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 的调用的参数。参数必须是在点击或观看时已知的 。
在新方案中,改为在广告技术平台服务器上定义这些参数的值。
![基于标头的来源注册示意图](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/diagram-header-based-sou-5d15e921f96f3.png?authuser=9&hl=nb)
这样做有很多好处,特别是在安全性方面:标头机制为 来源(通常是广告技术平台)直接控制是否在归因来源中注册归因来源 范围。这在一定程度上缓解了欺诈问题,因为经过这一更改,正版浏览器永远 在未选择启用报告来源的情况下注册来源。
来源注册如何运作?
- 对于给定广告,广告技术平台现在需要定义特定的客户端属性
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 的现有效果衡量解决方案的效果。
![基于 Cookie 的新调试系统示意图](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/diagram-the-cookie-base-60490ad30c9e9.png?authuser=9&hl=nb)
如何进行调试?
来源注册和触发器注册都将接受新参数 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 网站。