Privacy Sandbox 究竟替代咗咩

第三方 Cookie 承擔著四項獨立嘅廣告功能：基於興趣嘅定向、再營銷、轉化衡量同頻次控制。Privacy Sandbox 將呢啲功能拆分為獨立嘅 API，每個 API 各有自己嘅同意要求。

Topics API——基於興趣嘅定向

Topics API 為每個瀏覽器分配一小組粗粒度興趣話題——每週約 五個話題，從包含數百個類別嘅精選分類體系中提取。當出版商調用 document.browsingTopics() 時，瀏覽器最多返回三個話題，廣告技術生態系統可以此進行情境化個性化，而唔需要任何跨站標識符。話題喺本地計算、儲存喺設備上，每週輪換，並受 chrome://settings/adPrivacy 中用戶控制嘅約束。

Protected Audience API——再定向同再營銷

Protected Audience（前身為 FLEDGE）喺無需共享跨站標識符嘅情況下保留咗再定向能力。廣告主喺其自有網站上將用戶加入興趣群組；當用戶訪問參與嘅出版商網站時，設備端競價喺 Fenced Frame 中運行並選出廣告素材。獲勝廣告展示時，出版商並唔知道匹配嘅係哪個興趣群組。

Attribution Reporting API——轉化衡量

Attribution Reporting 針對部分衡量用途替代咗轉化像素。佢支持事件級報告（含噪聲、有損耗、按轉化計）同匯總摘要報告（統計去偏差匯總）。同傳統像素唔同，佢唔暴露單個用戶到轉化嘅關聯鏈路。

Shared Storage 同 Fenced Frames

Shared Storage 係一種可隨處寫入、喺沙盒中讀取嘅鍵值存儲，適用於頻次控制同 A/B 實驗一致性等跨站用途。Fenced Frames 係隔離嘅 iframe，可防止外層頁面讀取已展示廣告或其互動數據。

Privacy Sandbox 係咪需要同意？

呢係 2026 年廣告技術領域被誤解最多嘅問題，答案因司法管轄區而異。

喺 GDPR 同 ePrivacy 框架下

EDPB 尚未發佈整體立場，但各國監管機構嘅態度更為明確。英國 ICO、意大利 Garante 以及法國 CNIL 均認為，Topics 同 Protected Audience 喺處理個人數據時需要事先選擇加入同意，包括任何喺用戶設備上寫入或讀取狀態嘅處理行為。其邏輯在於：瀏覽器仍喺本地存儲興趣話題同興趣群組，而 document.browsingTopics() 調用會將推斷出嘅個人數據傳輸畀第三方。呢受 ePrivacy 指令第 5(3) 條規管，該條款要求對超出所請求服務嚴格必要範圍嘅用戶終端設備訪問或存儲行為取得同意。

Google 嘅立場更為寬鬆——佢哋認為呢啲 API 喺設計上保護私隱，同意要求喺所有情境下可能並不適用。但呢並非監管機構嘅立場。喺歐洲將 Privacy Sandbox 視為無需同意係一種高風險做法。

喺 CCPA、CPRA 同美國各州法律框架下

喺美國，Privacy Sandbox 流程通常被視為 CPRA 下用於跨情境行為廣告嘅個人信息共享。呢意味著佢哋觸發咗選擇退出權，並必須透過 Global Privacy Control 信號同其他通用選擇退出機制予以落實。Topics 數據源自瀏覽器而非從第三方數據經紀商出售嘅事實，並不構成豁免。

Chrome 自身嘅控制

Chrome 喺 chrome://settings/adPrivacy 中為 Topics、Protected Audience 同 Attribution Reporting 提供咗面向用戶嘅開關。呢啲用戶選擇與你嘅 CMP 同意狀態並列存在，而非取而代之。若用戶喺你嘅橫幅中拒絕咗廣告 Cookie，但喺 Chrome 全局設置中啟用咗 Topics，佢仍透過橫幅向你表達咗拒絕。你嘅架構必須遵從兩個信號中更嚴格嗰個。

你實際需要嘅同意層

生產級別嘅 2026 年同意架構將 Privacy Sandbox API 視為獨立嘅處理活動，每項均透過 IAB TCF 目的或等效嘅州法類別進行門控。

將 Sandbox API 映射到 TCF 目的

• Topics API——至少 IAB TCF 目的 2（投放基礎廣告）同目的 3（建立個性化廣告畫像）；若話題輸入定向邏輯，則還需目的 4（投放個性化廣告）。
• Protected Audience——目的 3 同 4，若競價使用結果數據，還需目的 7（衡量廣告效果）。
• Attribution Reporting——目的 7（衡量廣告效果）同目的 9（透過統計了解受眾）。
• 用於頻次控制嘅 Shared Storage——喺輸入個性化嘅情況下適用目的 3，若僅用於頻次控制則可基於合法利益。

映射到 Google Consent Mode v2

Google Consent Mode v2 信號與 Privacy Sandbox 行為嘅映射關係如下：

• ad_storage 被拒絕——完全禁用 Topics 同 Protected Audience API 調用
• ad_user_data 被拒絕——阻止 Attribution Reporting 發送用戶範圍數據
• ad_personalization 被拒絕——跳過 Topics 對定向邏輯嘅輸入

美國各州信號處理

對於美國流量，你嘅同意層應檢查 Global Privacy Control 及適用嘅各州選擇退出信號。當美國用戶已選擇退出共享時，抑制 document.browsingTopics() 調用，唔好調用 joinAdInterestGroup，並剝離 Attribution Reporting 註冊頭信息。

實際實施模式

已推出 Privacy Sandbox 嘅出版商通常遵循以下兩種架構模式之一。

模式一：服務端編排

你源站上嘅第一方標籤管理器收集同意狀態、用戶所在司法管轄區及任何信號覆蓋，然後有條件地將 Privacy Sandbox 鉤子渲染到頁面中。廣告服務器同 SSP 透過競價請求接收同意標記，並決定係咪調用 Topics、Protected Audience 或兩者皆唔。呢個模式集中管理邏輯，保持同意狀態嘅權威性。

模式二：Header Bidding 封裝集成

Prebid.js 及其他 header bidding 封裝程序現已支持 Privacy Sandbox 模塊。封裝程序讀取同意信號，配置 Topics 調用行為，並喺獲得許可時透過 Protected Audience 轉發競價結果。呢個方法部署更輕量，但將更多邏輯推入客戶端，並加深咗對封裝程序發佈節奏嘅依賴。

審計要點

• 確認 document.browsingTopics() 僅喺 CMP 廣告同意為肯定且無選擇退出信號時才被調用
• 確認 joinAdInterestGroup 同 runAdAuction 受相同條件門控
• 確認 Attribution Reporting 註冊頭信息僅喺用戶同意狀態允許衡量嘅響應中發送
• 確認 TCF 字符串中嘅供應商列表與喺你廣告資源上使用 Sandbox API 嘅 SSP 同 DSP 仍保持匹配
• 確認你嘅私隱政策將 Topics、Protected Audience 同 Attribution Reporting 描述為獨立嘅處理活動，並註明合法依據同保留期限

Privacy Sandbox 做唔到咩

幾個常見誤解需要喺你將其納入預算之前消除。

佢唔係同意嘅繞過手段

呢啲 API 減少咗向廣告主暴露嘅個人數據，但喺歐洲法律下，佢哋並唔使底層處理行為免於同意要求。認為採用 Sandbox 可以省去 CMP 嘅合規論斷，喺每個 EU/EEA 司法管轄區都係錯誤嘅。

佢目前並非 Cookie 嘅完整替代

Topics 提供嘅係粗粒度、有損耗嘅定向信號，通常弱於基於 Cookie 嘅受眾。Protected Audience 再定向嘅規模仍在成熟中。Attribution Reporting 存在可能掩蓋小幅轉化提升嘅測量噪聲下限。目前將所有變現遷移至 Sandbox 嘅出版商，相對於基於 Cookie 嘅架構，喺典型廣告資源上應預期 RPM 下降 10-30%。

佢目前嘅形態並非永久不變

Privacy Sandbox 規範仍在演進。Topics 分類體系正在擴展，Protected Audience 興趣群組限制正在修訂，監管回應亦持續進行。請將你嘅同意層設計為配置驅動，而非硬編碼於當前規範。

2026 年嘅正確姿態

Privacy Sandbox 最好被理解為更廣泛嘅無 Cookie 策略中嘅一個層次，與第一方數據、賣方定義受眾、情境定向同服務端 header bidding 並行。2026 年嘅贏家將係那些將同意視為仲裁者而非障礙嘅出版商——僅喺法律同用戶選擇允許嘅情況下向 Sandbox API 提供輸入，喺其他情況下乾淨地回退到情境定向，並使用唔依賴身份假設嘅工具跨兩條路徑衡量結果。

最差嘅姿態係靜觀其變。監管機構已喺起草下一波規則——英國競爭及市場管理局嘅 Sandbox 承諾、持續嘅 CNIL 指引，以及 EU AI Act 嘅畫像條款都涉及呢一領域。那些喺 2026 年將 Privacy Sandbox 構建進經過適當門控嘅同意架構嘅出版商，將為呢啲規則做好準備。而那些將其作為最後時刻 Cookie 替代方案倉促接入嘅出版商，將發現自己喺壓力下不得不重寫一切。