OpenAI Ads Dynamic Parameters for UTM Tracking: Practical Guide

This guide explains the four dynamic ID templates visible in OpenAI Ads Manager Beta, how to map them into GA4-compatible UTM tags and custom query parameters, where compatibility is confirmed or still unverified, and how to keep OpenAI Ads, CRM, analytics, and warehouse reporting reconcilable.

Practical default: keep utm_source=chatgpt, utm_medium=paid_ai, and a readable business campaign slug in utm_campaign static. Put {campaign_id} in utm_id, put {ad_id} in utm_content, and preserve all four OpenAI object IDs in optional oai_* backup parameters. Never create, replace, or strip OpenAI's automatic oppref click reference.

Executive summary

OpenAI Ads Manager Beta now exposes a campaign-level field named Landing page query parameters in at least some advertiser accounts. The interface says that the field appends missing query parameters and lists four template values: {campaign_id}, {ad_group_id}, {ad_id}, and {ad_account_id}.

There is an important documentation conflict. As reviewed on 25 July 2026, OpenAI's public Measure Results article still says that static UTM parameters are supported but dynamic macro syntax is not. The public Advertiser API campaign schema and documented bulk workflows also do not expose a field for this query-parameter suffix. The safest interpretation is that the UI capability is an account-gated or staged beta that has reached some accounts before the public documentation and API surface have caught up.

Advertisers should therefore use a two-layer model:

• Marketing taxonomy: stable values in utm_source, utm_medium, utm_campaign, and utm_source_platform.
• Technical join keys: OpenAI IDs in utm_id, utm_content, and custom oai_* parameters.

The best direct mappings are utm_id={campaign_id} and utm_content={ad_id}. The ad-group ID is useful, but utm_term is defined by Google Analytics as a paid-keyword field, while OpenAI ad groups organize themes, intents, and context hint clusters rather than search keywords. For most teams, oai_ad_group_id={ad_group_id} is cleaner than forcing the value into utm_term.

Dynamic query parameters do not replace OpenAI conversion measurement. OpenAI automatically appends an oppref click reference to eligible landing-page URLs. The OpenAI Pixel can capture it, and advertisers can pass it with Conversions API events when available. UTMs explain traffic in GA4 and other analytics tools; oppref helps OpenAI connect conversions to eligible ad clicks.

Compatibility is strongest for standard website ads created in the Ads Manager interface when the field is visible in the exact account. Compatibility is not publicly confirmed for product-feed destinations, bulk CSV creation, the public Advertiser API, the limited-preview Bulk API, or mobile measurement partner links. These paths need their own implementation and QA strategy rather than an assumption that every OpenAI Ads URL accepts the same macro layer.

The feature is visible in the UI, but not yet consistently documented

The most important part of this guide is not the template itself. It is the distinction between what is officially documented, what is visible in a live beta interface, and what must still be validated by the advertiser.

Evidence level	What it supports	How to use it operationally
Confirmed in public documentation	Static UTM parameters can be added to destination URLs; OpenAI uses campaign, ad-group, ad, and account IDs in reporting and APIs; oppref is appended for conversion measurement.	Safe to build a static fallback and a reporting data model around these documented objects.
Observed in Ads Manager Beta	The campaign editor shown in the supplied account lists four dynamic template values and says that missing query parameters are appended.	Use only when the field and token list are visible in the exact account where the campaign will run.
Not publicly specified	Exact rollout scope, token resolution across every campaign type, duplicate-key precedence, product-feed behavior, bulk/API support, encoding behavior, and whether the feature survives all edit workflows.	Run a controlled click test and keep a static fallback. Do not infer unsupported macros from other ad platforms.

This conflict is not unusual in a rapidly changing beta product. It does, however, change the implementation standard. A template that is logically correct should not be considered production-ready until the browser receives resolved IDs instead of literal strings such as {campaign_id}.

This is a query-string suffix, not a full Google Ads-style tracking template

Operationally, the field behaves more like a final URL suffix than a full tracking template:

• It accepts parameter-value pairs rather than a complete destination URL.
• The interface example starts with a parameter name, not with ?.
• There is no documented landing-page placeholder comparable to Google Ads {lpurl}.
• The field does not replace the ad's landing page. It adds query parameters to that landing page.
• The wording says it appends missing query parameters, which implies that an existing key may be preserved, but the precedence rule is not publicly specified.

Do not paste a complete URL into this campaign field, and do not begin the value with ?. Use a plain query string:

utm_source=chatgpt&utm_medium=paid_ai&utm_campaign=q3-demo-push-emea&utm_id={campaign_id}&utm_content={ad_id}

OpenAI Ads dynamic parameter reference

The interface currently exposes four ID-based values. The example outputs below use the same object prefixes shown in OpenAI's public Ads API documentation. They are illustrative, not a guarantee that every account or UI rollout will display exactly the same formatting.

Template value	Object represented	Illustrative resolved value	Best UTM or custom-field use	Practical note
{campaign_id}	Top-level OpenAI Ads campaign ID	cmpn_101	utm_id and/or oai_campaign_id	The cleanest campaign-level join key for Ads Manager exports, the Insights API, CRM reporting, and cost reconciliation.
{ad_group_id}	Ad-group ID inside the campaign	adgrp_301	oai_ad_group_id; optionally utm_term	Useful for theme, intent, context-hint, bid, and product-set analysis. It is not a paid-search keyword.
{ad_id}	Individual ad or product-ad-template ID	ad_501	utm_content and/or oai_ad_id	The strongest creative-level identifier currently exposed by the UI token list.
{ad_account_id}	OpenAI Ads account ID	adacct_123	oai_account_id	Especially useful for agencies, multi-brand organizations, shared landing pages, and centralized data warehouses.

Values that are not in the current token list

The observed field does not expose dynamic names or delivery metadata. Do not invent macros such as {campaign_name}, {ad_group_name}, {ad_name}, {placement}, {device}, {country}, {context_hint}, {product_id}, or {objective}. A literal unresolved token can pollute GA4, CRM records, and redirect logs without causing an obvious landing-page error.

The lack of name macros is not necessarily a disadvantage. IDs are more stable than editable names. Keep a mapping table between platform IDs and readable names in your reporting layer instead of making the landing URL the only place where campaign structure is described.

Recommended UTM model for OpenAI Ads

Google Analytics defines utm_id as a campaign ID and utm_content as a way to differentiate creatives. Those definitions align well with the OpenAI campaign and ad identifiers. The remaining fields should stay readable and stable across platforms.

Parameter	Recommended OpenAI Ads value	Static or dynamic?	Why
utm_source	chatgpt	Static	Identifies the inventory where the user clicked. It also leaves room for OpenAI to add other ad surfaces later without changing the buying-platform field.
utm_medium	paid_ai	Static	Creates a clear channel that works across CPM, CPC, and oCPC objectives. Use cpc only if that is the organization's deliberate cross-channel convention.
utm_campaign	A controlled business slug such as q3-demo-push-emea	Usually static	Keeps one initiative comparable across OpenAI Ads, Google Ads, Meta, LinkedIn, email, and partner media. Use the OpenAI campaign name only when naming governance guarantees that it matches this business layer.
utm_id	{campaign_id}	Dynamic	Matches GA4's campaign-ID meaning and provides a stable key for campaign-data or spend joins.
utm_content	{ad_id}	Dynamic	Distinguishes the ad or creative object without relying on a mutable ad name.
utm_term	Leave empty, use a controlled theme label, or use {ad_group_id} only by policy	Optional	GA4 describes this as a paid-keyword field. OpenAI ad groups are not keywords, so a custom field is semantically cleaner.
utm_source_platform	openai_ads	Static	Identifies the platform responsible for budget and targeting while utm_source identifies the current ChatGPT inventory.
oai_account_id	{ad_account_id}	Dynamic	Agency, multi-account, and warehouse join key.
oai_campaign_id	{campaign_id}	Dynamic	Technical backup for utm_id and a clearly named field for CRM or server logs.
oai_ad_group_id	{ad_group_id}	Dynamic	Preserves the hierarchy without overloading utm_term.
oai_ad_id	{ad_id}	Dynamic	Technical backup for utm_content and a clear ad-level join field.

Why paid_ai is usually safer than changing the medium by objective

A CPM campaign can still generate website clicks, and an oCPC campaign is still billed per valid click. If the same channel alternates among display, cpc, ocpc, and paid_ai based on campaign objective, GA4 will split one acquisition source across several mediums. The objective and billing model belong in the OpenAI campaign table, not necessarily in the UTM channel taxonomy.

paid_ai is an editorial recommendation, not an OpenAI or Google reserved value. Do not assume GA4's default channel group will classify it exactly as intended. Create a custom channel such as Paid AI and verify the result in your property:

Custom channel: Paid AI
Source exactly matches: chatgpt
AND
Medium exactly matches: paid_ai

Organizations that already use cpc for every paid click source can retain that convention, but they should still use utm_source=chatgpt and consider a custom channel group for consistent classification.

What should stay static and what should be dynamic

• Keep static: source, medium, business campaign, buying platform, geography label, funnel label, offer name, and any value that must remain readable across channels.
• Make dynamic: platform object IDs that are difficult to type correctly and valuable for deterministic joins.
• Avoid dynamic names: the current UI does not offer them, and editable names are weaker historical keys than IDs.
• Do not put IDs in source or medium: doing so creates a new acquisition row for every object and destroys channel-level reporting.

Copy-ready OpenAI Ads query templates

Compact GA4 template

Use this when the main requirement is clean GA4 acquisition reporting with campaign- and ad-level identifiers:

utm_source=chatgpt&utm_medium=paid_ai&utm_campaign=q3-demo-push-emea&utm_id={campaign_id}&utm_content={ad_id}&utm_source_platform=openai_ads

Recommended full template for GA4, CRM, and warehouse joins

This is the practical default for advertisers that need reliable downstream reconciliation:

utm_source=chatgpt&utm_medium=paid_ai&utm_campaign=q3-demo-push-emea&utm_id={campaign_id}&utm_content={ad_id}&utm_source_platform=openai_ads&oai_account_id={ad_account_id}&oai_campaign_id={campaign_id}&oai_ad_group_id={ad_group_id}&oai_ad_id={ad_id}

The deliberate duplication of campaign and ad IDs is optional. It gives analytics tools conventional UTM fields while giving CRM, forms, server logs, and data pipelines explicit OpenAI-specific names.

Variant that uses utm_term for the ad group

Use this only when the organization's UTM specification already treats utm_term as a broader targeting or ad-group field:

utm_source=chatgpt&utm_medium=paid_ai&utm_campaign=q3-demo-push-emea&utm_id={campaign_id}&utm_content={ad_id}&utm_term={ad_group_id}&utm_source_platform=openai_ads&oai_account_id={ad_account_id}

For a new implementation, the cleaner option is to leave utm_term empty and use oai_ad_group_id.

Illustrative resolved landing URL

Assume the ad's destination URL is https://www.example.com/demo?language=en. A resolved click could look like the following. The exact order of parameters and the actual ID values may differ:

https://www.example.com/demo?language=en&utm_source=chatgpt&utm_medium=paid_ai&utm_campaign=q3-demo-push-emea&utm_id=cmpn_101&utm_content=ad_501&utm_source_platform=openai_ads&oai_account_id=adacct_123&oai_campaign_id=cmpn_101&oai_ad_group_id=adgrp_301&oai_ad_id=ad_501&oppref=gAAAAAb123

Do not add oppref to the template. OpenAI creates it automatically for eligible clicks.

A beta-era override pattern based on “appends missing query parameters”

The UI wording suggests a useful hierarchy: broad defaults can live in the campaign field, while an ad URL can carry an intentional override for a key that should not be appended again. For example, a campaign might provide the common source, medium, and ID layer, while one ad URL already contains a special utm_campaign or utm_content value.

This is a promising workflow, not a documented contract. Before relying on it, test all three cases:

1. A destination URL with no query string.
2. A destination URL with unrelated keys such as language=en.
3. A destination URL that already contains one of the same UTM keys as the campaign field.

If the resulting URL contains duplicate keys, different analytics systems may choose the first value, the last value, or an array. Remove the duplicate at the source rather than assuming every downstream tool will resolve it the same way.

Compatibility by objective, campaign type, and creation method

UTM logic is attached to the click path, not to the bidding algorithm. That is why the same baseline taxonomy can work across CPM, CPC, and oCPC website campaigns. The difficult cases are campaign types or creation methods where the landing URL comes from a different object or where the dynamic suffix is not exposed in public schemas.

Campaign path	Where the destination comes from	Dynamic UI template status	Recommended implementation	Confidence
Standard CPM / Reach campaign created in Ads Manager	The individual ad's landing page	Likely usable when the campaign field is visible, but not publicly documented	Use the compact or full query template and validate a resolved click.	Medium: supported by the observed UI, contradicted by the public macro FAQ.
Standard CPC / Clicks campaign created in Ads Manager	The individual ad's landing page	Likely usable when visible in the account	Use the same stable UTM taxonomy; do not change the medium merely because billing is per click unless that is your organization-wide rule.	Medium.
Standard oCPC / Conversions campaign created in Ads Manager	The individual ad's landing page	Likely follows the same click path when the field is visible	Use UTMs for external analytics, but also configure the OpenAI Pixel and/or Conversions API and preserve oppref.	Medium for the query template; high for the documented measurement requirements.
Product-feed campaign	The selected feed item supplies the image and destination URL	Not publicly specified	Add a stable product key and static UTM fallback to each feed URL. Test whether the campaign-level suffix adds OpenAI object IDs across several products.	Low for macro compatibility; high for feed-owned destination behavior.
Bulk CSV campaign creation	Landing-page URLs are supplied on the ads tab	No campaign query-template field is described in the public checklist	Download a fresh template from the exact account. Use a dedicated column only if it is present; otherwise use static UTMs in landing URLs or configure the campaign field after upload.	Low for dynamic bulk support; high for static landing URLs.
Public Advertiser API	creative.target_url for standard chat_card ads	The public campaign create/update schema has no landing-query suffix field	Generate static URL values in your integration from known object IDs. Do not assume UI tokens resolve when placed directly in target_url.	High for the current public schema; dynamic support remains unconfirmed.
Limited-preview Bulk API	target_url in ad create operations	No suffix field is listed among supported campaign inputs	Use static query strings generated by your integration and retain an ID-to-name mapping.	High for the documented request fields.
AppsFlyer or Adjust mobile attribution link	The mobile measurement partner generates the campaign link	Macro compatibility is not documented by OpenAI	Use the MMP-generated link required by the integration. Add only parameters accepted by the partner and confirm that OpenAI IDs resolve before launch.	Low for macro pass-through; high for the documented MMP link workflow.

Why CPM, CPC, and oCPC normally use the same UTM structure

OpenAI currently supports CPM, CPC, and conversion-optimized CPC objectives. The objective changes pricing and delivery optimization, but the website still receives a click when the user opens the landing page. A consistent source, medium, campaign, and ID model therefore makes cross-objective analysis easier.

Store objective and billing metadata in the OpenAI campaign table or reporting warehouse. Do not force it into utm_medium unless your organization explicitly wants separate channels for the same traffic source.

Product-feed campaigns need a separate product identity layer

For a product-feed ad, the selected feed item supplies the destination URL. OpenAI's Insights API can report product-segment fields including product.feed_id and product.item_id, but the observed dynamic token list does not contain a product macro. That creates a join gap unless the product URL itself carries a stable product identifier.

A practical product-feed destination can include the SKU or feed item ID statically:

https://www.example.com/products/running-shoe?utm_source=chatgpt&utm_medium=paid_ai&utm_campaign=spring-footwear&oai_product_id=sku-123

If the campaign-level field works for product-feed campaigns in your account, it can then append campaign, ad-group, ad-template, and account IDs. Test multiple products because one preview URL is not proof that every feed item preserves the suffix.

Product-feed campaigns cannot currently use oCPC. They should therefore be evaluated separately from conversion-optimized standard campaigns even if the same UTM naming model is used.

API workflows: expand static values yourself

The public Ads API returns stable object IDs such as adacct_123, cmpn_101, adgrp_301, and ad_501. Because the campaign API does not expose the UI suffix field, an integration can build static URLs from IDs it already knows instead of depending on an undocumented token parser.

A simple programmatic workflow is:

1. Read the ad account ID from GET /ad_account.
2. Create the campaign and store the returned campaign ID.
3. Create the ad group and store the returned ad-group ID.
4. Build the ad's target_url with those real values.
5. Store the returned ad ID in the reporting map, even if it was not available when the original URL was constructed.

This approach may omit the ad ID from the landing URL unless the integration performs a controlled follow-up update. It is still safer than sending literal, unconfirmed macro syntax through the API.

Mobile measurement partner links are not ordinary website URLs

OpenAI currently documents integrations with AppsFlyer and Adjust. For app measurement, the advertiser creates an attribution link in the mobile measurement partner and uses that link in the corresponding ChatGPT Ads campaign. Attribution settings and event sharing are then governed by the MMP configuration.

Do not replace an MMP link with a normal UTM-tagged app-store URL. Keep the partner link intact, then use only the partner's supported custom parameters. If the OpenAI dynamic suffix appears to be available on the campaign, test whether the MMP receives resolved IDs rather than literal braces and whether its redirect chain preserves them.

UTMs and oppref solve different measurement problems

OpenAI conversion measurement can connect an event to an eligible ad click using an automatic click reference named oppref. OpenAI appends it to the landing URL, the Pixel can capture it in a first-party context, and a server-side event can include it when available.

Identifier layer	Main purpose	Primary consumer	Implementation rule
utm_*	Source, medium, campaign, creative, and acquisition reporting	GA4, Adobe Analytics, Matomo, CRM, dashboards	Use a stable taxonomy and consistent casing.
oai_*	Deterministic platform-object joins and troubleshooting	CRM, server logs, data warehouse, attribution model	Capture deliberately; these are not automatically standard GA4 acquisition dimensions.
oppref	OpenAI click-to-conversion attribution	OpenAI Pixel and Conversions API	Never define it manually, overwrite it, or strip it in redirects.

Redirect services, CMS rewrites, privacy tools, single-page applications, and URL-cleaning scripts can preserve UTMs while accidentally removing oppref, or preserve oppref while dropping custom parameters. QA must check all three layers together.

When the same conversion is sent through the OpenAI Pixel and Conversions API, use the same event ID so OpenAI can deduplicate the two copies. UTMs should not be used as a substitute for that event-level deduplication key.

Implementation in GA4, CRM, and a data warehouse

GA4 acquisition layer

GA4 can populate manual campaign dimensions from standard UTM parameters. The baseline fields should therefore remain compact and readable:

• utm_source=chatgpt
• utm_medium=paid_ai
• utm_campaign=q3-demo-push-emea
• utm_id={campaign_id}
• utm_content={ad_id}
• utm_source_platform=openai_ads

Google recommends consistent, case-sensitive naming and specifically identifies utm_id as the campaign ID. Use one lowercase convention, because chatgpt, ChatGPT, and CHATGPT can become separate report values.

Custom parameters such as oai_ad_group_id do not automatically become standard traffic-source dimensions. If they are needed in GA4 reports, read them from the landing URL, send them as event parameters, and create the corresponding custom dimensions. Use only the fields that analysts will actually query; custom-dimension quotas and high-cardinality reporting make indiscriminate capture expensive.

CRM and lead-form layer

For lead generation, parse the landing URL on the first page and write attribution values into hidden form fields. At minimum, preserve:

CRM field	Suggested value	Reason
Original source	chatgpt	Readable acquisition source.
Original medium	paid_ai	Consistent channel grouping.
Marketing campaign	The static business slug	Cross-channel initiative reporting.
OpenAI campaign ID	oai_campaign_id or utm_id	Campaign spend and performance joins.
OpenAI ad-group ID	oai_ad_group_id	Audience, context, bid, or product-set analysis.
OpenAI ad ID	oai_ad_id or utm_content	Creative and ad-level analysis.
OpenAI ad account ID	oai_account_id	Multi-account and agency routing.
OpenAI click reference	oppref	Available for server-side OpenAI conversion attribution.
Original landing URL	The complete first landing-page URL	Forensic QA when parsed fields or redirect behavior are questioned later.
First landing timestamp	Server or browser timestamp	Helps reconcile attribution windows, time zones, and delayed CRM events.

Do not add emails, phone numbers, names, or other personal data to the query string. URLs commonly appear in browser history, server logs, analytics exports, support tickets, screenshots, and third-party systems.

Warehouse and spend-reconciliation layer

OpenAI Ads Manager can export reporting data, and the public Insights API supports account, campaign, ad-group, and ad scopes. Use the dynamic IDs as deterministic join keys:

1. Store the raw landing URL and parsed parameters for each session or lead.
2. Export OpenAI performance or query the Insights API with campaign, ad-group, and ad IDs.
3. Maintain an ID-to-name history table rather than assuming the current name was always used.
4. Join spend and clicks to sessions, leads, opportunities, and revenue by the most granular available ID.
5. Use campaign ID for broad reconciliation and ad ID for creative analysis; use ad-group ID when bid, audience, context, or product-set logic matters.

OpenAI notes that Ads clicks and analytics sessions can differ because the systems count different stages of the journey. Page-load failure, redirects, consent settings, browser blocking, UTM handling, attribution windows, and time zones can all create legitimate gaps. Compare the same time zone and date range before treating a discrepancy as a tracking failure.

Best practices and beta-era lifehacks

1. Use a dual-layer taxonomy

Keep human marketing meaning in UTMs and technical identity in oai_* fields. This protects GA4 reports from unreadable IDs without sacrificing CRM or warehouse joins.

2. Reserve utm_id for {campaign_id}

This is the most semantically direct mapping and the easiest field to use later for campaign data imports or cost joins. Do not use utm_id for an ad-group or ad ID unless your entire reporting model is deliberately built at that level.

3. Keep source inventory-specific and platform vendor-specific

Use utm_source=chatgpt for current inventory and utm_source_platform=openai_ads for the buying platform. If OpenAI adds another placement later, the source can change while the source-platform value remains stable.

4. Treat campaign defaults plus ad-level overrides as an experiment

Because the UI says missing parameters are appended, a campaign-wide baseline may coexist with a more specific key already present on one ad URL. This can reduce repetitive tagging, but only after a resolved-click test proves the actual precedence in the account.

5. Put the product key in the feed URL

There is no observed {product_id} template, while product reporting can expose product.item_id. Add the stable item ID or SKU to the product URL so website behavior can be joined to product-level OpenAI reporting.

6. Expand values in your API integration instead of guessing macros

The public API returns real IDs. Use them to construct static query strings. This produces deterministic URLs even while the UI template remains undocumented and absent from public campaign schemas.

7. Store the raw first landing URL

Parsed fields are convenient, but the raw URL is the evidence of what the browser actually received. It helps diagnose duplicate keys, unresolved macros, redirect stripping, casing errors, and missing oppref.

8. Snapshot the beta configuration

Save the date, screenshot, exact template, account ID, campaign ID, and result of a controlled click test in the tracking specification. A beta UI can change before internal documentation is updated.

9. Keep a static fallback ready

Because the public Help Center still says dynamic macros are unsupported, every launch should have a fallback that uses static UTM values in the ad destination. A fallback prevents a staged rollout, UI change, or unsupported campaign path from sending literal braces into production data.

Common mistakes and troubleshooting

Symptom	Likely cause	Recommended fix
The landing URL contains {campaign_id} or another literal token.	The account, campaign type, field, or click path does not support dynamic resolution, or the syntax was entered in an ordinary ad URL rather than the beta field.	Confirm the token picker in the exact account. Replace the dynamic layer with static values until a resolved click succeeds.
Only static UTMs appear; OpenAI IDs are missing.	The campaign field was not saved, was not available on the final campaign, or the public static-only behavior is still in effect.	Reopen campaign settings, verify the exact saved value, and test a new eligible click.
Duplicate utm_campaign or utm_content keys appear.	The ad destination and campaign suffix both define the same key, or a redirect adds another copy.	Assign ownership of each key to one layer. Do not rely on downstream first-value or last-value behavior.
GA4 shows several rows for one OpenAI campaign.	Mixed casing, inconsistent static slugs, or a mutable campaign name is being used in utm_campaign.	Normalize source and medium, use one stable business slug, and preserve the platform ID separately.
Ads Manager clicks exceed GA4 sessions.	A click does not guarantee a completed analytics session. Redirects, consent, blockers, slow loads, time zones, and UTM handling can differ.	Compare the same date and time zone, inspect final URLs, and reconcile against OpenAI CSV or Insights data.
OpenAI conversions are missing although GA4 conversions exist.	oppref was stripped, the Pixel or Conversions API is incomplete, the event does not match the campaign's configured conversion, or attribution timing differs.	Validate oppref, the conversion event, event IDs, Pixel/CAPI delivery, and the selected campaign goal.
Product traffic cannot be joined to the product report.	The feed destination does not carry the product item ID and no product macro is available.	Add a static SKU or item-ID parameter to each product URL and join it to product.item_id.
API-created ads do not contain dynamic IDs.	The public API has no documented campaign suffix field and does not promise UI macro parsing in target_url.	Generate static URL values from API responses and maintain the full hierarchy in your data model.
An MMP link opens the app but loses campaign metadata.	An unsupported query parameter was appended, or an intermediate redirect removed it.	Use the partner-generated link, follow the partner's accepted parameter model, and test the complete app-click flow.

QA checklist before launch

• [ ] Confirm that Landing page query parameters is visible in the exact ad account and campaign editor.
• [ ] Copy template values from the account UI instead of retyping them from memory.
• [ ] Do not add a leading ? to the campaign field.
• [ ] Keep static values lowercase and use one separator convention.
• [ ] Confirm that each query key appears only once across the ad URL, campaign suffix, redirects, and MMP link.
• [ ] Test a destination with no existing query string.
• [ ] Test a destination that already contains unrelated query parameters.
• [ ] Test any destination that contains a fragment such as #pricing.
• [ ] Follow every redirect and inspect the final browser URL.
• [ ] Confirm that no literal braces remain in the final URL.
• [ ] Confirm that oppref is present on an eligible click and survives redirects.
• [ ] Verify GA4 source, medium, campaign, campaign ID, and content values in debugging or real-time tools.
• [ ] Verify that oai_* values are captured by the website, forms, CRM, or server logs where required.
• [ ] Run a test lead or purchase and confirm that the original IDs and oppref reach the server-side conversion workflow.
• [ ] Download an OpenAI Ads report or query the Insights API and prove that the captured IDs join to the intended campaign, ad group, and ad.
• [ ] Repeat the test after a campaign edit, URL change, bulk update, feed refresh, or MMP-link change.
• [ ] Keep a static-UTM fallback for accounts or campaign types where dynamic resolution fails.

Related tracking guides

This guide follows the same cross-platform tracking model used in the metricfixer series on LinkedIn Ads dynamic parameters, Microsoft Ads dynamic parameters, Google Ads ValueTrack parameters, and Meta Ads dynamic URL parameters. The shared principle is to keep channel taxonomy stable and use platform IDs as technical join keys rather than turning every UTM field into a dynamic platform dump.

Open questions and limitations

The current public OpenAI documentation and the supplied Ads Manager Beta interface do not fully agree. The interface exposes four dynamic values, while the public reporting FAQ still describes dynamic macros as unsupported. OpenAI has not publicly documented the rollout criteria, exact macro parser, duplicate-key precedence, output encoding, URL-length behavior, or compatibility matrix for the campaign field.

The public Advertiser API and its downloadable OpenAPI schema do not currently expose this campaign-level suffix. The public bulk-upload checklist and limited-preview Bulk API also do not document it. Product-feed campaigns inherit destination URLs from feed items, and mobile app campaigns use MMP-generated links, so neither path should be treated as confirmed without a live test.

This research did not execute a billable live ad click in the supplied account. Exact token resolution, parameter ordering, existing-key precedence, redirect behavior, and campaign-type compatibility therefore remain account-level QA items rather than guaranteed platform behavior.

Methodology and sources

This article was prepared on 25 July 2026 by comparing the supplied OpenAI Ads Manager Beta interface with OpenAI's current Help Center, developer Ads documentation, public OpenAPI schema, bulk workflow documentation, measurement documentation, product-feed documentation, and reporting API. Google Analytics documentation was used only for UTM semantics, naming guidance, custom channel groups, and custom event-parameter reporting.

Compatibility ratings distinguish three evidence levels: behavior documented by OpenAI, behavior visible in the supplied UI, and behavior inferred from object ownership or field wording but still requiring a controlled click test. Example IDs use official OpenAI API examples and are illustrative.

• OpenAI Help Center: ChatGPT Ads collection
• OpenAI Ads Manager Beta overview
• OpenAI: Ads in ChatGPT — The Basics
• OpenAI: Create Campaigns for ChatGPT
• OpenAI: Measure Results
• OpenAI: Conversion Measurement
• OpenAI Ads API quickstart
• OpenAI Ads API: Campaigns
• OpenAI Ads API: Ads
• OpenAI Ads API: Insights
• OpenAI Ads public OpenAPI schema
• OpenAI: Bulk Upload Campaign Schema Checklist
• OpenAI Ads Bulk API
• OpenAI Ads product feeds
• OpenAI Ads conversion-optimized campaigns
• OpenAI: Mobile Measurement Partner integrations
• Google Analytics: collect campaign data with custom URLs
• Google Analytics: custom channel groups
• Google Analytics: set up event parameters and custom dimensions

This article is for technical and operational information only. OpenAI Ads Manager is a beta product, and account availability, campaign types, dynamic template values, URL behavior, APIs, measurement features, and documentation may change after publication. Verify every template in the exact account and click path before spending begins. metricfixer is not affiliated with OpenAI, ChatGPT, Google, Google Analytics, AppsFlyer, or Adjust.