本文要点
- 讨论对象从ChatGPT内广告展示转到站外转化像素。
- 隐私风险从匿名广告归因转为可能关联ChatGPT账号。
- OpenAI文档中的Pixel能力需要和obi调查一起审计。
阅读辅助
先看数字、证据和来源，再读正文。
Buchodi称ChatGPT会为广告同步生成obi并绑定账号或匿名主体。
2026-08-27（背景） · Buchodi称OpenAI Pixel SDK 0.1.31曾采集姓名和地理字段，随后版本收窄范围。
这篇调查的新闻点很窄，也很敏感：Buchodi在2026-09-20 15:17 UTC发布文章，称OpenAI广告收集器会设置名为__obi的Cookie，并且这个值会在普通网站加载OpenAI广告像素时随请求发往OpenAI。
可确认的新鲜事实是这篇独立调查本身。文章给出抓包路径、JWT字段、Cookie属性、广告像素请求类别和观察样本；OpenAI官方Measurement Pixel文档则确认，ChatGPT Ads Measurement Pixel确实是用于测量可归因于ChatGPT广告的网站事件。
需要先划清边界。Buchodi没有观察到OpenAI服务端实际把这些事件合并回ChatGPT账号，也没有拿到OpenAI内部数据处理记录。OpenAI在文中只通过Support确认收到问题并会内部转交，未回答作者关于__obi分类和同意边界的两个问题。
这条线索对隐私、安全和广告合规团队的价值，在于它把AI聊天产品拉进传统广告像素审计。ChatGPT承载的用户意图比普通内容平台更敏感；若站外商业行为能与聊天账号标识同域关联，企业采购和监管评估都要重新检查数据边界。
调查链路：从ChatGPT到广告像素
Buchodi描述的机制分三步。第一步发生在chatgpt.com，客户端生成16个随机字节，然后调用/backend-api/bazaar/obi/sync-token；如果用户未登录，则走/backend-anon/路径。后端返回一个RS256签名JWT，字段包括iss: chatgpt-wadi、aud: bzr.openai.com、purpose: obi_sync、operation: set、consent_decision: analytics_allowed、subject_type、sub和obi。
第二步是Cookie落盘。文章称客户端把JWT跨站POST到bzr.openai.com/v1/obi/sync，返回的Set-Cookie为__obi，并带有Domain=.openai.com、HttpOnly、Max-Age=31536000、Path=/、SameSite=None和Secure。作者强调，JWT里的obi值和Cookie值相同。
第三步发生在广告主网站。OpenAI的Measurement Pixel文档要求广告主在页面中加载https://bzrcdn.openai.com/sdk/oaiq.min.js，并通过bzr.openai.com发送转化事件。Buchodi称，在一台带有__obi的Chrome Android手机上，多个来自广告主页面的OpenAI请求携带了这个Cookie。
| 请求或行为 | Buchodi观察到的Cookie状态 | 能证明什么 | 不能证明什么 |
|---|---|---|---|
GET bzrcdn.openai.com/sdk/oaiq.min.js | 携带__obi | SDK加载请求本身可能带上OpenAI域Cookie | 不证明SDK代码主动读取了__obi |
POST bzr.openai.com/v1/sdk/events带obref | 携带__obi | 转化事件请求可同时带站点事件和OpenAI Cookie | 不证明事件已合并进账号画像 |
POST bzr.openai.com/v1/sdk/events裸请求 | 携带__obi | 作者称无凭据路径也未阻止浏览器附带Cookie | 仍依赖作者单设备抓包 |
GET bzrcdn.openai.com/pixel-config/... | 文中称没有Cookie header | 可作为同域请求行为的对照 | 不说明其它地区或浏览器一致 |
这里最容易误写的地方，是把“请求携带Cookie”直接写成“OpenAI已经知道每个用户浏览了什么”。更稳妥的表述是：作者观察到一个与ChatGPT账号或匿名主体相关的__obi可随部分站外广告像素请求发往OpenAI；服务器端是否完成身份合并，公开材料尚未证明。
Cookie属性为什么关键
Domain=.openai.com意味着Cookie适用范围覆盖OpenAI主域下的子域。HttpOnly意味着普通页面脚本不能直接读取这个Cookie值，但浏览器仍可在匹配的HTTP请求中自动携带它。Max-Age=31536000对应约1年有效期。
SameSite=None和Secure是这组属性里最敏感的组合。MDN文档说明，SameSite=None用于允许Cookie在跨站请求中发送，并且必须同时设置Secure。换句话说，这不是一个只在同站导航里工作的保守Cookie属性。
WebKit的Tracking Prevention文档提供了另一个限制背景：Safari的ITP默认阻止所有第三方Cookie，且无例外；第三方Cookie访问只能通过Storage Access API等机制获得。Buchodi也因此把复现范围限定在Chrome Android，并明确说Safari ITP和Chrome iOS不按同一路径运作。
| Cookie属性 | 中文解释 | 对本案的意义 | 需保留的边界 |
|---|---|---|---|
Domain=.openai.com | 覆盖OpenAI主域及子域 | 可让bzr.openai.com相关请求携带同域Cookie | 不能推出第三方站点能读取该值 |
HttpOnly | JavaScript不可直接读 | 广告主页面脚本理论上看不到__obi | 浏览器仍会自动附带到匹配请求 |
SameSite=None | 允许跨站场景发送 | 符合第三方像素请求携带Cookie的条件 | 具体发送仍受浏览器策略影响 |
Secure | 仅HTTPS传输 | 与SameSite=None组合满足现代浏览器要求 | 不代表数据用途已被证明 |
Max-Age=31536000 | 约一年有效期 | 标识具备长期归因能力 | 用户清Cookie或浏览器限制可缩短 |
这也是为什么文章把__obi和其它OpenAI Cookie分开讨论。Buchodi称，在相同广告主页面请求中，oai-did和oaicom-stable-id因SameSite=Lax被阻止，登录会话Cookie因域名不匹配被阻止，只有__obi被发送。
样本显示的覆盖面
Buchodi给出的样本规模不小，但仍是作者掌握的观察样本。文章称，作者用两种独立抓包方法复现了完整机制，并交叉检查数月流量，覆盖936个不同广告像素和1,029个主机名。这个数字说明它不是单个网站误装代码，但还不是全网覆盖率统计。
令牌样本也值得看。作者称解码了932个sync token，其中736个为account_user，196个为anonymous。匿名主体被描述为每台设备一个，并至少持续27天。这说明风险不只发生在登录态账号，也可能覆盖未登录访问路径。
作者还给了两个跨广告主传播指标。其一，一台设备上的一个__obi值被发送到12个商业网站下的OpenAI请求，涉及13个不同pixel ID。其二，在更大样本中，30个不同__obi值里有12个出现在多个广告主请求下，其中一个出现在10个广告主下。
这些数字必须保留口径：它们来自Buchodi的独立调查，不是OpenAI透明度报告，也不是监管披露。它们可以说明“该机制在作者样本中跨多个广告主出现”，不能说明所有ChatGPT用户、所有广告主或所有浏览器都会出现同样行为。
| 数字 | 原文口径 | 安全中文表述 |
|---|---|---|
| 936 pixels | observed traffic covering 936 distinct advertiser pixels | 作者观察样本覆盖936个不同广告像素 |
| 1,029 hostnames | across 1,029 hostnames | 样本横跨1,029个主机名 |
| 932 tokens | Across 932 decoded sync tokens | 作者解码932个同步令牌 |
| 736 account_user | 736 carried subject_type: account_user | 其中736个标为account_user |
| 196 anonymous | 196 carried anonymous | 其中196个标为anonymous |
| 12 of 30 | 12 of 30 distinct __obi values appeared under more than one advertiser | 30个__obi值中12个出现在多个广告主下 |
OpenAI文档提供的背景
OpenAI Developers文档把Measurement Pixel定义为一个浏览器SDK，用于测量可归因于ChatGPT广告的网站事件。文档示例要求广告主把脚本放进页面head，初始化pixelId，并在转化发生时调用oaiq("measure", ...)。
同一文档还说明，Pixel支持点击归因和在可用账户下的浏览归因；浏览归因窗口是固定1天，点击归因使用配置的点击窗口。文档强调浏览归因不会改变浏览器端集成或事件payload，也不会进入Conversions这项点击转化总数。
更敏感的是user data和automatic advanced matching部分。文档允许广告主在初始化时传入用户对象，包括邮件、手机号、external ID、姓名、国家、城市、地区和邮编。邮件、手机号、external ID和姓名需在浏览器里SHA-256哈希；国家、城市、地区和邮编按文档字段发送。
文档还称，当automatic advanced matching启用时，OpenAI Pixel会自动检测网站中受支持的客户信息，在浏览器里标准化并哈希后随转化事件发送，原始客户信息不会通过自动匹配发送。Buchodi的文章则进一步声称，SDK会从表单字段、页面文本和tag-manager bus等位置收集身份线索，并把来源区分为in、fm、ht和js。
这两组材料的关系要写准。OpenAI文档能证明Pixel产品存在、用途是广告转化测量、支持用户数据和自动高级匹配；Buchodi调查提出的问题是，在这些事件之外，__obi是否把站外事件与ChatGPT账号或匿名主体连接起来。前者是官方功能说明，后者仍是独立研究者观测。
同意与分类的争议点
Buchodi把同意边界列为核心问题。作者称，OpenAI Cookie Policy把__obi列在Analytics cookies下，有效期为一年，适用chatgpt.com和openai.com。作者还称，解码到的每个同步令牌都带有consent_decision: analytics_allowed。
这个细节不能改写成“OpenAI绕过营销同意”。更准确的说法是：按作者观察，允许analytics但拒绝marketing的用户仍可能获得__obi；作者已向OpenAI询问为什么把__obi归类为analytics cookie，以及这种同意组合下是否仍会设置它。公开材料里尚未看到OpenAI的实质回答。
OpenAI Pixel文档的consent段落也有一层相关背景。文档写明，如果需要同意才能追踪转化事件，广告主可先调用oaiq("consent", false)，用户授权后再设为true；Pixel默认consent为true，除非广告主设为false或Pixel找到已存储的拒绝。
这意味着广告主侧和ChatGPT侧可能存在两套同意语境：一个是广告主网页是否允许Pixel发送事件，另一个是ChatGPT或OpenAI域内是否允许生成和同步__obi。Buchodi调查真正要求OpenAI解释的，就是这两套语境如何相互隔离。
限制比结论更重要
这篇稿不能忽略限制。Buchodi明确写到，观察环境是Chrome for Android；Safari ITP阻止所有第三方Cookie，Chrome iOS运行在WebKit上，因此同一机制在iOS浏览器上不按相同方式运作。桌面Chrome没有测试。
另一个限制是触发概率。作者称大约每5个ChatGPT会话里只有1个会产生sync token，ChatGPT移动网页客户端也会在没有同步的情况下投放广告。因此读者照着步骤复现时，可能看到Pixel触发但没有Cookie附带。
最关键的限制是服务端合并不可见。文章写明，202只代表collector接受了带Cookie的事件；OpenAI是否把事件解析到账号、如何保留、如何用于归因或个性化，作者没有观察到。这个限制决定标题必须写“独立调查称”，而不是写成OpenAI已被证实跟踪所有站外浏览。
| 限制项 | Buchodi说法 | 对报道置信度的影响 |
|---|---|---|
| 浏览器范围 | 观察于Chrome for Android | 不能外推到Safari、Chrome iOS或桌面Chrome |
| 触发概率 | 约五分之一会话产生sync token | 复现结果可能依账号、地区和会话状态变化 |
| 服务端合并 | the join is not observed | 只能证明请求携带，不能证明账号画像已更新 |
| OpenAI回应 | Support确认收到并内部转交 | 尚无实质解释或反驳可引用 |
| 样本来源 | 作者自有抓包和数月观察 | 需要第三方复现或监管问询提高置信度 |
对企业和广告主的影响
广告主面临的第一类风险是披露义务。OpenAI Pixel文档已经要求网站加载SDK、发送转化事件，并可传入或自动匹配用户信息。若同一请求还会携带OpenAI域名下的__obi，广告主隐私政策是否足够说明这条数据流，就需要重新审查。
企业采购ChatGPT相关产品时，关注点也会变化。过去的合规问卷多问聊天内容是否用于训练、企业数据是否隔离、管理员能否控制日志。广告像素问题要求再加一组问题：OpenAI广告业务的账号标识、Cookie、归因数据和ChatGPT使用身份之间是否有技术隔离。
安全团队则应把这件事当成可操作的审计清单。浏览器开发者工具或代理抓包可以检查bzrcdn.openai.com脚本请求、bzr.openai.com事件请求、Cookie header和consent状态。若公司网站安装了OpenAI Pixel，还需要核对是否启用automatic advanced matching。
对普通用户来说，最现实的防护仍是浏览器和同意设置。Safari的ITP、第三方Cookie限制、定期清理站点数据和拒绝不必要的analytics consent，都可能改变实际发送行为。不过这不是用户独自承担的责任；广告主和平台方更应解释默认设置和数据用途。
早报判断是，这条调查提出了一个应被公开解释的架构问题。AI聊天账号、广告点击归因、站外转化事件和浏览器Cookie放在同一域名体系里时，传统广告技术的默认设计会遇到更高的隐私预期。
ChatGPT不是普通广告平台。用户在聊天产品里留下的是问题、计划、困境和工作内容；这些信号天然比新闻站或电商站的浏览行为更敏感。因此，即便OpenAI最终说明__obi只用于有限测量，它也需要解释为什么analytics consent足以覆盖这条链路，以及如何防止广告归因数据回流到聊天身份和个性化系统。
广告主也不能把责任完全推给SDK供应商。只要页面加载第三方测量代码，广告主就是用户数据流的一部分。OpenAI文档让安装门槛很低，但合规门槛不会因此降低；高风险行业尤其需要在上线前做Cookie、CSP、consent和数据字段审计。
现阶段最克制的结论是：Buchodi给出了足够具体的抓包线索，值得隐私团队复核；但公开证据还不足以认定OpenAI已在服务器端把站外行为合并进ChatGPT账号画像。下一步需要的是OpenAI的正式说明、第三方复现和广告主侧的透明披露。
接下来要看什么
平台回应是最关键的下一步。外部需要看到__obi的具体用途、保存周期、同意口径、数据隔离和删除机制，而不只是“保护隐私”的原则声明。若OpenAI坚持它是analytics cookie，就需要说明为什么它会出现在广告像素请求路径里。
第三方复现要覆盖更多环境。Chrome Android之外，桌面Chrome、Edge、Firefox、不同地区同意弹窗、登录和未登录状态，都需要独立测试。复现报告应记录浏览器版本、Cookie设置、地区、账号状态、consent选择和请求样本。
广告主披露同样需要补齐。OpenAI Pixel文档已经公开了安装和用户数据字段，广告主若启用Pixel，隐私政策和CMP配置应说明发送到OpenAI的事件、标识和哈希字段。若广告主不知道__obi会随请求发送，这本身就是供应链透明度问题。
监管反应会决定这件事是否进入正式问询。AI聊天产品进入广告归因链后，监管者可能不只问“是否用了Cookie”，还会问聊天身份、广告展示、站外转化和模型个性化之间是否隔离。Buchodi这篇单源调查还不能给出最终答案，但它把问题问到了正确的位置。