Chrome 协助测试

为了针对弃用第三方 Cookie 做好准备，我们将提供 Chrome 协助测试模式，让网站可以预览在没有第三方 Cookie 的情况下网站行为和功能的运作方式。本指南简要介绍了 Chrome 计划提供的测试模式，以及如何访问实验组标签。

在此上下文中，Chrome 浏览器指的是 Chrome 客户端：在设备上安装 Chrome。每个用户的数据目录都构成不同的客户端。

实验组：已启用、停用或配置特定功能的一组 Chrome 浏览器。在 Chrome 协助测试环境中，这是一组设置标签的浏览器。

标签：在此上下文中，是为属于实验组的浏览器设置的请求标头值。 在 Chrome 协助测试期间，实验组中的每个浏览器都将归入该组，以确保浏览器的标签在所有测试人员之间保持一致。

注意 ：此测试侧重于衡量 Privacy Sandbox 相关性和效果衡量 API (PS R&M API) 的性能：Attribution Reporting、Protected Audience、Topics、Private Aggregation、共享存储空间和围栏框架。

我们提供了两种不同的模式：

• 模式 A：从 2023 年 11 月起，测试 PS R&M API 的组织已经能够选择在一部分 Chrome 浏览器中接收一致的标签，以便不同测试人员进行协调测试。
• 模式 B：从 2024 年 1 月 4 日起，Chrome 会为部分 Chrome 浏览器全面停用第三方 Cookie。

这两种模式至少将持续到 2025 年初。如果第三方 Cookie 在模式 B 下被停用，则这些 Cookie 将保持停用状态，直到逐步完全停用第三方 Cookie。

我们已与 CMA 合作，确保这些测试模式符合其行业测试指南中所述的第三方测试框架（和时间表）。因此，CMA 预计，在评估 Privacy Sandbox 时，可以在这些模式下测试的结果用于评估。CMA 表明，他们可能会更重视实验性设计 2 的结果，该设计使用模式 B 标签和模式 A 的对照组 1 标签。如需详细了解实验性设计 2，请参阅 CMA 10 月 26 日发布的指南。

注意 ：标签将通过临时弃用 Cookie 值获取，该值可通过 HTTP 标头或 JavaScript API 访问。如需了解实现详情，请参阅后面的通过 Cookie 弃用值访问标签部分。

我们还将通过常规的 Blink 开发流程发送此提案，届时技术设计和 Chrome 版本里程碑将最终确定。虽然这是我们希望发布的实现，但经过额外的讨论和批准，这些细节仍有可能更改。随着计划的进展，我们会持续更新此页面，并且您可以继续提供反馈或问题。

模式 A：已加标签的浏览器组

参与测试的组织将能够选择接收一部分 Chrome 浏览器的永久性标签集，从而在同一组浏览器上跨不同广告技术平台进行协调实验。例如，如果浏览器属于 label_only_3 实验组（如下表所示），则所有参与的广告技术平台都将能看到相同的 label_only_3 标签，并相应地进行协调：请使用 PS R&M API，但避免使用第三方 Cookie。我们希望页面的参与者能够确保将标签转发给其他参与者，从而在整个广告选择和衡量流程中实现一致的实验。

例如，这样可让多个参与者在一组一致的浏览器中无需第三方 Cookie 即可运行 Protected Audience 竞价。竞价卖方参与者会将观察到的标签转发给买方，以便协调测试。

这些标签不会影响此类 Chrome 中的任何功能，包括第三方 Cookie 的可用性。这些标签用于为独立、协调的实验提供分组，但对于实验来说，是否执行相关参数则取决于参与方。如果您要测试移除第三方 Cookie 的效果，则每个参与者都有责任针对带有该标签的浏览器排除第三方 Cookie 数据。

我们的目标是创建可代表常规 Chrome 流量的群组。这意味着第三方 Cookie 和 PS R&M API 应该都可用，不过某些用户可能已通过设置或扩展程序更改或停用了功能。

标签通常在 Chrome 的整个浏览会话和会话之间保持不变。但是，这无法保证，因为在极少数情况下，完全重置浏览器也可能会重置当前标签。

我们计划在模式 A 中覆盖 8.5% 的 Chrome 稳定版浏览器，我们的初始方案将这一比例划分为 9 组。较小的子组旨在让广告技术平台能够灵活地组合标签，以创建他们自己的不同规模的实验。组不会重叠。

请注意，control_1.* 标签旨在用作“对照组 1”，如 CMA 的行业测试指南中所述，因此测试参与者不应使用 Topics API，也不应针对此类流量运行 Protected Audience 竞价。由于标签不会影响功能，因此在检测到 control_1.* 群组标签时，参与者不应传递观察到的主题或进行 Protected Audience 竞价。

我们欢迎您就这些精选群组是否符合相关组织的需求提供反馈。

标签	稳定流量占比
control_1.1	0.25
control_1.2	0.25
control_1.3	0.25
control_1.4	0.25
label_only_1	1.5
label_only_2	1.5
label_only_3	1.5
label_only_4	1.5
label_only_5	1.5

模式 A label_only_ 浏览器组已于 2023 年 11 月推出，模式 A control_1_* 组自 2024 年 1 月 4 日起提供。在第三方 Cookie 于 2025 年初逐步淘汰之前，我们将继续发送所有模式 A 和模式 B 标签。

模式 B：停用 1% 的第三方 Cookie

自 2024 年 1 月 4 日起，Chrome 为大约 1% 的 Chrome 稳定版浏览器停用了第三方 Cookie（2023 年第 4 季度起，开发者版浏览器、Canary 版浏览器和 Beta 版浏览器也停用了第三方 Cookie）。测试 PS R&M API 的组织无需选择启用此模式，因为它将统一应用于整个浏览器群体。当然，如果网站尚未采用 CHIPS 或 Related Website Set 等替代解决方案，某些网站功能可能会受到影响。

注意 ：如果您依赖第三方 Cookie 数据来实现网站功能，请阅读我们的为逐步淘汰第三方 Cookie 做准备的指南，了解 CHIPS 或 Related Website Set 能否满足您的需求。我们推出了一个公开的问题跟踪器，您可以在其中报告因弃用第三方 Cookie 而导致的网站问题。我们正努力研究缓解措施，以便检测和解决此阶段影响用户体验的问题，并主动向网站所有者发出提醒。

此外，我们计划在已停用 PS R&M API 的模式 B 中提供一小部分流量。但 Related Website Set、CHIPS 和 FedCM 等其他 API 不会被停用。我们预计，这种组合将有助于为没有第三方 Cookie 和 PS R&M API 的浏览器建立性能基准。

在模式 B 中，我们还会为受影响的浏览器提供标签。这些标签会在 API 停用的同时可用。我们建议将用户划分为三个已停用第三方 Cookie 但 PS R&M API 可用的 treatment_1.* 组和一个已停用第三方 Cookie 和 PS R&M API 的 control_2 组。

为了协助调试 Attribution Reporting API 和 Private Aggregation API 的集成以及帮助测试参与者更好地了解噪声影响，只要用户未明确屏蔽第三方 Cookie，处于模式 B 的浏览器就仍可使用 ARA 调试报告和不公开汇总调试报告。control_2 中不提供调试报告，因为该 Slice 中不提供 PS R&M API。调试报告将与逐步淘汰第三方 Cookie 一同逐步淘汰。

• 对于 Attribution Reporting API，由于第三方 Cookie 已停用，报告来源将无法设置 ar_debug Cookie，而应依赖设置 debug_key 字段（对于归因成功报告）和 debug_reporting 字段（对于详细报告）来选择启用或停用接收调试报告。
• 对于 Private Aggregation API，报告来源应依赖于调用 enableDebugMode() 来控制是否选择接收调试报告。公司应该继续考虑在使用 Attribution Reporting API 和 Private Aggregation API（包括调试报告）时可能需要履行的监管义务。

模式 A 继续运行，并且这些组与模式 A 组不同，因为用户要么处于模式 A 或模式 B，要么两者都不处于。测试参与者应使用 control_1.* 流量作为代表使用第三方 Cookie 现状的对照组。

标签	稳定流量占比
treatment_1.1	0.25
treatment_1.2	0.25
treatment_1.3	0.25
control_2	0.25

Chrome 还限制了 20% 的 Chrome Canary 版、开发者版和 Beta 版客户端的 Cookie。

标签	使用稳定前的流量占比
prestable_treatment_1	10%
prestable_control_2	10%

将其中一个实验组纳入该实验组的效果与将其与稳定版本对应的实验组纳入效果相同。

与模式 A 一样，我们无法保证 PS R&M API 可用，因为用户可在 Chrome 的隐私设置和安全性设置中将其停用。同样，我们也不保证为 control_2 群组的每个成员都停用第三方 Cookie，因为用户可能通过访问浏览器界面来允许网站使用第三方 Cookie。

实验监控

请务必监控每个实验组和对照组标签的相对流量。treatment_1.1 获得的流量应该与 treatment_1.2 和 treatment_1.3 大致相同。

我们建议您谨慎处理包含来自 120 之前 Chrome 版本的标签的流量。如果您的团队通常负责处理无效流量，发现有用户代理具有无效流量特征，那么最好从测试结果中滤除这些用户代理。

投放前时段标签

在 2024 年 1 月之前，我们针对多个实验组运行了前期实验：在这段时间内，Chrome 可以准确地调整规模并选择在统计上无偏差的组。针对安排在 1 月份开始的所有实验组，都会运行以下预期：模式 B 实验组和 Control_1.* 实验组。这种情况下，开发者或网站无需采取任何行动 - 这些投放前期的实验组在行为或 API 可用性方面不会出现任何变化，但请注意，您可能会看到在某些情况下返回 preperiod 标签。虽然收到 preperiod 标签的浏览器可能会过渡到某个实验组，但无法保证一定能完成，因此建议不要假定带有此标签的浏览器一定会参与实验。

实验组是研究对象的一部分：在本例中，为其中一个加标签的组。

通过 Cookie-Deprecation 值访问标签

在模式 A 和模式 B 运行期间，我们将引入一个可通过选择启用 HTTP 标头和 JavaScript API 访问的临时 Cookie-Deprecation 值，如果属于一个模式，它将为浏览器的适用模式 A 或模式 B 实验组（如上述百分比所定义）提供标签。

访问标签涉及访问用户设备上存储的信息。在某些管辖区（例如欧盟和英国），我们理解此类活动与使用 Cookie 类似，因此访问标签可能需要获得最终用户的同意。在开始请求添加标签之前，我们建议您先咨询法律建议，了解这项用户意见征求义务是否适用于您。

注意 ：与我们的 Chromium 中提供的所有功能一样，我们在 Blink 开发流程中发送了原型设计 intent (I2P)。 以下实现详情是我们提议的，但当我们在 Chrome 稳定版中推出该功能之前，可能会更改这些实现详情。我们将继续更新本文档，您也可以在 intent 发布到 blink-dev 邮寄名单后关注公开讨论。

访问 Sec-Cookie-Deprecation HTTP 标头

若要接收 Sec-Cookie-Deprecation 请求标头，网站必须先设置 receive-cookie-deprecation Cookie。此 Cookie 必须使用 Partitioned 属性，这意味着必须按顶级网站选择接收标头。

例如，如果 3p-example.site 希望在其嵌入 example.com 上的资源中接收 Sec-Cookie-Deprecation 标头，则 3p-example.site 必须在该上下文中设置以下 Cookie。

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned;  Max-Age=15552000

Secure、HttpOnly、SameSite 和 Partitioned Cookie 属性是必需的。Domain、Path、Expires 和 Max-Age 等其他属性可以根据需要进行设置，不过 Path=/ 是一个不错的默认值。此处的示例设置了 Max-Age=15552000，因此 Cookie 的有效期为 180 天。

您可能需要在 Chrome 协助测试期开始之前就开始设置 receive-cookie-deprecation=1 Cookie，以确保实验组中的浏览器在 Sec-Cookie-Deprecation 请求标头可用时尽快添加该标头。

例如，假设浏览器位于 example_label_1 组中，包含此 Cookie 的后续请求也将包含 Sec-Cookie-Deprecation 标头。

Sec-Cookie-Deprecation: example_label_1

如果浏览器不属于任何组，则不会发送任何标头。标签与 Cookie 的存在相关联，因此，如果为特定网站删除、完全屏蔽或屏蔽 Cookie，系统将不会发送标签。由于 Partitioned 属性应在第三方 Cookie 被完全弃用后继续使用，因此系统可能会在屏蔽第三方 Cookie 时设置 Partitioned Cookie。

访问 cookieDeprecationLabel JavaScript API

您还可以通过 navigator.cookieDeprecationLabel.getValue() JavaScript API 访问 Cookie-Deprecation 值。这将返回一个 promise，它可以解析为包含适用组标签的字符串。例如，如果浏览器位于 example_label_1 组中：

// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
 // Request value and resolve promise
 navigator.cookieDeprecationLabel.getValue().then((label) => {
   console.log(label);
   // Expected output: "example_label_1"
 });
}

如果浏览器不属于某个组，则 API 将不可用或相应值将为空字符串，因此请务必执行功能检测。

无论是否存在 receive-cookie-deprecation Cookie，都可以调用 JavaScript API。不过，如果完全或专门针对网站屏蔽 Cookie，API 将再次不可用或返回一个空字符串。

与客户端提供的任何值一样，请务必在使用之前清理并验证标头或 JavaScript API 中的值。

演示和测试

从 Chrome 120 开始，有一些标志可用于启用请求和读取标签的本地开发者测试。

chrome://flags/#tpc-phase-out-facilitated-testing 标志可让您启用一系列测试标签。这些标签带有 fake_ 前缀，以便与真实标签区分开来。启用此标志不会让浏览器加入任何实验组。

您可以通过 goo.gle/cft-demo 查看标签的实际效果。

由于 Privacy Sandbox 相关性和效果衡量 API 的注册会强制执行，因此您可能需要使用 chrome://flags/#privacy-sandbox-enrollment-overrides 并提供演示来源来覆盖本地测试的强制执行情况。或者，如果您从终端运行 Chrome，请添加以下命令行标志：--args --disable-features=EnforcePrivacySandboxAttestations

标志下拉菜单包含多个选项。测试人员主要对标记为“强制”的条目感兴趣，因为这些条目可确保无论其他设备配置如何，实验行为都会启用。

若要仅测试实验组标签，请选择“已启用强制对照组 1”或“已启用 Force LabelOnly”。这会导致浏览器发送“fake_control_1.1”或“fake_label_only_1.1”标签。

在 Chrome M120 或更高版本中，您还可以使用以下条目。

若要测试第三方 Cookie 拦截功能，请选择“已启用强制处理”。这将发送“fake_treatment_1.1”实验组标签，但也会修改 Cookie 设置页面和当前 Cookie 设置，以屏蔽第三方 Cookie。

如需在不使用私享广告 API 的情况下测试第三方 Cookie 屏蔽，请选择“Force Control 2”。这样将会发送“fake_control_2”实验组标签、更新 Cookie 设置页面、屏蔽第三方 Cookie，并且还会禁用新的私享广告 API。

请注意，目前存在的一个问题是，即使您停用该标志，浏览器仍会使用新版 Cookie 设置页面和屏蔽第三方 Cookie 的设置。我们正在努力解决此问题，在此期间，您可以使用 --user-data-dir=<new dir> 命令行 flag 启动 Chrome，在单独的 Chrome 数据目录中测试这些 flag 值。

反馈

我们使用 GitHub 上的开发者支持代码库中的“chrome-testing”标签来管理问题。我们欢迎您就以下初始问题提供反馈和讨论：

• 您打算使用模式 A 和/或模式 B 进行测试吗？
• 为 Chrome 协助测试选择标签大小
• 在 Chrome 协助测试中使用客户端提示

您还可以使用“Chrome 协助测试”模板在代码库中提出新问题或讨论。