你可能已經注意到了——那個在對話框裡突然出現的贊助卡片。

「Get Chinese Food Delivered」,上面寫著 Grubhub 的圖示和一句「Satisfy Your Cravings with Grubhub Delivery」,點下去直接在 ChatGPT 內嵌瀏覽器開啓外送網站。

如果你以為這只是 ChatGPT 在對話中間塞了一個廣告橫幅,那沒錯,但它不只這樣。背後藏著一套你我都似曾相識、卻又不太一樣的追蹤系統。

一位研究者在自己的行動裝置研究場域中,全程捕捉了 ChatGPT 廣告從投放、點擊、到回傳的全過程。每一層加密、每一個 cookie、每一條 server-side token,都被拆開來看了。

以下是他看到的東西。


廣告怎麼出現在你的對話裡?

當你傳送一則訊息給 ChatGPT,後端會開一條 SSE(Server-Sent Events)串流,回傳網址是 chatgpt.com/backend-api/f/conversation。大部分 event 是 model 產出的文字內容——但有一些不是。

SSE 串流中可能會出現這樣的 event:

event: delta
data: {
  "type": "single_advertiser_ad_unit",
  "ads_request_id": "069e89b3-c038-7764-8000-6e5a193e5f69",
  "ads_spam_integrity_payload": "gAAAAABp6Js_<...>",
  "preamble": "",
  "advertiser_brand": {
    "name": "Grubhub",
    "url": "www.grubhub.com",
    "favicon_url": "https://bzrcdn.openai.com/cabfae7ead26b03d.png",
    "id": "adacct_6984ed0ba55481a29894bb192f7773b4"
  },
  "carousel_cards": [{
    "title": "Get Chinese Food Delivered",
    "body": "Satisfy Your Cravings with Grubhub Delivery.",
    "image_url": "https://bzrcdn.openai.com/...",
    "target": {
      "type": "url",
      "value": "https://www.grubhub.com/?utm_source=chatgptpilot&...&oppref=gAAAA<...>&olref=gAAAA<...>",
      "open_externally": false
    },
    "ad_data_token": "eyJwYXlsb2<...>"
  }]
}

你看到的結果就是一個帶有品牌 Logo、標題和圖片的卡片式廣告。但這背後藏著好幾層設計:

還有一個細節:每一則廣告內含四個 Fernet 加密 token。 一個是 ads_spam_integrity_payload,兩個分別叫 opprefolref,還有一個 base64 包裝的 ad_data_token。後面會逐一拆開它們各自負責什麼。


廣告是怎麼選的?靠的是對話內容

研究者用同一組帳號,在六次不同的對話中,看見了六家完全不同的廣告主:

對話主題 出現的廣告
規劃北京行程(長城、故宮) Grubhub — 「Get Chinese Food Delivered」
預訂北京旅遊行程 GetYourGuide — 故宮行程
查詢北京航班 Axel — 旅遊關鍵字廣告
NBA 季後賽 Gametime — 賽事門票廣告
春季流行趨勢 Aritzia — 購物廣告
生產力/簡報 Canva — 軟體廣告

這其實就是情境式廣告投放(contextual targeting)——根據你正在聊的話題決定要展示哪個廣告,而不是靠你的個人檔案或歷史。它和你小時候在 Google 搜尋「東京機票」然後看到滿版日本旅遊廣告的原理一樣,只差在運算的上下文不同。

不過研究者也指出,這次測試本身無法完全排除是否也使用了對話歷史。至少從目前看到的證據來看,話題當下的語意是最主要的觸發因子。


四個 token 的追蹤鏈

這才是整篇文章最精彩的部分。每一則廣告出廠時帶著四個 Fernet 加密的資料塊,各有其職責。

1. ads_spam_integrity_payload

這個 token 只存在於 SSE 串流資料結構中,不會出現在點擊網址上。它的作用是伺服器端偽造點擊檢測——當使用者點擊廣告後,ChatGPT 後端可以比對這個 payload 是否合法,確認點擊是真實的,而不是機器人或惡意腳本的偽造請求。

2. oppref — 轉換追蹤的主幹

這是整條鏈中最關鍵的 token。它同時出現在點擊網址的 query 參數中,也被 OAIQ 像素 SDK 讀取後原封不動地寫入瀏覽器的 __oppref cookie,存活時間 720 小時(30 天)

意思是:你點擊一個廣告進到商家網站後的 30 天內,任何透過 OAIQ SDK 回傳的事件,都會附帶這個 oppref 值。這讓 OpenAI 可以知道——這個購買行為是從哪一次 ChatGPT 廣告點擊開始的。

3. olref — 印象端紀錄

oppref 成對出現在點擊網址上,但它在研究者觀察的 SDK 中沒有被寫入 cookie。它的用途最可能是 OpenAI 伺服器端的「離站連結參考紀錄」(outbound-link-reference),也就是在你點下去的瞬間,OpenAI 自己的伺服器就先記錄了一筆事件——不依賴用戶端的 cookie。

4. ad_data_token — base64 包裝的附加 token

這個 token 放在 SSE 資料的 ad_data_token 欄位中,內容是 base64 編碼的 JSON,裡面包著另一個 Fernet token。它的角色推測是在點擊發生時,由伺服器端與 ads_spam_integrity_payload 進行交叉比對。

關於 Fernet 加密的時間戳

Fernet 格式的前 9 個位元組是公開的:第 1 個 byte 是版本 0x80,後面 8 個 byte 是大端序 Unix 時間戳。這意味著不需要 OpenAI 的金鑰,任何人都可以還原出任何一個 token 的生成時間。

研究者用這招還原了一次 Home Depot 廣告的 token 時間:

import base64, struct, datetime
b = base64.urlsafe_b64decode("gAAAAABp7fdA" + "==")
print(datetime.datetime.utcfromtimestamp(struct.unpack(">Q", b[1:9])[0]))
# → 2026-04-26 11:30:08 UTC

而瀏覽器實際載入商家頁面的時間是 11:31:43——從 token 產生到使用者真正到達網站,只花了 95 秒。 這個延遲非常低,代表廣告點擊後的整個重定向鏈幾乎是即時的。


商家端的追蹤:OAIQ SDK

當使用者點擊廣告卡片,瀏覽器會開啓商家的網址,網址中包含 opprefolref 兩個參數:

https://www.grubhub.com/?utm_source=chatgptpilot&...&oppref=gAAAA<...>&olref=gAAAA<...>

商家頁面載入後,會執行 OAIQ SDK(版本 0.1.3):

<script src="https://bzrcdn.openai.com/sdk/oaiq.min.js"></script>
<script>
  oaiq('init', { pid: '<merchant pixel ID>' });
  oaiq('measure', 'contents_viewed', { ... });
</script>

SDK 初始化時會做三件事:

  1. 從網址讀取 oppref,寫入第一方 cookie __oppref(TTL 720 小時)
  2. 設定探測 cookie __oaiq_domain_probe,確認 cookie 寫入功能正常
  3. 每次呼叫 measure 時,POST JSON 到 OpenAI 的像素端點:
POST https://bzr.openai.com/v1/sdk/events?pid=<merchant>&st=oaiq-web&sv=0.1.3

從這裡你可以看到一個完整的歸因迴圈:

使用者傳送訊息 → SSE 回傳含廣告的 event → 
廣告卡片渲染 → 使用者點擊 → 
Fenet token 在點擊網址中傳遞 → 
OAIQ SDK 將 oppref 寫入 cookie → 
每次事件回傳都帶著 oppref → 
OpenAI 後端可以從 oppref 解出原始廣告點擊的時間和上下文

這套系統和 Google Ads、Facebook Pixel 的歸因框架在本質上沒有不同。 最大的差別是觸發點——歸因循環的起點不是搜尋引擎結果頁或社群平台動態牆,而是 ChatGPT 對話中的一段回答。


如果你想封鎖 ChatGPT 廣告

研究者給出了兩個具體的阻擋方向:

加入過濾清單的域名:
bzrcdn.openai.com — 廣告素材和 SDK 的 CDN
bzr.openai.com — 像素事件回傳的端點

檢查的 cookie 名稱:
__oppref — 30 天 cookie,存著歸因 token
__oaiq_domain_probe — 探測 cookie,確認 SDK 初始化正常

如果你是技術使用者,在瀏覽器或廣告封鎖工具中封鎖這兩個域名,基本上就能阻止 ChatGPT 廣告的歸因鏈路閉合。不過要注意:這只會影響商家端的追蹤回傳——廣告仍然會出現在對話中,因為它是直接從伺服器端推送的 SSE event,與用戶端的廣告封鎖無關。


這件事為什麼值得關注

從產品角度來看,ChatGPT 的廣告系統設計其實相當成熟:情境式投放、多層 token 加密、第一方 cookie 歸因、分離的廣告素材託管與事件回傳——所有 Google Ads 和 Meta Ads 的標準元件,它都有,只是換了一個使用場景。

從隱私角度來看,這套系統也展示了 OpenAI 目前對廣告歸因的設計哲學:他們選擇了去中心化的歸因方式,把 token 交給商家端的第一方 cookie 來管理,而不是讓 OpenAI 本身持有一個跨站追蹤的 ID。 也就是說,OpenAI 不會知道進到商家網站後你買了什麼——它只知道某個點擊事件發生了。但商家 OAIQ 回傳的事件,則可以讓 OpenAI 知道「這個點擊最終產生了一個 purchase」。

這和 Google 的「強化轉換」(enhanced conversions)或 Meta 的「離線事件回傳」在架構上很相似,只是規模還小得多。

對於開發者而言,這套系統最大的看點是SSE 中嵌入廣告 payload 的架構——它不是把廣告當作額外的 API 呼叫,而是直接混入模型輸出串流中。這意味著 OpenAI 的廣告插入時機點和頻率控制,完全掌握在送出 SSE 資料的後端邏輯中,使用者端無法透過一般的廣告封鎖器來攔截(因為那不是一個獨立的請求)。

所以回到開頭的問題:ChatGPT 怎麼投放廣告?

答案是——用一套你不看原始碼就不會發現的,混合了情境語意比對、Fernet 加密、SSE 內嵌、和第一方 cookie 歸因的完整系統。 和你熟悉的所有廣告平台一樣精密,只是在一個全新的對話框裡。

如果你想深入探索,打開瀏覽器開發者工具,注意 SSE 串流中的 single_advertiser_ad_unit event——然後追著那些 gAAAAAB... 開頭的 token 下去,你會發現一個比想像中完整得多的廣告生態。


本文資訊來源:一篇由獨立研究者發布的詳細技術分析,研究者在自己的行動裝置研究場域中捕捉了完整的 ChatGPT 廣告歸因流程。所有技術觀察來自實際流量攔截。