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 替代方案仓促接入的出版商，将发现自己在压力下不得不重写一切。