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、Shared Storage 和 Fenced Frames。

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

• 模式 A：从 2023 年 11 月起，测试 PS R&M API 的组织 已选择在部分 Chrome 中接收一致的标签 供不同测试人员协同测试。
• 模式 B：自 2024 年 1 月 4 日起，Chrome 将在全球范围内停用 部分 Chrome 浏览器的第三方 Cookie。

第三方 Cookie 在模式 B 下停用后，将一直保持停用状态，直到逐步完全停用所有第三方 Cookie。

我们与 CMA 以确保这些测试模式与测试框架（以及 （如其 行业测试指南。 因此，CMA 预计可以将在这些模式下进行的测试结果用于评估 Privacy Sandbox。CMA 表示，他们可能会更看重实验设计 2 的结果，该实验设计使用的是模式 B 标签和模式 A 对照组 1 标签。请参阅 CMA 于 10 月 26 日发布的指南 有关实验设计 2 的更多信息。

可以使用可用的临时 Sec-Cookie-Deprecation 值访问标签 从 HTTP 标头或 JavaScript API 获取。如需了解实现详情，请参阅使用 Sec-Cookie-Deprecation 值访问标签部分。

我们还会通过常规 Blink 开发流程， 技术设计和 Chrome 发布里程碑将最终敲定。 虽然这是我们希望发布的实现方式，但由于需要进一步讨论和审批，这些详细信息仍可能会发生变化。随着计划的推进，我们会继续更新此页面，您也可以继续提供反馈或提出问题。

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

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

例如，这样一来，多个参与者就可以在同一组浏览器中，在不使用第三方 Cookie 的情况下运行 Protected Audience 竞价。通过 竞价卖方参与者会将观察到的标签转发给买方， 促进协调测试。

这些标签不会影响这些 Chrome 实例中的任何行为，包括第三方 Cookie 的可用性。标签提供 对独立、协调的实验进行分组， 让参与实验的各方强制实施实验的相关参数。如果 您需要测试移除第三方 Cookie 的效果 负责排除具有 标签。

目的是获得代表正常 Chrome 流量的群组。这样 意味着第三方 Cookie 和 PS R&M API 都应该可用， 部分用户可能已使用设置或扩展程序更改或停用 功能。

在 Chrome 的浏览会话期间，标签通常会保持不变； 。不过，我们无法保证这一点，因为在极少数情况下，完全重置浏览器也可能会重置当前标签。

我们计划让 8.5% 的 Chrome 稳定版浏览器支持模式 A，我们的 初始方案将该人群划分为九组。较小的子群组 旨在让广告技术平台灵活地组合标签以创建 自己的实验规模不同。群组不会重叠。

请注意，control_1.* 标签旨在用作“Control 1”为 CMA 的 行业测试指南、 因此测试参与者不得使用 Topics API，也不得运行 Protected Audiences 针对此流量的竞价。由于这些标签不会影响浏览器行为，因此参与者在检测到 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 日起可用。

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

Chrome 已在 Chrome 稳定版中停用大约 1% 的第三方 Cookie 从 2024 年 1 月 4 日开始，开发者版、Canary 版和 Beta 版 （2023 年第 4 季度）。测试 PS R&M API 的组织无需选择启用此模式，因为此模式会在整个浏览器群体中统一应用。部分网站功能 会受到影响。 CHIPS或 Related Website Sets。

注意：如果您依赖第三方 Cookie 数据来使用网站功能，请参阅我们的关于为第三方 Cookie 逐步淘汰做好准备的指南，了解 CHIPS 或相关网站集是否可以满足您的需求。我们已推出公开问题跟踪器，您可以通过该跟踪器报告因第三方 Cookie 弃用而导致的网站问题。我们是 正在制定缓解措施，以检测、解决并主动提醒网站所有者 影响用户体验的问题。

此外，我们计划在模式 B 中提供一小部分流量， 已停用 PS R&M API。其他 API（例如相关网站集、CHIPS 和 FedCM）不会被停用。我们预计，这种组合有助于在不使用第三方 Cookie 和 PS R&M API 的情况下，为浏览器建立基准效果。

在模式 B 中，我们还为受影响的浏览器提供了标签。通过 这些标签在 API 停用的同时仍可用。我们提议将受众群体划分为三个 treatment_1.* 组（其中第三方 Cookie 已停用，但 PS R&M API 可用）和一个 control_2 组（其中第三方 Cookie 和 PS R&M API 均已停用）。

协助调试 Attribution Reporting API 和不公开汇总 API 集成，并帮助测试参与者更好地了解 ARA 调试报告和不公开汇总调试报告 模式 B 下的浏览器上仍可使用，只要用户没有 明确阻止的第三方 Cookie。以下国家/地区不支持调试报告： control_2，因为 PS R&M API 在该 Slice 中不可用。调试报告仍将随着第三方 Cookie 逐步淘汰而逐步淘汰。

• 对于 Attribution Reporting API，由于第三方 Cookie 已停用，报告来源将无法设置 ar_debug Cookie，而应依赖于设置 debug_key 字段（针对归因成功报告）和 debug_reporting 字段（针对详细报告）来选择接收或不接收调试报告。
• 对于 Private Aggregation API，报告来源应依赖于调用 enableDebugMode() 来控制是否选择接收调试报告。公司应继续 考虑法规义务在使用归因时可能需要遵守的法律义务 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。

注意 ：缓解措施 允许在某些特定环境中允许第三方 Cookie 的 模式已启用 B 用户，但这些缓解措施是暂时性的，Chrome 计划停用 逐步淘汰第三方 Cookie 后采取的临时缓解措施。这意味着 逐步淘汰后的用户体验将与模式 B 不同 因为我们将不再提供缓解措施。

实验监控

确保监控每个实验组和对照组的相对流量 标签。treatment_1.1 的流量应与 treatment_1.2 和 treatment_1.3 大致相同。

我们建议您谨慎对待包含来自以下来源的标签的流量： 版本低于 120 的 Chrome 版本。如果通常负责处理无效流量的团队发现具有无效流量特征的用户代理，则有必要将其从测试结果中滤除。

报告期前标签

在 2024 年 1 月之前，我们为多个实验组设置了前期时间段。实施前时段 允许 Chrome 根据统计学特征 公正的群体。这些预实验期适用于所有安排在 1 月开始的组：模式 B 组和 Control_1.* 组。开发者或网站无需采取任何措施，因为这些前期组的行为或 API 可用性不会发生任何变化。不过，请注意，在某些情况下，您可能会看到系统返回 preperiod 标签。虽然收到 “preperiod”标签可能会转移到某个实验组，这不是 因此建议不要假定带有此标签的浏览器 才能参与实验

实验组是指被研究人群的一部分；在本例中，就是其中一个标记组。

使用 Sec-Cookie-Deprecation 值访问标签

在模式 A 和模式 B 期间，我们引入了 可通过选择启用的 HTTP 标头和 JavaScript 访问的 Sec-Cookie-Deprecation 值 API，为浏览器的适用模式 A 或 B 提供标签 （按照上述百分比所定义），前提是其属于 这些。

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

注意：与我们在 Chromium 中发布的所有功能一样，我们已在 Blink 开发流程中发送了意图到原型 (I2P)。 我们提议的实施细节在后面部分，但 更改。我们将不断更新 本文档。 系统会将 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 秒之后不会过期 天。

您可能需要先设置 receive-cookie-deprecation=1 Cookie 在 Chrome 协助测试开始前，确保 实验组中的浏览器包括Sec-Cookie-Deprecation 请求标头。

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

Sec-Cookie-Deprecation: example_label_1

如果浏览器不属于任何群组，则不会发送标头。 标签与 Cookie 的存在相关联 或针对特定网站屏蔽了广告，则标签不会 已发送。由于 Partitioned 属性旨在 第三方 Cookie 已被完全弃用，这意味着 Partitioned Cookie 可能会 在第三方 Cookie 被屏蔽时设置。

访问 cookieDeprecationLabel JavaScript API

Sec-Cookie-Deprecation 值也可使用 navigator.cookieDeprecationLabel.getValue() JavaScript API。这将返回一个 promise ，该 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 或仅针对相应网站屏蔽 Cookie，该 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

Chrome 协助测试的标志设置

标志下拉菜单包含多个选项。测试人员将主要 对标有“Force”的条目感兴趣因为这样可以确保实验 行为。

如需仅测试实验组标签，请选择“启用强制对照组 1”或“启用强制标签组”。这些方法会导致浏览器向 “fake_control_1.1”或“fake_label_only_1.1”标签。

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

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

如需在不使用私密广告 API 的情况下测试第三方 Cookie 屏蔽功能，请选择“强制使用对照组 2”。这将发送“fake_control_2”实验组标签、更新 Cookie 设置页面、屏蔽第三方 Cookie，还会抑制新的隐私广告 API。

请注意，存在一个问题，即浏览器始终使用 Cookie 设置页面以及用于阻止第三方 Cookie 的设置，即使您 来停用该标志我们正在努力解决这一问题，但在此期间， 可以在单独的 Chrome 数据目录中测试这些标志值，方法是启动 带有 --user-data-dir=<new dir> 命令行标志的 Chrome。

反馈

我们使用"chrome-testing" 标签，以管理问题。我们欢迎 您对于初始问题的反馈和讨论：

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

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