为了解决社区反馈，Attribution Reporting 提案进行了多项更改，从 API 机制变更到新功能。
更新日志
- 2022 年 2 月 7 日：添加了有关标头触发器重定向的部分。
- 2022 年 1 月 27 日：本文首次发布。
本帖子适合哪类用户？
以下内容适用于：
- 如果您已经了解该 API（例如，您一直在观察或参与 WICG 代码库的讨论，并希望了解 2022 年 1 月对该提案所做的一批更改）。
- 如果您是在演示版或正式版实验中使用 Attribution Reporting API。
如果您刚开始使用此 API 且/或者尚未对其进行实验，请直接参阅 API 简介。
即将进行迁移
在 Chrome 中实施这些更改后，如果您在演示版或正式版实验（来源试用）中使用 Attribution Reporting API 中的事件级报告，则需要修改代码，以便该 API 继续正常运行。您也可以考虑使用新功能。
本文还列出了可汇总报告的相关变更。不过，即使这些更改生效，您也无需执行任何操作或进行迁移，因为在撰写本文时，还没有浏览器实现可汇总报告。
改名
摘要报告和可汇总报告
您可能见过“汇总报告”一词，现在我们将其称为摘要报告。
摘要报告是汇总多个可汇总报告（以前称为贡献或直方图贡献）的最终输出。
API 机制变更
基于标头的来源注册（事件级报告）
具体变化及原因
当用户查看或点击广告时，浏览器会在用户设备本地记录此事件，以及特定于归因报告的参数（例如 attributionsourceeventid、attributiondestination、attributionexpiry 和其他参数）。这些参数的值由广告技术平台设置。
这些参数的设置方式将发生变化。
在之前的提案中，参数必须在客户端中添加：作为 HTML 属性添加到锚链接标记中，或作为基于 JS 的调用的参数添加。参数必须在点击或查看时已知。
在新提案中，这些参数的值是在广告技术平台服务器上定义的。
这有很多优点，尤其是在安全方面：标头机制可让报告来源（通常是广告技术平台）直接控制是否要在其范围内注册归因来源。这在一定程度上缓解了欺诈问题，因为在此次变更生效后，真实浏览器绝不会在未经报告来源选择的情况下注册来源。
来源注册的工作原理
- 对于给定广告，广告技术平台现在需要定义特定的客户端属性
attributionsrc。此属性的值是浏览器将向其发送请求的网址；此请求将包含一个新的 HTTP 标头Attribution-Reporting-Source-Info，其值navigation或event,分别指定来源是点击还是浏览。 - 收到此请求后，点击/观看跟踪服务器应返回包含所需归因参数的 HTTP 标头
Attribution-Reporting-Register-Source。 返回此标头的来源现在是报告来源（以前定义为
attributionreportto）。HTTP 响应标头
Attribution-Reporting-Register-Source：{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
如需了解详情，请参阅技术说明
加入公开讨论
基于标头的归因触发器（事件级报告）
具体变化及原因
与点击或观看注册一样，新提案会将归因触发器（即广告技术平台指示浏览器记录转化的时间）更改为基于标头的方法。
此机制与基于标头的来源注册保持一致，比之前使用的重定向机制更为传统。
此外，在新提案中，转化页上需要添加 attributionsrc 属性。
原因在于权限问题：在之前的提案中，触发器端网站（通常是广告客户网站）确实可以通过 Permissions-Policy 标头对该功能进行一般控制，但无法精细地控制元素级别的功能，即无法控制元素是否可以向最终触发归因的相关方发出请求。attributionsrc 会改变这一点：借助此强制性标记，广告客户可以监控哪些元素可以触发归因，从而控制哪些元素可以触发归因。
请注意，在来源端（通常是发布商网站）上，存在通过 Permissions-Policy 进行的页面级控制，以及通过 attributionsrc 进行的元素级控制。
归因触发器如何运作？
收到像素请求并确定应将其归类为转化后，广告技术平台应使用新的 HTTP
标头 Attribution-Reporting-Register-Event-Trigger 进行响应。
此标头的值指定了如何将触发器事件视为 JSON 对象。这与上一个提案中定义为查询参数的信息相同。
HTTP 响应标头 Attribution-Reporting-Register-Event-Trigger：
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
重定向（可选）
（可选）广告技术平台服务器可以将包含 Attribution-Reporting-Register-Event-Trigger 的响应设为重定向响应。这样，第三方就可以观察转化事件并指示浏览器进行归因。
重定向是可选的；如果广告技术平台和第三方都在网页上设置了像素，则无需重定向。
如需了解详情，请参阅第三方报告。
如需了解详情，请参阅技术说明
加入公开讨论
无工作流（可汇总报告）
具体变化及原因
在之前的可汇总报告提案中，需要 JavaScript 访问权限才能调用用于生成这些报告的工作流（一种基于 JavaScript 的机制）。
在新提案中，无需任何 worklet。而是通过 HTTP 标头以声明方式定义浏览器应用于生成可汇总报告的规则。
新方案具有多项优势：
- 浏览器实现：与 worklet 设计不同，新设计要简单得多，因为它不需要在浏览器中创建新的执行环境。
- 开发者体验：与 worklet 不同，新设计依赖于开发者常用且广为人知的标头。它还与来源注册的 API Surface 紧密契合，使 API 更易于学习和使用。
- 采用情况：新设计让更多现有衡量系统可以使用可汇总的报告。许多衡量解决方案仅支持 HTTP：它们依赖于不需要 JavaScript 访问权限的图片请求（像素请求）。但是，由于 Worklet 方法确实需要 JavaScript 访问权限，因此从某些现有衡量系统迁移到该方法可能很困难。
- 稳健性：新设计更易于与
keepalive语义集成，因此有助于减少数据丢失，例如，如果在用户离开网页时注册了点击或浏览。
无工作流机制如何运作？
与事件级来源注册和归因触发器标头一样，这种声明式机制基于 HTTP 标头。下一部分将对此进行详细介绍。
加入公开讨论
基于标头的来源注册（可汇总的报告）
我们提议了一种新机制，用于为可汇总的报告注册来源；此机制与事件级来源注册相同。
只有标头名称不同：Attribution-Reporting-Register-Aggregatable-Source。
如需了解详情，请参阅技术说明
基于标头的归因触发器（可汇总的报告）
我们提出了一种新机制，用于为可汇总的报告注册来源；此机制与事件级归因触发器相同。
只有标头名称不同：Attribution-Reporting-Register-Aggregatable-Trigger-Data。
如需了解详情，请参阅技术说明
新功能
第三方报告（事件级报告和可汇总报告）
具体变化及原因
新提案的以下两方面有助于更好地支持第三方报告用例：
- （可选）广告技术平台可以将网络请求重定向到其他广告技术平台服务器，以便这些其他广告技术平台执行自己的来源和触发器注册。这是目前配置第三方的常用方法。这样一来，该 API 就更容易被现有第三方报告系统等采用。
- 报告来源（通常是广告技术平台）不再受大多数隐私权限制。这支持多家广告技术平台与同一发布商或广告客户合作的用例。
第三方报告是如何运作的？
在新提案中，基于响应的来源注册和触发器依赖于 HTTP 标头。广告技术平台可以针对这些请求使用 HTTP 重定向。
如果发布商网站上的点击/浏览请求（来源注册）随后重定向到多个方，那么这些方中的每一个都可以注册此浏览或点击（来源事件）。
同样，广告技术平台可以重定向从广告客户网站发出的特定归因请求，以允许多个其他方注册转化（归因触发器）。
每个方都可以访问各自的报告，并使用各自的数据对其进行配置。
注册多个触发器，无需重定向
您还可以通过在转化端添加多个像素元素（每个触发器一个），在不使用重定向的情况下注册多个归因触发器。
加入公开讨论
展示衡量（事件级报告和可汇总报告）
具体变化及原因
在新提案中，浏览型转化衡量和点击型转化衡量采用统一的方式运作：
registerattributionsrc（用于指示浏览器同时记录浏览次数和点击次数的视图专用属性）不再包含在该提案中。- 现在，点击和观看的隐私保护机制已统一。如需了解详情，请参阅噪声和透明度。
建议进行此更改，以使其与新的基于标头的注册机制保持一致。此外，如果开发者打算同时支持点击型和浏览型衡量，这种方法还能简化开发者体验。
浏览型广告效果衡量的工作原理
浏览型效果衡量和点击型效果衡量都依赖于基于标头的注册。
如需了解详情，请参阅技术说明
加入公开讨论
调试 / 效果分析（事件级报告和可汇总报告）
具体变化及原因
该提案中添加了调试机制，以帮助开发者检测 bug，并将归因报告的效果与现有的基于 Cookie 的衡量解决方案进行比较。
调试的工作原理是什么？
来源注册和触发器注册都将接受新的参数 debug_key，即一个 64 位无符号整数（即一个大数）。
如果使用来源和触发器调试键创建报告，并且在来源和触发器注册时报告来源的 Cookie Jar 中存在 Samesite=None ar_debug=1 Cookie，则系统会将调试报告 (JSON) 发送到 .well-known/attribution-reporting/debug 端点：
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
事件级报告和可汇总报告也将包含这两个新参数，以便与正确的调试报告相关联。
如需了解详情，请参阅技术说明
加入公开讨论
过滤功能（事件级报告和可汇总报告）
具体变化及原因
由于这些指标支持当今广告生态系统中的重要用例，因此事件级报告和可汇总报告现在都将支持以下多种用例：
- 转化过滤：根据来源端信息过滤转化。例如，为广告点击和观看选择不同的触发器数据（转化数据）。
- 归因不一致：过滤错误归因的转化；这是一种特定类型的转化过滤。例如，滤除因 API 中的 etld+1 目标网址范围而与错误的广告点击/观看匹配的转化。
过滤功能如何运作？（适用于事件级报告）
来源端 JSON 对象中的可选 source_data 字段可以定义浏览器在转换时随后用于应用过滤逻辑的项。
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
触发器注册现在接受可选标头 Attribution-Reporting-Filters。
HTTP 响应标头 Attribution-Reporting-Filters：
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
或者，您也可以使用 filters 字段扩展 Attribution-Reporting-Register-Event-Trigger 标头，以执行选择性过滤，以便根据 source_data 设置 trigger_data。
如果过滤条件 JSON 中的键与 source_data 中的键匹配，并且交集为空，则系统会完全忽略该触发器。
如需了解详情，请参阅技术说明
加入公开讨论
隐私保护方面的变更
噪声和透明度（事件级报告和可汇总报告）
具体变化及原因
在新提案中，报告的隐私保护机制之一得到了改进：报告会采用随机响应机制。
这意味着，系统会正确报告部分真实转化；在一定比例的时间内，系统会抑制部分真实转化或添加一些虚假转化。
这种新技术具有以下优势：
- 它统一了点击和浏览的隐私保护机制。
- 与将触发器数据（转化数据）和触发器-来源关联噪声分开的机制相比，这种机制更简单。
- 它设置了一个隐私保护框架，通过正确的噪声设置，可确保任何一方都无法依赖该 API 来确定某个用户是否因某个广告而完成了转化。
此新机制取代了之前的机制，在之前的机制中，5% 的时间触发器数据（转化数据）会被随机值替换。
此外，报告正文（randomized_trigger_rate 字段）中还添加了随机响应概率值。此字段指定来源采用随机响应的概率（0 到 1）。
这有两个主要优势：
- 它可向将接收报告的各方（通常是广告技术平台）公开底层浏览器行为。
- 这有助于未来各浏览器都支持该 API：不同的浏览器可能会根据其隐私保护目标决定应用不同级别的噪声，而处理报告的各方需要了解这一点。
噪声功能如何运作？
在新提案中，在注册来源（即记录广告点击或浏览）时，浏览器会随机决定是真实归因转化并发送此广告点击/浏览的报告，还是改为生成虚假输出。
虚假输出可能：
- 完全不会报告，无论用户是否完成转化；
- 一项或多项虚假举报，无论用户是否完成转化。
在虚假报告中，触发器数据（转化数据）是随机的：点击次数为随机的 3 位值（0 到 7 之间的任意数字），而查看次数为随机的 1 位值（0 或 1）。
与真实报告一样，虚假报告不会在用户完成转化后立即发送。系统会在随机的报告期结束时发送这些报告。
点击有三个报告期（点击后 2 天、7 天或 30 天）。系统会将每份虚假报告随机分配到某个报告期。
此外，如之前的提案中所述，报告在时间范围内的排序是随机的。
如需了解详情，请参阅技术说明
加入公开讨论
报告限制（事件级报告和可汇总报告）
具体变化及原因
新提案明确限制了可以衡量两个网站之间事件的各方数量。
- 建议将每个{发布商、广告客户}可以注册来源的唯一报告来源（通常是广告技术平台）的数量上限设为每 30 天 100 个。系统会在每次广告点击或观看（来源事件）后递增此计数器，即使未归因的事件也是如此。
- 建议将每个{发布商、广告客户}可以发送报告的唯一报告来源（通常是广告技术平台）的数量上限设为每 30 天 10 个。系统会在每次归因转化后递增此计数器。
这些限制足够高，不会限制任何角色衡量转化的能力，但足够低，有助于减少某些形式的 API 滥用。
报告冷却期 / 速率限制
具体变化及原因
报告冷却是一种隐私保护机制，用于限制用户在给定时间段内通过此 API 发送的总信息量。
在新方案中，每 {来源网站、目标平台、报告来源}（通常为{发布商、广告客户、广告技术平台}）可在 30 天内安排 100 份报告。
超过此限制后，浏览器将停止安排与此给定{source site, destination, reporting origin}（通常为{publisher, advertiser, adtech}）匹配的报告，直到该{source site, destination, reporting origin}的 30 天滚动报告数低于 100 个为止。
如需了解详情，请参阅技术说明
目标网址上限（仅限事件级报告）
具体变化及原因
目的地上限已修改为在范围内包含报告来源（通常是广告技术平台）：每个{发布商、广告技术平台}允许有 100 个唯一的待处理目的地（通常是广告客户网站或预计会发生转化的网站）。
这项隐私保护功能可限制浏览记录重建。
如需了解详情，请参阅技术说明
所有资源
- 请参阅归因报告。
- 请参阅关于该 API 的须知事项。
标题图片来自 Unsplash 上的 Diana Polekhina。