You haven't thought about the gclid in years: Google adds it,
auto-tagging keeps it and it almost always survives. In ChatGPT Ads the
equivalent is called oppref, it does exactly the same job and it
gets lost with alarming ease. And when it does, the sale still happens
but nobody knows which ad produced it.
What it is and how it arrives
According to OpenAI's help centre, the oppref is the click
reference: it is appended to the end of your landing page address when
someone taps your ad, in a form as simple as
yourdomain.com/offer?oppref=gAAAAAb123.
If you have the measurement pixel installed, it picks the value up from
the address and stores it in a first-party cookie on your domain.
Checked by us on 18/09/2026 by reading the pixel's code (version
0.1.41): that cookie is called __oppref, it lasts 30 days, it is
set on your main domain —so it reaches the subdomains where the pixel is
also installed— and it travels as a first-party cookie, not a
third-party one.
If you don't use the pixel and confirm conversions from your server, nobody captures it for you: you pick it up on arrival and carry it through to the moment you send the conversion. That route exists and OpenAI documents it for developers (link in the sources); your job is simply not to lose the identifier along the way.
Why it's the thread that holds everything
Without oppref, ChatGPT Ads can still try to attribute the conversion
using other signals (hashed contact data, modelling), but with it the
attribution is direct: this click, this person, this sale. It's what
turns a click report into a business report, and what supports the
per-ad cost-per-lead table in the lesson "The funnel ad by ad: from
impression to customer, and the cost of every step". If it fails, Ads
Manager says so in the event quality warnings, which include one
specifically for click information that is missing or can't be
connected.
The five places where it gets lost
| Where | What happens | How to fix it |
|---|---|---|
| Redirects | An intermediate redirect doesn't carry the parameters through and the final page gets none | Pass the ad's parameters to the final page, or point the ad straight at it |
| The form | The page receives it, but the form doesn't carry it; if the lead is confirmed later, there is nothing left to send | Store the identifier with the lead, in the same record |
| Another domain without measurement | Browser storage is per origin: what your website stores can't be read by your dashboard or your shop | Pass it between systems and measure at the destination too |
| Consent refused | With no advertising consent nothing is stored or sent, and what was blocked is not recovered | No technical fix: it's a legal decision (next lesson) |
| Shared links | Someone copies the address with oppref and passes it to another person, who converts |
Nothing to do — but never reuse someone else's identifier |
The first two happened to us. On 17/09/2026 we found that two of our eight ads pointed to an address that redirects to another page of ours, and that redirect was eating the parameters: the identifier died in the jump. We fixed it by carrying the ad's parameters through to the final page.
⚠️ Trap: the last two pieces of advice in the table aren't a matter of style. OpenAI asks for them explicitly in its event quality guidance: preserve the
opprefthrough redirects and navigation, and never substitute a default value or someone else's. Filling gaps with a made-up value doesn't improve attribution: it poisons it.
How to check it in five minutes
- Copy the final URL of an ad and add
?oppref=test-18-09by hand (use&if it already has parameters). - Open it and follow the whole path like a customer would: redirects, landing page, form, confirmation.
- Check three things: that the parameter reaches the final page, that the first-party cookie appears, and that the value ends up stored next to the lead in your database or CRM.
- Repeat on mobile, where most of the traffic is and where apps and in-app browsers break things most often.
- Repeat while refusing consent: here the right outcome is that nothing is stored.
Do it for every new ad and every time someone touches the redirects or the form.
Plan B: when there is no identifier
If the click arrived without an oppref, you can still send the
conversion with the SHA-256 hashed email (what OpenAI calls advanced
matching). Three warnings:
- Attribution gets worse: it's no longer "this click", it's "this person, probably". It works if they use the same email address.
- A hashed email is still personal data, not anonymous data.
- It doesn't fix the fault: if you lose the identifier often, fix the path, not the symptom.
💡 Ninja tip: add your own parameter, different for each ad (a
utm_content, for example). Theopprefbelongs to OpenAI and lets them attribute; your parameter is yours and lets you know which ad brought each visit, even when the platform's attribution fails.
Trap: chatgpt.com is not your ad
In your analytics you'll see visits whose referrer is chatgpt.com.
They are almost always organic: ChatGPT cited your site in an answer
and someone clicked the link. That is not the ad.
We checked it on our own site in September 2026 and the mistake is
expensive: counting those visits as campaign traffic inflates paid
performance and makes you raise budget for no reason. The paid visit
is the one carrying the oppref (or your per-ad parameter);
everything else is organic until proven otherwise.
What to take away
- The
opprefarrives at the end of the landing address and, with the pixel, lives for 30 days in a first-party cookie on your domain (checked by us on 18/09/2026). - It gets lost in redirects, forms, jumps between domains, refused consent and shared links.
- Check it in five minutes with a test value, following the whole path and on mobile too.
- Without the identifier, the hashed email is a plan B with worse attribution, and it is still personal data.
- Never invent or reuse an identifier: it poisons your measurement.
chatgpt.comas a referrer is the organic citation, not your ad.