Soku AI
On 2026-09-21 the ChatGPT Ads Measurement Pixel documentation at developers.openai.com gained a section it has never had: Cookie expiry. It names the two first-party cookies the Pixel writes on your domain, gives each an exact lifetime, and — the part that will change some implementations — explains that the two cookies refresh under completely different rules.
This is the first time OpenAI has documented the Pixel's client-side storage at all. Until today an advertiser filling in a cookie table for a privacy notice, or configuring a consent management platform, had nothing official to cite. Now there is a source, and it is precise enough to act on.
The change appears only in the developer documentation. The ChatGPT Ads help centre says nothing about Pixel cookies, before or after. That asymmetry is not new — the developer docs have repeatedly carried mechanics that the help centre never picked up — but it is worth stating plainly: if your team works from the help centre, you would not know this exists.
Last verified: 2026-09-21.
What the documentation now says
From the Measurement Pixel documentation, under Cookie expiry: "When measurement consent is granted, the Pixel uses these first-party cookies on your website".
| Cookie | Documented expiry |
|---|---|
__oppref | "30 days after the Pixel writes the cookie." |
__obref | "365 days after creation." |
The refresh semantics are the interesting part, and they differ between the two.
__oppref stores, in OpenAI's words, "the oppref attribution identifier from the landing page URL." Its renewal rule is stated explicitly: "Each time the Pixel captures a non-empty oppref URL parameter, including the same value again, it resets the cookie's expiry to 30 days. Reading the stored cookie on a visit without that parameter does not extend its expiry."
__obref stores "a randomly generated browser reference for your website." Its rule is the opposite: "The Pixel reuses a valid stored reference without extending its expiry. If the cookie is missing or invalid, the Pixel creates a new reference with a new 365-day expiry."
Two further statements matter and are easy to skim past:
- "These are the lifetimes requested by the Pixel. Browser restrictions or clearing cookies can shorten them."
- "Cookie expiry is separate from conversion attribution windows and conversion-data retention. The durations above describe browser cookie storage only."
And on removal: calling oaiq("consent", false) removes both cookies.
Why the difference between the two rules matters
It is tempting to read "30 days" and "365 days" as two numbers and move on. The renewal asymmetry is the substantive part.
__oppref is a rolling window tied to ad traffic. A visitor who lands on your site from a ChatGPT ad on day 1 and again on day 25 has their 30-day clock reset on day 25 — the identifier survives to day 55. But a visitor who returns organically on day 25, without the oppref parameter in the URL, does not reset anything; that cookie still expires on day 31. So the practical lifetime of the attribution identifier is a function of how often that person re-clicks your ads, not of how often they visit.
__obref is a fixed window from creation. Reuse does not extend it. A browser reference created today expires in 365 days regardless of how engaged that visitor is, and when it lapses the Pixel mints a new one — meaning the same browser becomes, from the Pixel's point of view, a new browser reference after a year.
The operational consequence: attribution coverage decays on two different schedules, and neither is the same as your configured attribution window. Which brings us to the sentence most likely to prevent a wrong conclusion.
Cookie lifetime is not the attribution window
OpenAI says it outright: "Cookie expiry is separate from conversion attribution windows and conversion-data retention."
This deserves emphasis because it is exactly the inference an analyst would otherwise draw. A 30-day cookie does not mean a 30-day click window, and it does not extend one. The same documentation page describes attribution separately: click-through attribution "uses the applicable configured click window", while view-through conversions "use a fixed one-day window after an eligible ad impression", with the click taking precedence when a conversion is eligible for both. View-through conversions are reported as a separate campaign-level metric and are not included in Conversions, and "CPA, post-click CVR, bidding, billing, and conversion optimization also remain click-through-based."
So there are now at least three clocks running in a ChatGPT Ads measurement setup, and conflating them will produce wrong reconciliations:
| Clock | Duration | What it governs |
|---|---|---|
__oppref cookie | 30 days, rolling on each ad landing | Whether the browser still carries the attribution identifier |
__obref cookie | 365 days from creation, not extended | Whether the browser reference persists |
| Configured click window | Advertiser-configured | Whether a conversion is credited to a click |
| View-through window | Fixed 1 day after an eligible impression | Whether a view-through conversion is counted, separately |
If your reported conversions dropped and your click window did not change, the cookie clocks are now a documented place to look — but they are a different place from the attribution settings.
What advertisers should do this week
Update your cookie table. If you publish a cookie notice, or maintain a cookie inventory for a DPO or a privacy review, __oppref and __obref now have citable names, purposes and durations from a first-party source. Previously any entry you wrote was an observation; now it is documented.
Check how your CMP categorises them. These are first-party cookies set on your own domain, which means a consent platform that blocks only third-party cookies will not touch them. The documented removal mechanism is oaiq("consent", false), and the Pixel's own consent model is worth reading alongside it: the Pixel "initializes consent to true by default unless you set it to false or the Pixel finds a stored denial", and when consent is false it does not send measurement-event pings, with blocked events not replayed later. If you operate under a consent regime that requires opt-in before any non-essential storage, the correct sequence is to call oaiq("consent", false) before oaiq("init", ...), and flip it to true only on grant. That ordering is in the documentation and is easy to get backwards.
Stop explaining attribution gaps with the wrong clock. Before today, teams debugging ChatGPT Ads conversion shortfalls had no documented client-side storage behaviour to reason about and tended to blame the attribution window. Now the honest diagnosis has more branches: a returning visitor without the ad parameter does not refresh __oppref, and Safari and other browsers can shorten first-party script-written cookie lifetimes well below the requested duration — OpenAI's own caveat that "browser restrictions or clearing cookies can shorten them" is doing real work in that sentence.
Do not rebuild your integration. Nothing here requires a code change to keep working. The section documents existing behaviour; it does not announce new behaviour. Treat it as disclosure, not as a migration.
The other documented change in the same window
One more substantive change landed on the same day, in the help centre rather than the developer docs, and it is worth recording because it changes who the billing rules apply to.
The Billing & Payment article was rewritten to scope almost every threshold statement to a newly named advertiser class. Where it previously said "Before campaigns can begin delivering, billing must be fully set up in Ads Manager Beta. This involves two steps", it now says "For self-serve card-billed accounts, this involves two steps." And it adds a sentence that did not exist before: "Eligible sales-managed advertisers on postpaid invoice terms follow their invoice billing arrangements instead of saved-card threshold charging."
The same qualifier now runs through the whole article — payment thresholds, threshold progression, failed-payment behaviour and the FAQ answers are all explicitly scoped to self-serve card-billed accounts. The mechanics for self-serve advertisers have not changed; what changed is that OpenAI has formally acknowledged a second billing track, and the payment-threshold model that everyone has been planning around is now documented as applying to only one of them. If you are on invoice terms through a sales contact, the threshold article no longer describes your account. Related: our earlier piece on ChatGPT Ads account spending limits covers the invoice-only spending-limit capability, which sits on the same postpaid-invoice track.
Two new help-centre articles also went live in this window covering first-party integrations — Set up ChatGPT Ads in HubSpot and Set up ChatGPT Ads for Shopify. Both state their integration is available wherever ChatGPT Ads is available, to all HubSpot customers and all Shopify merchants respectively. These were pre-announced in OpenAI's advertiser product-update email of 2026-09-16, which described the Shopify app as US-first with international availability "planned later this month"; the help-centre articles now published do not repeat that US-first restriction, so treat the geographic detail as the one point where the email and the documentation are not saying the same thing.
What this does not tell you
Discipline about the boundary of the source matters more than usual here, because cookie behaviour is the kind of topic where confident-sounding inference spreads fast.
The documentation does not say what oppref values look like, how they are generated, or how they map to a click on OpenAI's side. It does not say whether __obref is used for frequency, deduplication, or anything beyond being "a randomly generated browser reference for your website." It does not state a server-side retention period for the data these cookies help associate — it explicitly says cookie expiry is separate from conversion-data retention, without giving that retention figure. And it says nothing about behaviour in browsers that cap script-written first-party cookies, beyond the general caveat that browser restrictions can shorten the lifetimes.
We are not going to fill those gaps with reasoning. If OpenAI documents them, we will update this page and say when.
FAQ
What cookies does the ChatGPT Ads Pixel set?
Two first-party cookies on your own domain: __oppref, which stores the oppref attribution identifier from the landing page URL and expires 30 days after it is written, and __obref, a randomly generated browser reference that expires 365 days after creation.
Does visiting my site refresh the 30-day cookie?
Only if the visit carries a non-empty oppref URL parameter. The documentation is explicit that "reading the stored cookie on a visit without that parameter does not extend its expiry."
Does the 365-day cookie refresh on reuse?
No. The Pixel "reuses a valid stored reference without extending its expiry." A new 365-day clock starts only when the cookie is missing or invalid.
Is the cookie lifetime my attribution window?
No, and OpenAI states this directly: "Cookie expiry is separate from conversion attribution windows and conversion-data retention." Click-through attribution uses your configured click window; view-through uses a fixed one-day window after an eligible impression.
How do I remove these cookies for a user who declines consent?
Call oaiq("consent", false), which removes both cookies. Set consent to false before initialising the Pixel if you need opt-in before any storage.
Are these third-party cookies?
No. They are first-party cookies written on your website's own domain by the Pixel script, which means third-party-cookie blocking will not remove them and your consent platform must handle them explicitly.
Sources: developers.openai.com/ads/measurement-pixel, help.openai.com Billing & Payment, Set up ChatGPT Ads in HubSpot, Set up ChatGPT Ads for Shopify. All quoted text is OpenAI's. Analysis and the three-clock framing are Soku's. Verified 2026-09-21.
