One ChatGPT tracking cookie travels where the others cannot.
It is issued under analytics consent, not advertising consent, and it follows visitors onto other companies' sites.
On 20 September 2026, Buchodi's Threat Intel published a teardown of the ad collector OpenAI runs at bzr.openai.com, the host behind advertising inside ChatGPT.
The researcher reproduced the mechanism on a phone, verified it with two capture methods, and cross checked it against traffic covering 936 advertiser pixels across 1,029 hostnames.
Companies that buy ads in ChatGPT install OpenAI's measurement pixel on their own sites, and the pixel sends an identifier back to OpenAI that is joined to the visitor's ChatGPT account.
The story is not that OpenAI sells ads, it is that the only OpenAI cookie built to cross sites is the one handed to people who allow analytics.
How the ChatGPT tracking cookie travels
The identifier begins on chatgpt.com. The client generates 16 random bytes and asks a backend endpoint for a signed token, and the reply is a JWT addressed to the collector.
Inside that token sit the account subject, a short lived identifier, and a consent decision that reads analytics allowed in every token the researcher decoded. The token expires about a minute after it is issued, which is why the collector trades it for a durable cookie instead of passing it around.
The client posts the token to the collector, which answers with a cookie called __obi, scoped to .openai.com, marked Secure and given a lifetime of one year. That cookie also carries the one attribute a browser needs before it will attach the cookie to a request coming from another company's page.
OpenAI documents the pixel that ends up on those pages in its Ads developer documentation.
Once the cookie is in the jar, three request types from an advertiser page carried it in the captures: the script load that pulls the pixel, conversion events posted back to the collector, and the SDK path that is meant to send no credentials at all.
The script load is the one to think about. Browsers attach cookies to that request before any of OpenAI's code runs, so loading the pixel is enough to disclose the identifier, and every other OpenAI cookie was blocked on the same requests.
Checking any of this on your own device means reading cookies and tokens by hand, and authentication and authorization is the skill underneath.
What the pixel carries back
The SDK also lifts identity out of the page it runs on. OpenAI's own labels separate four sources: values the advertiser passes on purpose, and values scraped from form fields, rendered page text and the tag manager bus.
The bus was the largest source of email addresses, because the SDK replaces the tag manager's push function and finds renamed layers through script parameters.
Scraped identity outnumbered advertiser supplied identity in the observed traffic by 685 events to 255. Email, phone, first and last name are hashed before transmission, while country, region, city and postal code travel in the clear.
Postal code was the most harvested form field, at 100 events across 28 sites. One path that reached the collector pointed at a medical condition, another at a debt funnel, and another at a litigation intake form.
Automatic matching was enabled for 638 of the 881 pixels with a known setting, including every credit and lending advertiser observed, and that setting lives in OpenAI's Ads Manager.
Query strings were stripped before sending, and a denylist excludes passwords, single use codes, card numbers, social security numbers, dates of birth, medical history and court fields.
Advertisers cannot see any of this from their side, because the cookie belongs to a domain their scripts cannot read. The measurement half of it is marketing work rather than security work, and the digital marketing competence check covers how conversion data gets assembled.
On the researcher's own device, one identifier reached 12 commercial sites under 13 pixel IDs, and every one of those requests came back accepted.
What to change now
1. Audit egress from the assistant client, not just from the office network. A chat request and a pixel request leave the same browser profile, so monitoring that only watches a proxy or a firewall will miss an identifier riding out on a script tag.
2. Stop treating analytics consent as the harmless half. Every token decoded carried analytics allowed, OpenAI's cookie policy files __obi as an analytics cookie, and the value persists for a year. If a notice promises that refusing marketing stops cross site tracking, the notice is wrong.
3. Ask what your own pixel collects before you ship it. Scraped identity beat supplied identity here because the SDK reads form fields and tag manager layers, and that comparison only looks safe when a single advertiser's own values are the only ones measured.
Two caveats are worth holding onto. The identifier is observed travelling, and the join to an account happens on OpenAI's side, which the researcher did not watch happen.
The mechanism also does not work in Safari or in any browser running on WebKit, because those block third party cookies outright, and only about one ChatGPT session in five produced a token in the first place.
OpenAI acknowledged the researcher's questions on 14 September and did not answer them, and the script load finding came after the questions were sent.
What this changes for your next audit
The old assumption was that the interesting thing about an AI assistant is what a person types into it, and that advertising is a separate discussion about a separate product.
The structural equivalent has existed in advertising for years: a logged in account, a cross site pixel, and off site conversions resolved to a profile.
What is new is who holds the profile, and this cookie sits on the same account that holds the conversations people would not post on a social network.
What this analysis shows is narrower and harder to dismiss. The client is a first party sensor on the open web, and the consent screen splits analytics from marketing in a way the cookies do not respect.
The pattern is familiar from other product surfaces that became data channels, including the APIs that leaked a model's value through ordinary traffic.
What would have to appear in a browser's network log before your team refused to load a vendor's pixel?