

.png)
ChatGPT Ads drops a click identifier on your ads and opens an API to send your conversions back. Three things change in your measurement. You gain an identifier on the bought share of your AI traffic, you inherit one more source of truth to reconcile, and the blind spot upstream stays exactly as it was.
You already get traffic from ChatGPT. Someone asks a question, the assistant cites one of your pages, the visitor clicks. And what do you know about that visitor? Nothing of what was said before the click. Often not even where the visit came from. If you have worked on web-to-app attribution, the pattern will look familiar. Since 24 August 2026, ads have been serving in ChatGPT across 31 European markets. And since 31 August, a business registered in one of those countries opens its own account.
This article looks at what the channel adds to a measurement setup that already runs, and what it takes away. Not how to launch a campaign. What needs settling before you launch one.
Like any modern ad platform. With one difference, and it changes everything: until this summer, this surface sent nothing back.
The relationship between ChatGPT and your site ran one way. The assistant cited your pages, visitors arrived, and you had nothing to send back. You watched an effect without being able to touch its cause. That is what makes visibility work inside generative answers so painful to steer. No return signal, so no loop, so no optimisation in the sense you use everywhere else.
The setup rests on two objects, and only two. A click identifier first, first. OpenAI appends a parameter called oppref to your ad URLs. Same role as Google's gclid: tying an action on your site to the click that came before it. The ChatGPT Ads pixel, the measurement script on your pages, reads it on the way through. A conversions API second, second. Your server posts what your visitors do, so OpenAI can attribute it and optimise campaigns on it.
So a loop now exists between an AI-generated answer and your information system. Nothing revolutionary on the technical side: your teams have already wired the same thing to other ad platforms. It is the surface at the other end of the wire that is what is new.
It answers one question: did this sale come from an ad, and from which one?
Someone clicks, oppref appears in the URL of the landing page. The measurement script reads it and stores it in a cookie set by your own domain, so later pages in the visit can reuse it. As long as the conversion happens in the browser, it all runs without you thinking about it.
That script still has to sit somewhere. The pixel identifier is generated in the conversions tab of Ads Manager, along with the snippet that goes with it. Put it in your tag manager, not in the site's code. That is the only place where you can gate it on consent, and remove it one day without reopening the site. OpenAI does not publish an official Google Tag Manager template yet: it will be a custom HTML tag, or a community template. Either way, only one configuration per page.
The problem starts when the conversion completes somewhere else. An order validated in a back office. A payment confirmed by the provider. An appointment marked as attended in the CRM. Those events leave from your servers, and OpenAI's documentation is clear on this: the click identifier does not travel with them automatically. Someone has to write the code that reads it from the cookie, stores it with the order, and sends it back at conversion time.
This is the number one omission on this channel, and the sneakiest: nothing breaks. The conversions are sent, OpenAI receives them, they are perfectly valid. Attached to no campaign. You have them in your back office, you hunt for them in vain in Ads Manager, and you end up blaming the platform 🙂
A word on a claim doing the rounds. Several articles state that this cookie lasts 30 days. I read the pixel documentation line by line (it took a while): no lifetime is published for it. What does last 30 days is the attribution window you set yourself when creating a conversion event. An account setting, not a browser property. I am wary of any article that conflates the two.
No. It only lands on what you buy. Your organic citations, the ones carrying most of your visibility, stay as opaque as before. Worse: if nobody deals with this before launch, the two land in the same place in your reports. Three reasons for that.
So you end up with two-speed measurement. On one side a minority share of AI traffic, tracked click by click, with its cost and its return. On the other the majority: no identifier, no upstream, no way to tie a sale to a conversation. That asymmetry has known effects. What is finely measured attracts budget, whether or not it creates value. It is what led to a decade of overspending on brand search. Not because it paid better. Because it proved itself more easily.
So the right question is not “how much is ChatGPT worth to me”, it is can I separate what I buy there from what I earn there. And it is settled before launch. Campaign parameters placed on your landing URLs travel inside the address itself, where the referrer disappears. Information you did not record on day one cannot be rebuilt on day thirty.
A loop runs both ways. For OpenAI to tell you what your ads return, you first have to tell it what your visitors do. And at that point it stops being a tagging question.
Three decisions are yours, and none of them is technical.
First: which conversions you agree to send back. OpenAI's taxonomy holds thirteen standard events, from page view to order.
Every event you send feeds OpenAI's optimisation as much as your own reporting. That list is a decision, not a default.
Second: where you send them from. Conversions that complete outside the browser can only leave from your servers. If you already run server-side collection, this is one more destination and a few days of work. If you do not, it is a project in its own right. Budget it as one.
Third: what the visitor can refuse. OpenAI becomes one more data recipient, to be declared in your consent platform like every other ad platform. Watch the default: the script assumes consent is granted until told otherwise. So block it upstream, with an exception that reads the state of your banner. Add a trigger on the consent update event too, or the pixel will wait for the next page to load for anyone who accepts mid-visit. As for advanced matching, which sends customer details as irreversible fingerprints, it raises the same lawful basis questions as everywhere else. Turning an email address into a fingerprint protects the data in transit; it does not manufacture consent. And do not count on Google Consent Mode to do the work for you: it is a Google protocol that talks to Google tags. OpenAI's pixel does not listen to it.
Because you have just added a fourth referee to a table that already had three. Your analytics tool, Google Ads and Meta never agree, and that is normal: each applies its own rules. ChatGPT Ads brings four new ones, which look like neither Google's nor the ones your teams carry in their heads.
The third row is the expensive one. A single sale is often sent twice, from the browser and from the server, so it survives an ad blocker or a tab closed too early. The platform still has to understand that both events describe one sale. It only does so if they carry a rigorously identical event identifier.
In most of the setups we take over, that identifier is built in two different places. The order number on one side, a value generated on page load on the other. Both events are valid, nothing surfaces as an error, and every sale counts twice. The kind of bug you find at quarter end, when the Ads Manager number stops resembling anything.
Note above all that at OpenAI the first event received is the one kept, whichever channel it came from. If your server posts forty seconds after the browser with the exact amount and the full basket, the poorer version survives. The same reasoning applies to any architecture that sends a conversion from two places, as we cover in our piece on identity resolution.
Three things, and all of them are settled before the first impression is served.
Take them in that order: the first one conditions the other two.
This is where we start when a client hands us a new channel, before touching a tag. It is the core of our Measurement & Tracking.
If you take one thing away: ChatGPT Ads does not measure your AI traffic, it measures the small share the small share you buy. And that is exactly what makes it useful. It finally forces you to separate, in your reports, what you buy on generative surfaces from what you earn there. That distinction existed nowhere. Without it, no claim about your visibility inside AI answers is verifiable.
Want to know what your stack actually captures from assistant-driven traffic? Talk to a Smart Bees consultant.
Not to run them. Without measurement you already have impressions, clicks and cost. The pixel becomes necessary as soon as you want to track a conversion, or let OpenAI optimise on it. And it can live in the browser, on your servers, or both at once.
Because the only parameter appended automatically to your ad URLs is a click identifier. An analytics tool does not read it as a source. The untagged click therefore lands where an organic citation lands, or falls into direct when the referrer is lost. The only reliable fix: tag every landing URL before launch, not after.
Not with ChatGPT Ads tooling, which only covers bought traffic. The earned share is handled with the usual referral analysis methods, and their known limits. That is exactly the asymmetry to keep in mind when you split a budget between the two.
Because your browser and server events do not carry the same event identifier. The platform only recognises a duplicate when both are rigorously identical. The classic case: the order number on one side, a value generated when the confirmation page renders on the other. Both events are valid, nobody sees an error, and every sale counts twice.
Yes, like any advertising tracker. Two things to watch. OpenAI has to be declared as a recipient in your consent platform, or your consent-gated triggers will stay blocked. And the script treats consent as granted by default: block it upstream rather than trusting its own setting.

Thirty minutes with one of the founders. We look at your collection setup, what comes back from generative surfaces, and what you are missing to make the call.