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 的响应设为重定向响应。
这样一来，第三方便可观测到转化事件，并指示浏览器对其进行归因。
重定向是可选的；如果广告技术平台和第三方在网页上都有像素，则无需使用此属性。
如需了解详情，请参阅第三方报告。
通过技术说明了解详情
加入公开讨论
没有 Worklet（可汇总报告）
具体变化及原因
在之前关于可汇总报告的方案中，需要 JavaScript 访问权限才能调用 worklet（一种基于 JavaScript 的机制）来生成此类报告。
在新提案中，不需要 Worklet。相反，广告技术平台会通过 HTTP 进行声明式定义 标头 - 浏览器在生成可汇总报告时应使用的规则。
新提案具有以下几个优势：
- 浏览器实现：与 Worklet 设计不同，新设计 因为它不需要在浏览器中使用新的执行环境，
- 开发者体验：新设计依赖于标头， 它与 Worklet 不同。它还与 来源注册，从而使该 API 更易于学习和使用。
- 采用：新设计可让更多现有的衡量系统使用可汇总报告 报告。许多效果衡量解决方案仅支持 HTTP：它们依赖于图片请求（像素） 请求，无需 JavaScript 访问权限。但由于 Worklet 方法确实需要 JavaScript 访问，但从一些现有的衡量系统迁移到这些系统可能并非易事。
- 稳健性：新设计更易于集成，因此有助于减少数据丢失。
具有
keepalive语义，例如在用户离开应用界面时注册了点击或查看 网页。
无 Worklet 机制如何运作？
这种声明式机制基于 HTTP 标头，就像事件级来源注册一样 和归因触发器标头有关详情，请参阅以下部分。
加入公开讨论
基于标头的来源注册（可汇总报告）
提出了一种为可汇总报告注册来源的新机制；这种机制是 与事件级来源注册相同。
只有标头名称不同：Attribution-Reporting-Register-Aggregatable-Source。
通过技术说明了解详情
基于标头的归因触发器（可汇总报告）
提出了一种为可汇总报告注册来源的新机制；这种机制是 与事件级归因触发器相同。
只有标头名称不同：Attribution-Reporting-Register-Aggregatable-Trigger-Data。
通过技术说明了解详情
新功能
第三方报告（事件级报告和可汇总报告）
具体变化及原因
新方案有以下两个方面有助于更好地支持第三方报告用例：
- （可选）广告技术平台可以将网络请求重定向到其他广告技术平台服务器，以便 让广告技术平台执行自己的来源和触发器注册。这是很常见的第三种方式 今天的配置。这使得该 API 与其他现有 API 一样， 第三方报告系统
- 报告来源（通常是广告技术平台）不再具有大部分隐私权限制。它支持使用 多个广告技术平台与相同的发布商或广告主合作的情况。
第三方报告是如何运作的？
在新提案中，基于响应的来源注册和触发器依赖于 HTTP 标头。广告技术平台可以利用 HTTP 重定向来处理这些请求。
如果发布商网站上的点击/查看请求（来源注册）随后被重定向到
多方，其中每一方都可以注册此次观看或点击（来源事件）。
同样，广告技术平台可以重定向来自广告客户网站的特定归因请求，
允许多个其他方注册一次转化（归因触发器）。
各方都可以访问各自的报告，并可以使用各自的数据对其进行配置。
注册多个无重定向的触发器
您也可以在不使用重定向的情况下注册多个归因触发器，只需在转化端添加多个像素元素（每个触发器一个）。
加入公开讨论
浏览型转化衡量（事件级报告和可汇总报告）
具体变化及原因
在新方案中，浏览型转化和点击型衡量以统一的方式运作：
registerattributionsrc：视图专用属性，用于指示浏览器 同时记录观看次数和点击次数，不再包含在提案中。- 现在，点击和观看都采用了统一的隐私保护机制。有关此情况，请参阅噪音 和透明度。
建议进行这项更改，以便与新的基于标头的注册机制保持一致。 它还可以简化开发者的体验，以同时支持点击型转化和浏览型转化 衡量。
如何衡量浏览型转化？
浏览型转化和点击型衡量均依赖于基于标头的注册。
通过技术说明了解详情
加入公开讨论
调试 / 效果分析（事件级报告和可汇总报告）
具体变化及原因
我们在方案中添加了调试机制，以帮助开发者检测 bug， 比较 Attribution Reporting 与基于 Cookie 的现有效果衡量解决方案的效果。
如何进行调试？
来源注册和触发器注册都将接受新参数 debug_key（一个 64 位无符号）
整数（即一个大数字）。
如果使用来源和触发器调试键创建报告，且使用 Samesite=None ar_debug=1 Cookie
来源和触发器注册时间是否出现在报告来源的 Cookie jar 中，
报告 (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"
}
或者，可以使用 Attribution-Reporting-Register-Event-Trigger 标头扩展
filters 字段，用于进行选择性过滤，以根据 source_data 设置 trigger_data。
如果过滤条件 JSON 中的键与 source_data 中的键匹配，则触发器为
如果交集为空，则完全忽略。
通过技术说明了解详情
加入公开讨论
隐私保护方面的变更
噪声和透明度（事件级报告和可汇总报告）
具体变化及原因
在新方案中，其中一个报告隐私权机制得到改进：报告
这取决于随机应变。
也就是说，系统会正确报告一些真实的转化；并且一定百分比的
一段时间，系统将抑制一些真实转化或添加一些虚假转化。
这种新方法具有以下优势：
- 它统一了点击和查看的隐私机制。
- 相比将触发器数据（转化数据）和触发器-来源链接噪声分离开来的机制，这种机制更容易推断。
- 该 API 建立了一个隐私框架，该框架可以通过合适的噪声设置，确保任何一方都无法依赖该 API 确定具体某个用户是否已转化（或未）观看某个广告。
这一新机制取代了先前的机制，即 5% 的时间都会触发数据 （转化数据）已替换为随机值。
此外，报告正文中添加了随机回复概率值
（randomized_trigger_rate 字段）。此字段用于指定某个来源属于该来源的概率（0 到 1）
随机应变。
这样做有两大好处：
- 它会使底层浏览器行为对接收报告的各方透明 （通常是广告技术平台）。
- 这对于未来会支持此 API 不同浏览器：不同的浏览器可能会根据所使用的 隐私保护目标，而负责处理报告的各方需要清楚了解这一点。
噪声的工作原理是什么？
在新提案中，注册来源（即记录广告点击或观看）时， 浏览器会随机决定是否要据实进行转化归因，并针对此次转化发送报告 广告点击/观看，还是会产生虚假输出。
虚构输出可以是：
- 完全不报告 - 无论用户是否完成了转化；
- 一次或多份虚假举报 - 无论用户是否完成转化。
在虚构报告中，触发器数据（转化数据）是随机的：点击的随机 3 位值（任何 0 到 7 之间的数字）和视图的 1 位随机值（0 或 1）。
与真实举报一样，虚假举报不会在用户完成转化后立即发送，邮件的发送地址 随机报告期结束时。
点击报告期有三个（点击后 2 天、7 天或 30 天）。每个虚假 随机分配给其中一个报告期
另外，正如前一种方案所述，同一时间段内的报告顺序是随机的。
通过技术说明了解详情
加入公开讨论
报告限制（事件级报告和可汇总报告）
具体变化及原因
新提案明确限制可以在两个网站之间衡量事件的各方。
- 可注册的唯一报告来源（通常是广告技术平台）的数量上限 建议每个 {publisher, advertiser} 的来源不超过每 30 天 100 个。这个 计数器就会针对每次广告点击或观看（来源事件）进行递增， 属性。
- 可按每个条件发送报告的唯一报告来源（通常是广告技术平台）的数量上限 建议 {publisher, advertiser} 的频次上限为每 30 天 10 次。此计数器将被 都会增加。
这些限制应该足够高，不会限制任何参与者的衡量能力， 而且也足够低，有助于减少某些形式的 API 滥用。
报告冷却期 / 速率限制
具体变化及原因
报告冷却期是一种隐私保护机制，可限制系统发送的总信息量 在给定时间段内通过此 API 向用户发送实际事件。
在新提案中，每个 {来源网站、目标平台、报告来源} 100 份报告 （通常是 {publisher, advertiser, adtech}）可以安排在 30 天内。
超出此限制后，浏览器将停止安排与指定的 {来源网站, destination, reporting origin}（通常为 {publisher, advertiser, adtech}）- 直到 30 天滚动数据 针对该{来源网站, 目标, 报告来源}的报告数量低于 100。
通过技术说明了解详情
目标页面上限（仅限事件级报告）
具体变化及原因
修改了目标页面上限，以将报告来源（通常是广告技术平台）纳入范围：100 个唯一 待处理的目标页面（通常是预计需要转化的广告客户网站或网站） 。
这是一项隐私保护，用于限制重构浏览记录。
通过技术说明了解详情
所有资源
- 请参阅 Attribution Reporting。
- 阅读有关 API 的注意事项。
标题图片来自 Diana Polekhina 的 Unsplash 网站。