ChatGPT Ads conversion tracking: from click to customer

A new advertising channel is only as trustworthy as its measurement. If all you can see is clicks, you will either overrate it or kill it early, and both mistakes are expensive.

This is how conversion measurement works in ChatGPT Ads, drawn from OpenAI's documentation, plus the part nobody's documentation covers: what to do about the stretch between a tracked conversion and money in the bank.

The four conditions for a conversion to count

OpenAI reports a conversion when all four of these are true:

1. It receives the event from a data source connected to your ad account.
2. The standard or custom event matches a conversion event configured for the campaign.
3. The event occurs within the applicable attribution window.
4. OpenAI can connect the event to an eligible ad click.

Each of those is a place measurement can quietly fail, and most tracking problems turn out to be one of the four rather than something exotic.

Two ways to send events

You create a data source in Ads Manager, then send conversion events using the OpenAI Pixel, the Conversions API, or both.

The Pixel is browser-side JavaScript. The Conversions API is server-side. Neither is strictly better, and OpenAI recommends using them together for more resilient measurement, for reasons that become obvious once you understand the click reference.

oppref: the thread that ties it together

The OpenAI click reference is called `oppref`, and it is appended to the end of your landing page URL like this:

``` www.openai.com?oppref=gAAAAAb123 ```

When someone clicks your ad, they arrive with that parameter attached. The OpenAI Pixel captures `oppref` and stores it in a first-party cookie, so it can be associated with conversion events that happen later in the session or on a subsequent visit.

Advertisers can also include `oppref` in Conversions API calls where it is available. That is the mechanism that lets a server-side event be tied back to the original click.

Two practical consequences that catch people out:

Do not strip the parameter. Some CMS setups, redirect chains and marketing tools clean query strings on arrival. If `oppref` is dropped before the Pixel fires, that click loses its strongest attribution signal. Test your actual landing path, including any redirect, with the parameter attached.

Capture it if your form posts server-side. If your lead form submits to a CRM rather than firing a browser event, you need `oppref` to travel with it. Read it from the cookie and pass it through as a hidden field so the Conversions API call can carry it.

Deduplication: the mistake that doubles your numbers

If you send the same conversion through both the Pixel and the Conversions API, use the same event ID for both so OpenAI can deduplicate it.

Skip this and you will count real conversions twice. That inflates your apparent performance, which is worse than under-reporting, because it leads you to scale spend on a number that was never true. If you are running both methods, verifying deduplication is not a nice-to-have.

Advanced matching, and what actually leaves the browser

Click identifiers are not always available. Advanced matching exists to fill that gap.

Advanced matching lets an advertiser send eligible first-party information, such as normalized and hashed contact details, alongside a conversion event, to give a clearer view of performance and support better optimization.

Automatic advanced matching (AAM) does this without you wiring anything. The OpenAI Pixel detects supported customer information from recognizable forms and other sources on your site, then normalizes and securely hashes it in the browser using SHA-256 before including it with conversion events.

The privacy detail worth understanding properly: raw customer information is not sent to OpenAI through automatic advanced matching. The hashing happens client-side, before transmission. You do not need to pass customer information manually or change your Pixel implementation.

That said, "you do not have to configure it" is not the same as "you do not have to think about it." If you operate under privacy commitments or a consent regime, you should know that hashed identifiers derived from form fields are being sent, and confirm that is consistent with what your privacy policy tells people and what your consent tooling permits.

Modeled measurement

Where it is available, OpenAI may use aggregated patterns from observed conversions to estimate attribution for advertiser-reported conversion events that would otherwise go unattributed.

In plain terms: some conversions cannot be deterministically tied to a click, and rather than reporting them as zero, the system estimates. This makes reporting more complete and is the industry norm now across every major platform.

It also means a portion of your reported conversions is modeled rather than individually observed. That is not a reason to distrust the number. It is a reason not to treat it as an audited ledger, and a reason to keep an independent source of truth in your own systems.

Conversion-optimized campaigns raise the bar

If you want the system to optimize toward conversions rather than clicks, there are hard prerequisites.

Conversion-optimized (oCPC) campaigns require conversion tracking to already be set up via the Conversions API and/or the JavaScript Pixel, and at least one supported standard conversion event. Custom conversion events are not currently supported for oCPC.

Several settings are locked at creation:

• Each oCPC campaign optimizes toward one conversion event, and the event cannot be changed after creation.
• The campaign objective cannot be changed after creation.
• Existing CPM or CPC campaigns cannot be converted to oCPC.

So the sequence matters. Tracking first, then a standard event flowing reliably, then the conversion campaign. Building the campaign first and bolting measurement on afterwards means starting again.

Where the platform stops and your business begins

Everything above ends at a tracked conversion: a form submitted, a purchase, a registration. For an ecommerce business that is often close enough to revenue.

For a service business it is not. A submitted form is not a customer. Between the two sit the questions that decide whether the channel was worth anything:

• Was the lead real, in your service area and in scope?
• Did it become a booked appointment?
• Did the job close?
• What was it worth?

No ad platform can see any of that, because it happens in your phone system, your calendar and your CRM. This is where most channel evaluations go wrong: the platform reports 40 conversions, that number looks healthy, and nobody checks that 22 were out of area and six were the same person filling in the form twice.

Closing that gap needs three unglamorous things: call tracking so phone leads are attributed rather than invisible, a CRM where lead status is genuinely maintained, and a habit of writing outcomes back, so a lead that became a $14,000 job is recorded as such.

With those in place you can follow spend through to booked work. Without them, be honest that measurement stops at the form, and fix that before scaling rather than estimating across it.

A working checklist

1. Create the data source in Ads Manager.
2. Install the Pixel, and add the Conversions API if you can send server-side events.
3. Verify `oppref` survives your entire landing path, including redirects.
4. Pass `oppref` into server-side events where your forms post to a CRM.
5. Use consistent event IDs across Pixel and CAPI, and confirm deduplication.
6. Confirm at least one supported standard event fires reliably before considering oCPC.
7. Check that automatic advanced matching is consistent with your privacy policy and consent setup.
8. Connect call tracking and CRM outcomes so the chain reaches revenue.
9. Only then judge the channel, and judge it on qualified leads and customers.

The rule that has not changed in twenty years of paid media: instrument before you spend. New platform, same discipline.

Last reviewed against OpenAI documentation: August 2026. Measurement features here are actively changing, so verify API details against current documentation before implementation.