OpenAI uses ad cookie to link external browsing to ChatGPT accounts

A technical study published by the newsletter Buchodi's Threat Intel describes how OpenAI runs a cross-site tracking mechanism that links a user's browsing on third-party pages to their ChatGPT account. Researcher Jamie Larson reproduced the entire flow on an Android phone, validated it with two independent traffic capture methods, and cross-checked the data against months of observed traffic covering 936 distinct advertiser pixels across 1,029 domains. The full report is available at Buchodi's Threat Intel.

The mechanism is named __obi, a cookie scoped to .openai.com that originates inside ChatGPT itself and is sent back to OpenAI when the user visits advertiser sites running the company's measurement pixel, the same model used by Meta and Google for years. The difference, according to the researcher, is running this engineering on top of a chat product that receives far more sensitive information than a social network.

How the token is born inside ChatGPT

The process starts on chatgpt.com itself. The client generates 16 random bytes and calls POST /backend-api/bazaar/obi/sync-token (or the /backend-anon/ route when the user is logged out). The backend returns a JWT signed with RS256:

{
 "iss": "chatgpt-wadi",
 "aud": "bzr.openai.com",
 "purpose": "obi_sync",
 "operation": "set",
 "consent_decision": "analytics_allowed",
 "consent_policy_version": "user_granular_consent_v1",
 "sub": "«64-hex subject, the account»",
 "obi": "«22-character identifier»",
 "exp": "«iat + 60s»"
}

bzr is the internal name of OpenAI's ad platform ("bazaar"); wadi is the service that issues the token. The sub field is the user's account, obi is the tracking identifier, and the token expires in 60 seconds, enough to bind the two values and send them to the collector's domain. The client then makes a cross-site POST to bzr.openai.com/v1/obi/sync with that token, and the response sets the cookie:

Set-Cookie: __obi=«value»; Domain=.openai.com; HttpOnly;
 Max-Age=31536000; Path=/; SameSite=none; Secure

The SameSite=none setting combined with Secure is exactly what a cookie needs to be sent on third-party requests. It's the only way to guarantee it comes back when the browser loads a script on another domain. According to the study, __obi is the only OpenAI identifier configured this way: every other cookie from the company (oai-did, oaicom-stable-id, session cookies) was blocked on the same requests, either by SameSite=Lax or by domain mismatch.

What comes back from partner sites

Any company that buys ads on ChatGPT installs a small piece of OpenAI code on its own site, oaiq.min.js, hosted at bzrcdn.openai.com, following the same pattern as Meta and Google's pixels. When that tag loads, the browser already attaches the __obi cookie to the very <script src> request that downloads the SDK, before any consent logic runs. In other words: even the SDK path designed not to send credentials fails, because the browser exposes the identifier on the mere loading of the script.

The report documents three classes of requests that leave the advertiser's page for OpenAI and tested whether each one carried the cookie:

Beyond the identifier, the SDK also collects identity data from the advertiser's own page, split into four categories that OpenAI labels internally: in (what the advertiser deliberately passes), and fm, ht and js (what the SDK scrapes from forms, rendered text, and the tag manager's data bus). In the observed traffic, scraped data outnumbered deliberately supplied data by 685 events to 255.

The largest source of email is Google Tag Manager itself: the SDK overwrites window.dataLayer.push, also reads adobeDataLayer, and locates renamed GTM layers by parsing the l= parameter of the gtm.js tag. Email, phone, and name are converted into a SHA-256 hash before being sent, but country, region, city, and postal code go out in plain text. Postal code was the most collected field: 100 events across 28 different sites. URLs are reduced to origin plus path (without the query string), but the path alone was already enough to reveal, in the observed data, a medical condition, a debt renegotiation funnel, and a lead-capture form for a lawsuit.

Classified as "analytics," not "marketing"

OpenAI's cookie policy lists __obi under the Analytics category, valid for one year, on chatgpt.com and openai.com. It's the only entry in that section, described as something that helps the company understand "how its services are used." Except OpenAI operates analytics and marketing consent as two separate choices (oai_consent_analytics and oai_consent_marketing), and all 932 tokens decoded in the study carried consent_decision: analytics_allowed. In practice, a user who accepts analytics and declines marketing receives the same cookie used for cross-site ad attribution.

The researcher sent the mechanism and two questions to press@openai.com and privacy@openai.com on September 14: why __obi is classified as analytics, and whether someone who accepts analytics and declines marketing still receives the cookie. The reply came from OpenAI support, confirming receipt and stating that the observations would be forwarded internally, without answering either question.

Where the mechanism works (and where it doesn't)

The behavior was observed on Chrome for Android. Safari's Intelligent Tracking Prevention blocks all third-party cookies, and Chrome on iOS runs on the WebKit engine, so the mechanism simply doesn't operate on any iOS browser. Desktop Chrome wasn't tested. Even in the environment where it works, syncing isn't constant: roughly one in every five ChatGPT sessions produced a token, and the mobile web client sometimes shows ads without syncing any cookie at all.

Another point relevant to anyone dealing with privacy: the tracking works even when the user is logged out. Of the 932 decoded tokens, 736 carried subject_type: account_user and 196 carried anonymous. The anonymous identifier is as stable as the account one, persisting for at least 27 days on the same device. In one test, a single __obi value was sent to OpenAI from 12 commercial sites under 13 distinct pixels, including Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera, and SeatGeek, all accepted with an HTTP 202 response.

What this changes for those who build and instrument sites

For engineering and product teams in Brazil that already deal with the LGPD (Brazil's data protection law), the case is a concrete reminder of two real technical problems. The first is dataLayer exposure: if the marketing team plugged ChatGPT's ad SDK (OpenAI is already testing Sponsored Agents and launched the ChatGPT Ads Manager, as iMasters showed in recent coverage) into the same dataLayer used by GTM, any field placed there, including email and phone numbers typed into forms, can be scraped by third-party scripts without the dev team knowing. It's worth auditing which scripts read window.dataLayer and adobeDataLayer in your stack, and not assuming that "hashing before sending" solves the problem of plain-text data like postal code and city.

The second is consent governance: classifying a cross-site tracking cookie as "analytics" instead of "marketing" is a choice that directly affects teams that need to justify legal bases for data processing under the LGPD. If a third-party vendor (in this case, OpenAI itself, via a pixel installed on the client's site) mislabels the cookie's purpose, whoever installed the script, not whoever supplied it, is the one accountable for the data processing that's live.

The Buchodi's Threat Intel report makes clear that the advertiser installing the pixel has no visibility into this: __obi belongs to a domain the advertiser's script can't read, so whoever puts the tag live has no way of knowing they're resolving visitors to a ChatGPT account identity on the other side. OpenAI did not respond to the technical questions sent by the researcher by the time the study was published, and the case remains open.