为了针对第三方 Cookie 的弃用做好准备,我们提供了 Chrome 协助测试模式,允许网站预览网站行为如何 和功能无需第三方 Cookie 即可正常运行。本指南提供了 简要介绍 Chrome 计划提供的测试模式以及如何访问 实验组标签。
这里的“Chrome 浏览器”指的是 Chrome 客户端:Chrome 安装到设备上。每个用户的数据 目录 构成独立客户。
实验组:一组已启用、停用或配置了特定功能的 Chrome 浏览器。在 Chrome 协助的测试环境中,指一组已设置标签的浏览器。
标签:在本上下文中,是指为属于实验组的浏览器设置的请求标头值。在整个实验过程中,实验组中的每个浏览器都将保留在该组中 Chrome 协助测试期间,确保浏览器使用的标签 确保所有测试人员对浏览器保持一致
我们提供了两种不同的模式:
- 模式 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。
此外,我们计划在模式 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。
实验监控
确保监控每个实验组和对照组的相对流量
标签。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,因此访问标签可能需要征得最终用户同意。在开始请求标签之前,我们建议您先 判断此用户意见征求义务是否适用于您。
访问 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
标志下拉菜单包含多个选项。测试人员将主要 对标有“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" 标签,以管理问题。我们欢迎 您对于初始问题的反馈和讨论:
您还可以 提出新的问题或讨论 使用“Chrome 协助测试”在代码库中模板。