2024 年第 4 季度季度报告,总结了收到的有关 Privacy Sandbox 提案的生态系统反馈和 Chrome 的回复。
根据 Google 向 CMA 做出的承诺,Google 同意每季度公开提供有关其 Privacy Sandbox 提案利益相关方互动流程的报告(请参阅承诺的第 12 段和第 17(c)(ii) 段)。这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈概览中列出的各种来源(包括但不限于 GitHub Issues、privacysandbox.com 上提供的反馈表单、与行业利益相关方举行的会议和 Web 标准论坛)收到的反馈而生成的。Chrome 欢迎收到来自生态系统的反馈,并正在积极探索将所学知识融入设计决策的方法。
反馈主题的排名依据是每个 API 的普遍性。具体方法是汇总 Chrome 团队针对给定主题收到的反馈量,并按数量从高到低排序。我们通过查看公开会议(W3C、PatCG、IETF)、直接反馈、GitHub 以及 Google 内部团队和公开表单中出现的常见问题的讨论主题,确定了常见的反馈主题。
具体而言,我们查看了网络标准机构会议的会议记录,并考虑了 Google 的 1 对 1 利益相关方会议记录、各个工程师收到的电子邮件、API 邮寄名单和公开反馈表单,以获取直接反馈。然后,Google 协调了参与这些各种宣传活动的团队,以确定与每个 API 相关的主题的相对普遍程度。
关于 Chrome 对反馈的回复的说明是根据已发布的常见问题解答、对利益相关方提出的问题的实际回复,以及专门为此次公开报告活动确定的立场而制定的。我们收到了许多关于 Topics、PA API 和归因报告 API 及相关技术的问题和反馈,这反映了当前开发和测试的重点。
我们可能尚未就近期收到的反馈做出周到的 Chrome 回复。
首字母缩写词表
- ARA
- Attribution Reporting API
- CHIPS
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- Federated Credential Management
- IAB
- 美国互动广告局
- IDP
- 身份提供商
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- Origin 试用版
- PA API
- Protected Audience API(以前称为 FLEDGE)
- PatCG
- “私密广告技术”社区群组
- RP
- 依赖方
- RWS
- 相关网站集(以前称为第一方集)
- SSP
- 供应方平台
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 故意忽视 IP 地址
一般反馈,无特定 API/技术
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
承诺 | 承诺的第 G 部分对 Privacy Sandbox 的可行性至关重要。由于无法保证 Google 自家广告业务将完全依托沙盒技术运营,因此沙盒技术的效用会越来越低,Google 剥离该技术的可能性也会增加。此类剥离或实用性降低将对开放网络上注重隐私保护的可定位性构成生存威胁。 | 这些承诺并不能保证 Google 自家的广告业务将完全 依托 Privacy Sandbox 技术运营。Google 打算采用组合方法来实现可定位性,其中包括 Privacy Sandbox 技术,就像第三方可以和正在使用的一样。我们知道,投资组合方法在广告生态系统中很常见。 我们认为,开发者拥有可保护隐私的工具和技术仍然非常重要。我们将继续提供 Privacy Sandbox API,并在该 API 上加大投入,进一步增强其隐私保护和实用性。 |
治理 | 拟议的治理模式未在正式咨询或申诉流程中纳入问责机制。 | 这不正确。(i) 决策系统和相关出版物以及 (ii) 申诉流程都提供了特定的问责机制。此外,监测受托人还将详细监督其运作。 |
治理 | 反馈指出,该模型未包含有关创建和维护跨平台标准的规定。 | 任何治理模式都无法强制其他参与者(在本例中为浏览器)采用某种标准。因此,我们没有提出需要跨平台采用标准的模型。Google 将继续参与标准论坛,在该过程中,提出提案和分享实施提案的经验是一项常见活动。 |
治理 | 建议将咨询期延长至至少 2 个月。建议的治理模式无法让整个生态系统有足够的时间来分析建议的更改的影响。 | 三周时间并不是一项更改的整个反馈期,因为现有的反馈周期(时间要长得多)将继续。咨询流程则是在现有流程内为战略决策提供了一个新的正式反馈窗口。因此,在功能开发过程中,第三方仍可通过各种论坛(包括 GitHub、W3C 和 IAB Tech Lab 等广告标准机构)提供反馈。以这种方式构建反馈周期,可让生态系统有机会分析和分享对拟议更改的看法,而不会大幅延迟开发流程。 |
治理 | 请求提供有关未来治理计划的详细信息。 | 此处的 CMA 2024 年第 2/第 3 季度报告第 3-5 页中列出了拟议治理模式的摘要。 |
异常请求 | 为已同意的用户请求访问第三方 Cookie (3PC) 的例外情况。 | 同意出于特定数据处理目的访问设备和存储设备中的数据并不意味着用户想要在 Chrome 中替换其 3PC 设置。允许在网站一级替换用户的 3PC 设置可能会造成严重的滥用行为,而且 Chrome 无法审核所有可能导致用户请求例外情况的网站行为。 |
Privacy Sandbox | 请求提供 Privacy Sandbox API 用户选择接受率。 | 我们没有计划与生态系统分享这些信息。欢迎开发者调用他们已部署代码的 API,以估算 Privacy Sandbox API 的可用性。 |
源试用 | 是否有延长源试用期的计划? | 源试用期已延长至 2025 年 4 月 14 日。 |
Privacy Sandbox | 请求以非技术性的方式简要说明 Privacy Sandbox,突出其业务价值并赢得高管的支持。 | 我们最近在 privacysandbox.com 上添加了此处的“商家资源”部分,其中提供了这些信息。 |
模式 B | 当浏览器处于“模式 B”时,当前 Cookie Jar(1PC、3PC、本地存储)会保留还是会被清除? | 当前的 Cookie Jar 不会被清除。3PC 仍可在其第一方环境中访问。 |
更新了 Chrome 上的 3PC 方法 | 未来 Chrome 中是否会彻底移除 3PC? | 我们提出了一种更新的方法,让用户能够更加明智、灵活地做出选择。正如此处所述,我们不会弃用第三方 Cookie,而是会在 Chrome 中引入一种新的体验,让用户在知情的情况下做出选择,并确保用户的选择将应用于他们的所有网络浏览行为,而且用户能够随时做出调整。我们正在与监管机构探讨这种新方案,并计划在推出之前与整个行业进行沟通。 |
Chrome 测试 | 请求继续使用 Chrome 协助测试标签。 | Privacy Sandbox 团队理解,各公司希望继续使用Cookie 弃用标签。延长标签的使用期限的过程与延长来源试用期的过程类似。在此过程中,实验一次只能延长三个 Chrome 里程碑。例如,Chrome 针对 Cookie 弃用标签的最新 Intent to Extend Experiment (I2EE) 已延伸至 Chrome M130-M132(包括这两个版本)。这样一来,在 2 月初发布 M133 稳定版之前,系统就会支持这些标签。其他扩展程序将遵循相同的流程,因此我们建议您加入 blink-dev 电子邮件群组,以便及时了解最新动态。 |
注册和认证
本季度未收到任何反馈。
展示相关内容和广告
主题
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
规格 | 分类器模型是否在 Android(按应用名称)和 Chrome(按主机名)之间共享? | 不可以,这两者是不同的模型,因为它们的分类不同。 |
“主题”分类的粒度 | 主题过于宽泛,无法与第一方信息搭配使用。 | “主题”分类法旨在平衡实用性和隐私性。虽然我们已评估可能的机制来使主题更具体,但最终决定不这样做,因为安全和隐私等方面存在顾虑。 广告技术平台可以将所有可用工具(例如机器学习和可保护隐私的 API 提供的注重隐私保护的信号)与情境数据、广告素材数据和第一方数据相结合,从而取得理想的成效。如需有关此方面的进一步指导,请点击此处。 |
API 应用 | Topics API 的覆盖率较低。 | 覆盖率较低的常见原因包括: - 用户控制/用户选择停用 - 发布商控制/用户选择停用 - 网站资格要求(以下网站未获准与主题匹配:不安全的网站;WebView;iOS 版 Chrome 和无痕模式) - 用户限制(年龄未满 18 周岁或使用无痕模式的 Chrome 用户无法被观察和分配主题) - 卖方观察要求(调用方必须先前在与符合条件的主题相关联的网站上看到过用户) - 实现时间较短(需要大约 4 周的时间来逐步扩大调用方观察范围) |
API 应用 | 请求有关 Topics API 使用情况的信息,因为“Networking”标签页似乎显示发送并捕获了调用,但 chrome://topics-internals/ 未显示已记录的观察器。 | 使用 HTTP 标头机制与 Topics API 交互时,系统会在 Sec-Browsing-Topics 请求标头中发送主题,但只有在服务器响应时使用 Observe-Browsing-Topics: ?1 响应标头时,系统才会观察到这些主题。如需了解详情,请点击此处。 |
Chromium 参与情况 | 对于桌面设备,Chrome 是否会与其他基于 Chromium 的浏览器共享相同的观察和排名情境? 对于移动设备,Android Chrome 是否会与基于 Chromium / In-App Chromium 的其他 Android 浏览器共享相同的观察和排名情境? |
Chrome 不会与设备上的其他浏览器共享主题数据。 |
规格 | Topics API 如何确定用户的网页浏览是否应被视为“主题历史记录条目”? | 网页浏览必须包含“observe”调用(可以来自任何调用方),才能纳入每周主题计算范围。如果没有“observe”调用,系统将不会将相应访问纳入主题历史记录。 |
安全 | Topics API 如何防止一个调用方获取其他调用方观察到的主题? | 您可以在此处找到相关说明。 |
分类 | Topics API 中的树结构分类如何在每个时间段的观察中使用? | 在计算前 5 个主题时,该功能仅会考虑分类器提供的原始主题,排名则由以下两项决定:(i) 网页访问频率,以及 (ii) 优先级得分(请参阅规范)。 在计算前 5 个主题的“被调用方观察到”次数时,系统会纳入观察到主主题或其任何子主题的调用方。 |
规格 | 请求提供有关响应中 5% 随机噪声的更多信息。 | 每个周期始终有 5 个热门主题。如果浏览记录未提供 5 个主题,系统会随机选择主题,直到达到 5 个为止。我们将这些主题称为“填充主题”。除非调用方在过去几周内观察到(调用了该 API)用户在包含相应主题的网站上浏览,否则不会收到这些随机填充的主题之一。 调用该 API 时,系统会计算每个用户、每个网站和每个时间段的哈希值。如果该哈希小于返回带噪主题的概率,则系统会选择返回每个用户、每个网站、每个时间段的随机主题。不过,只有在调用方观察到相应用户/网站/时间段的未加入噪声的主题时,系统才会返回加入噪声的主题(例如,不会进行过滤)(请参阅说明)。这种过滤可确保在 5% 的时间里,无论给定调用方的观察能力如何,系统都会返回带噪主题。 |
规格 | 跨周重复主题是如何运作的?API 是否会独立选择一周内的日期,然后进行合并? | 系统会单独计算每周(周期)的主题。从每个时间段返回的特定主题取决于调用方所在的网站。 我们没有考虑到,对于给定的调用方,主题可能会在多个时间段重复出现(因此应考虑选择其他主题),但欢迎您点击此处提供有关此问题的更多反馈。 |
Protected Audience API
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
A/B 测试 | 此处介绍的共享存储解决方案会增加延迟时间,并且失败率较高(即,大量流量最终都没有人口 ID)。熵值较低的 ID(例如,3 位)就足以进行有效的 A/B 测试,且不会对隐私造成重大影响。 | 我们认为共享存储空间解决方案仍然可行,但我们正在考虑此请求,如果此功能是高优先级的,欢迎生态系统提供更多反馈。 |
报告 | 请求在 reportWin() 中添加更多位,尤其是因为据了解,PA API 中的新点击和展示报告将使用 6-8 位,这会有效减少可用于其他 PA API 报告的剩余位数。 |
出于隐私保护方面的考虑,我们不再考虑将 modelingSignals 位数从目前的 12 位增加。 我们诚邀生态系统对我们的“私密模型训练”提案提供反馈,该提案旨在在不受 Privacy Sandbox 对位数限制的安全环境中满足机器学习训练需求。 |
兴趣群体 | 请求为兴趣群组 (IG) 设置 90 天的生命周期,因为 30 天的时间太短。 | 正如我们在博文中所提到的,我们计划将 Instagram 帖子的生命周期延长至 90 天,并在此处创建了相关说明。 我们目前正在实施该功能,并会在有可用发布时间表时分享。 |
兴趣群体 | 请求动态更新 IG 委托。 | 我们已注意到多方利益相关方提出的这项请求,并正在研究相应解决方案。 我们会在 GitHub 上分享相关进展,并欢迎生态系统提供更多反馈。 |
设备端 | 为生态系统带来更多价值,以便继续投资于设备端 PA API 解决方案。 | Privacy Sandbox 团队将继续开发基于增强隐私保护技术 (PET) 的 API(包括 PA API),以便在浏览器中为开发者提供更多可保护隐私的选项。这些技术现在已广泛应用于 Chrome 浏览器(而并非像某些开发者误解的那样,仅占 1%)。无论用户是否启用 3PC,开发者都可以选择将基于 PET 的解决方案纳入其产品中,就像许多公司选择在浏览器之外采用其他基于 PET 的解决方案一样。许多开发者已经通过投资设备端 PA API 解决方案获益,他们扩大了确定性第一方受众群体信号,从而扩大了各个网站的覆盖面。我们了解到,只有在停用更多第三方 Cookie 后,部分开发者才会选择使用 Privacy Sandbox API 或其他基于 PET 的解决方案,而这些开发者正在等待相关信息,以便推测有多少浏览器会保留第三方 Cookie。我们知道,这些开发者会等到找到所需信息后再做出产品决策。 |
兴趣群体 | 允许 SSP 参与 IG 创建过程以及与之相关的角色。SSP 将其视为增值服务的重要组成部分,希望能够帮助发布商通过其 SSP 销售 IG。 | 我们已收到多方利益相关方提出的支持更高级别 IG 委托的请求,并认为 SSP 为此流程带来的附加价值。 我们正在研究,希望找到一种最佳解决方案,让不同的方能够参与受众群体扩展流程。随着该计划的推进,我们会在 GitHub 上分享最新动态,并欢迎生态系统提供更多反馈。 |
报告 | forDebuggingOnly API 和 Private Aggregation API 之间“非零出价”报告数量不一致。 | 我们预计会存在差异,原因有二: 首先,只有在设备上允许 3PC 时,Private Aggregation API 调试模式才可用,而 forDebuggingOnly API 始终可用且未采样(此行为最终会发生变化,详情请参阅此处)。 其次,Private Aggregation API 有贡献限制,而 forDebuggingOnly 没有。 不过,根据这些反馈,可能还有其他原因导致出现意外差异,我们正在与第三方利益相关方合作解决此问题。 |
点击率 | 如更新后的点击率信号提案中所述,系统会通过向“attributionsrc”属性启动的符合条件的请求返回新的 HTTP 响应标头来注册观看和点击,并且此响应标头将包含来源列表,该列表可用于指明哪些其他方可以将这些观看和点击计入其汇总计数。这是否意味着广告技术平台可以任意设置来源? | 点击率说明中规定,向汇总的浏览次数和点击次数贡献了浏览或点击事件的广告技术平台(“提供来源”)可以在响应标头中添加一个可选参数,以便指定“一个或多个 IG 所有者来源,系统可能会在计算的浏览次数和点击次数中包含此事件,并将这些数据提供给 Protected Audience 竞价中的 generateBid() 调用”(“符合条件的来源”)。不过,这些观看和点击次数不会自动计入观看次数和点击次数。相反,每个广告技术平台都必须在其 IG 中指定一组“提供来源”,其中应包含要包含的观看和点击事件,并且只有来自这些提供来源的数据才会计入向该广告技术平台的 generateBid() 调用显示的观看次数和点击次数。此机制需要双方达成协议,并可防止恶意参与者影响其他广告技术平台的观看次数和点击次数。这也意味着,如果“提供方”广告技术平台任意设置“符合条件的来源”,则不会影响这些符合条件的来源的浏览和点击次数,除非这些符合条件的来源在其 IG 中明确且有意地包含该提供方来源。 |
私人模型训练 | 在某些情况下,DP-SGD(差分隐私 - 随机梯度下降法)会破坏在反向传播期间计算的梯度的稀疏性,从而使训练过程大大减慢。您是否考虑过使用什么方法来解决此问题,或者对此有何想法? | 我们知道一些可在 DP-SGD 中保留稀疏性的技术(例如此技术),并且正在探索在私密模型训练基础架构中支持此类技术。 我们会随着进展分享最新动态,欢迎您在此处提供更多反馈。 |
排除性定位 | 请求了解有关在 Instagram 上推出此处所述的负面过滤功能的最新动态。 | 正如我们在此处的回复中所述,我们计划在 PA API 出价中支持否定 IG。 我们将在有可用发布时间表时分享,欢迎您在此处提供更多反馈。 |
出价 | 在出价时,能否组合使用多个 IG? | 目前无法使用 PA API 执行此操作。PA API 的设计基于以下理念:IG 与单个网站对用户的了解相关,这一直是与整个生态系统讨论的核心。这种方法让广告技术平台能够构建各种解决方案,帮助广告客户在网络上扩大其第一方受众群体。 我们知道,Microsoft 的 Ads Selection API 提案确实提出了一种不同的设计,即受众群体基于各个网站上的信息。 虽然我们会继续监控他们的做法,但在考虑对 Chrome 进行类似更改之前,我们希望先看到生态系统(包括隐私保护社区)中进行更多讨论。 |
原生广告 | 关于 PA API 能否充分支持原生广告的多种格式和呈现要求,以及 PA API 能否实现有效原生广告所需的广告素材灵活性和优化功能的疑虑。 | 我们正在积极研究如何为原生广告提供进一步的支持,欢迎生态系统提供更多反馈。 |
报告 | 请求改进报告脚本的稳健性。报告脚本与出价脚本争夺资源,并且可能会在用户离开正在运行的竞价框架时丢失。 | 我们希望尽快在 GitHub 上发布回复,但我们认为这些问题在实践中不会对有效报告产生重大影响 |
宏替换 | 通过的竞价配置宏替换项不适用于某些第三方配置。 | 根本原因是,并非所有标记为模式 A/B 的流量都已启用此功能。我们最近决定为所有标记为“模式 A/B”的流量启用此功能(以及在相同情况下的其他功能)。我们预计会在 2025 年第 1 季度进行这项变更。 欢迎您在此处提供更多反馈。 |
文档 | 由于文档中关于 generateBid() 中 browserSignals 对象中的新近度值的测量单位存在差异,因此需要澄清一下。 |
我们已在此处详细回复了这个问题,并相应地更新了文档。正确答案是测量单位为毫秒。 |
报告 | 请求第三方报告;虽然 DSP 和 SSP 会收到 Chrome 发送的展示通知,但中间层技术提供商默认不会收到。 | 我们目前正在此处讨论此功能请求,欢迎您提供更多反馈。 |
兴趣群体 | 请求有关如何在使用并行 IG 竞价工作流时动态排除 interestGroupBuyer 的指导。 | 我们在此处提供了相关指导。 |
原生广告 | 针对给定网页加载的独立 PA API 竞价可防止同一网页上的广告被滤除。 | 我们正在积极研究如何进一步支持原生广告,包括被称为“原生”且在一个单元中包含多个广告的推荐 widget。我们承认,目前的设计可能不支持同一网页中的广告过滤,并且 Fenced Frames 等其他保护措施可能也会进一步阻止这种过滤。 |
原生广告 | 现有的 PA API 功能(例如广告素材扫描、报告等)可能需要进行调整,以便处理原生广告素材中使用的 JSON 对象,因为这些功能依赖于基于网址的信号。 | 我们正在积极研究如何进一步支持原生广告,并评估是否可采用 PA API 来帮助呈现原生广告。 |
广告验证 | 由于 perBuyerSignals 的延迟时间和缓存限制,PA API 中的第三方品牌保障功能受到影响,这会导致动态内容出现问题。 | 我们认识到,SSP 和 DSP 需要确定适合缓存的最佳 TTL,以平衡流量塑造目标和品牌安全最大 TTL,确保缓存的数据仍然与品牌安全相关。我们正在研究此问题,并会在有新进展时分享最新动态。 |
广告验证 | 为了进行出价后的品牌保障效果衡量,需要 SSP 进行 Fullpage网址 宏替换。 | 目前建议 SSP 使用 deprecatedReplaceInURN 提供此信号。 |
广告验证 | SSP 用于出价后验证的宏格式缺乏标准化,可能会导致数据处理和分析出现不一致和错误。 | SSP 和广告验证工具应直接合作,就宏的使用制定明确的指南和规范,以推动各个 SSP 采用标准化的宏格式,从而确保一致性并防止数据处理和分析出现错误。这项工作非常适合 IAB Tech Lab 等广告标准组织来完成。 |
广告验证 | 广告客户和广告验证工具需要一种机制来关联同一发布商情境的出价前和出价后检查,以便进行调试和问题排查。 | 出价后验证的一个选项是,通过纳入事件级报告中的竞价和广告系列信号来实现。这可能支持与出价前决策日志联接。我们正在探索实现此目标的可能模式,并会在进展时分享最新动态。 |
广告验证 | 请求探索可用于出价前的信任密钥值 (TKV) 服务器解决方案(DSP 自有和广告验证程序自有),并解决出价后受限于围栏框的问题。 | 我们正在评估此请求,欢迎生态系统中的各方通过此处提供更多反馈,以便我们找到可支持出价前品牌保障的解决方案,并简化各方之间的协调要求。 |
原生广告 | 请求对原生广告的卖方出价后呈现进行审核。 | 我们正在积极研究如何进一步支持原生广告,并考虑改进此类现有功能,以便更好地呈现原生广告。 |
Protected Auction(B&A 服务)
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
延迟时间 | 没有足够的延迟缓解措施。虽然 B&A 服务可能会从长远来看缓解此问题,但在 Chrome 上的 3PC 发生变化之前,Google 尚未承诺广泛提供此服务。 | 在过去几个季度中,我们对设备端延迟时间进行了多项改进。我们还会根据需要构建和扩展 B&A 服务。我们最近更新了延迟时间最佳实践指南,其中详细介绍了如何利用这些功能。我们还在不断改进延迟时间,其中一些改进措施可参见此处。 |
(也已在上一季度报告) 竞价安全 |
要求进一步说明如何防范/减少篡改设备端竞价的尝试(例如,包括 Google 是否认为这是一种重大风险)。 | 我们的回复与上个季度保持不变: “PA API 广告的报告机制会保留目前用于区分人流量和机器人流量的信息。此外,您还可以在 PA API 中使用当前基于网域的包含或排除网域的技术。如需了解详情,请参阅我们对 IAB Tech Lab 关于 Privacy Sandbox 的报告的回复。” |
本地解决方案 | 担心由于缺乏对私有云的支持,以及支持私有云的路线图冗长且不透明,因此大型供应商可能不会采用 Privacy Sandbox 或 B&A。 | 我们致力于扩展 Privacy Sandbox 服务所依托的基础架构;我们最近宣布了对 Azure 云的支持,并将继续研究可能的解决方案,以便为私有云提供类似的隐私和安全保护措施。 自 10 月份与您沟通以来,我们一直在研究在本地可信执行环境 (TEE) 中保护 Chrome 用户隐私的潜在方法,并取得了进展。目前,我们在研究中处于一个阶段,希望与生态系统利益相关方一起验证不同的方法,并计划在第一季度开始收集反馈。生态系统反馈和协作有助于优化所有可能的解决方案。 |
测试 | 是否可以创建 TEE 来测试 PA API 报告解决方案(实时报告和私密汇总)? | 对于汇总服务测试,广告技术平台可以使用测试数据和本地测试工具生成功能测试的摘要报告。请点击此处参阅本地测试 Codelab。 如需在 TEE 中测试汇总功能,广告技术平台需要完成上述 Codelab 前提条件中所述的注册流程。 欢迎您点击 此处,就此请求提供更多反馈。 |
交易键值对集成 | 请求能够根据业务用例从 KV 中提取交易相关信息。 | 我们正在评估此功能请求,并会在 GitHub 上提供最新动态。 |
无赢 交易衡量 |
请求信号或能够了解 SSP 未胜出以及原因。 | 我们正在评估此请求,并会在 GitHub 上提供最新动态。 |
功能请求 | 请求 Privacy Sandbox 提供字典结构,以帮助将一组广告与相应组的交易 ID 进行匹配。 | 我们正在评估此请求,以及其他用于缩减与存储交易 ID 相关的 IG 大小的方法。我们会在 GitHub 上提供最新动态。 |
性能 | 解决方案:衡量可能因出价脚本大小而错失的广告竞价机会。 | 我们正在评估此请求,欢迎您点击此处提供更多反馈。 |
规格 | 目前,B&A 仅读取 prevWins 字段,而不是在规范中取代 prevWins 的最新字段 prevWinMs。 | 确实,B&A 不会将 prevWins 中的时长(以毫秒为单位)传递给 generatebid() 。Chrome 以秒为单位发送时长,以确保载荷开销更低,这里的解决方法是让 B&A 将秒转换为毫秒。B&A 会在 browserSignals 中同时提供 prevWins 和 prevWinsMs,以使其与设备端竞价兼容。请注意,即使对于网站的设备端竞价,prevWins 和 prevWinsMs 也对应相同的值,并且 prevWinsMs = prevWins * 1000。 我们正在优先解决此问题。 |
文档 | 文档中未明确说明如何测试卖家前端 (SFE),如果在完成部署后能提供额外的测试指南以及如何使用 Bazel 进行构建,将会很有帮助。 | 此 Codelab已发布,旨在为更广泛的生态系统提供指导,以便更轻松地测试其 SFE。 |
部署 | 是否计划为 B&A 提供预构建二进制文件? | 我们正在考虑为 B&A 提供预构建二进制文件,但目前还没有具体的时间表。在此之前,广告技术平台可以自行构建二进制文件,并使用提供的哈希进行验证。 |
部署 | 是否应支持所有编排类型(服务器、客户端、混合),还是应优先支持某种类型? | 我们无法就广告技术平台应采用哪种模式提供任何具体建议。具体选择取决于多种因素,但归根结底,要看哪种方式最符合客户的利益。 |
测试 | 希望澄清有关 B&A build 期间失败的测试的问题。 | 这可能是测试不稳定所致。我们已建议广告技术平台对所有 build_and_test_all_in_docker build 命令使用 --no-tests 标志,以跳过运行测试。 |
日志 | 想了解为什么在测试模式下,GCP 日志浏览器中的日志会标记为运行 SFE 的虚拟机实例,但在生产模式下,日志不会标记为虚拟机实例。 | 这很难概括,因为具体取决于看到的内容,但总的来说: - 来自 non_prod 的日志可能是云服务提供商(在本例中为 GCP)重定向的 stderr 日志,GCP 添加了标记。 - 虚拟机生成的日志通常带有虚拟机实例标记,而二进制文件生成的日志不会被 GCP 标记。 - 来自 prod 的日志由 TEE 中的 Open Telemetry 导出,具有不同的标记。 点击此处可详细了解 non_prod 和 prod 中提供的内容。 |
B&A | 停用 OTEL 日志记录后,系统会因缺少 Secret 而出现 403 错误。 | 此问题现已在 4.1 更新中得到解决,文档也已相应修改。 |
B&A | GCP Terraform 配置缺少 outputs.tf 文件,导致出现错误。 | 此问题现已解决。 |
测试 | 在测试模式下提取私钥时出错。 | 在这些情况下,请确保服务器在 TEST_MODE=true 的情况下运行。 如需查看说明,请点击此处。 |
路线图 | 是否计划让 getInterestGroupAdAuctionData 接受多个卖方来源,并返回卖方来源与 B&A 载荷密文之间的映射? | 是的,我们计划添加支持,以允许 navigator.getInterestGroupAdAuctionData() 接受多个卖方。 |
KV 规范 | KV 网址 (trustedScoringSignals网址) 是否可以作为 promise 提供? | 请参阅此处提供的说明。 |
B&A | 请求创建新的平台标头,以向 B&A 卖方表明客户端(浏览器)需要哪些功能才能进行私下竞价。 | 我们目前正在此处讨论此功能请求,欢迎您提供更多反馈。 |
流量整形 | 提案:降低托管 B&A 服务器的增量费用,尤其是 DSP 的费用。 | 我们目前正在此处讨论此提案,欢迎您提供更多反馈。 |
自带二进制文件 |
考虑更新说明,明确说明所有二进制文件均受支持。 | 此政策现已更新,请点击此处查看说明。 |
KV 调用 | generateBid() 是等待所有键值对 (KV) 存储调用完成,还是独立运行?KV 批处理对其时间有何影响? |
请参阅此处提供的说明。 |
性能 | 请求提供有关重复使用出价脚本和建议在脚本中设置缓存控制标头的其他文档。 | 我们已在此处添加了相关文档。 |
性能 | 请求考虑和探索异步加载资源(例如出价脚本)的功能,以缩短设备端竞价延迟时间。 | 我们目前正在此处讨论此功能请求,欢迎您提供更多反馈。 |
意见征求日志记录 | 需要澄清一下,在尝试通过设置 CONSENTED_DEBUG_TOKEN 使用意见征求日志记录时出现的错误。 | 在这些情况下,请检查 Secret Manager 中是否存在 CONSENTED_DEBUG_TOKEN,是否将 ENABLE_OTEL_BASED_LOGGING 设置为 true,以及是否将 TELEMETRY_CONFIG 设置为 mode: PROD。 如需查看说明,请点击此处,其中引用了此处的来源。 |
日志 | 是否可以通过 B&A 使用 forDebuggingOnly 事件? | 自 2024 年 4 月起,B&A 的 forDebuggingOnly 已适用于单卖方竞价。我们计划很快为多卖家竞价启用此功能。 |
worklet 日志 | 请求使 Worklet 日志记录与 ChromeDriver 兼容。 | 我们正在评估此请求,欢迎您点击此处提供更多反馈。 |
衡量数字广告的效果
Attribution Reporting API(及其他 API)
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
调试报告 | 在 Chrome 上更新了第三方 Cookie 方法后,广告技术平台将如何获取 ARA 调试报告? 对于保留了第三方 Cookie 且启用了 Privacy Sandbox API 的用户,广告技术平台是否仍应有权访问 ARA 调试报告? |
对于同时启用 3PC 和 ARA 的用户,广告技术平台将能够使用基于 Cookie 和无 Cookie 调试解决方案。停用 Cookie 后,他们将只能使用汇总调试解决方案。 如需详细了解调试解决方案,请点击此处和此处。 |
特征检测 | 请求有关如何在服务器端为 ARA 执行特征检测的指导。 | 目前,可以根据用户代理字符串中显示的 Chrome 版本来确定 ARA 功能支持情况。 我们欢迎您就此提供更多生态系统反馈。 |
功能请求 | 请求在 ARA 汇总 shared_info 中使用的 source_registration_time 更精细,例如向下舍入到 1 小时或 1 分钟(而不是 1 天),并且可配置以考虑时区(目前仅限世界协调时间 [UTC])。 | 将 source_registration_time 字段舍入到最近一天是一项隐私保护机制,用于降低广告技术平台将特定用户与特定来源注册相关联的能力。目前,source_registration_time 基于 UTC,广告技术平台可以调整其广告报告以反映这一点。 欢迎您点击此处,针对此请求提供更多生态系统反馈。 |
规格 | 请求阐明“trigger_data”和“priority”的规范,尤其是在与数组值搭配使用时。 | 这些字段不接受数组值。说明中的方括号并不代表数组,而是表示相应文本不是示例值,而是带有说明的占位符。 正如方括号中的文本所示: - trigger_data 是 int-64 - priority 是带符号的 int-64 这两个字段都不接受数组值。如果文档令人困惑,不妨考虑使用 ARA 的标头验证器工具来尝试不同的值,并在遇到错误时进行修正。 |
支持 Accelerated Mobile Pages (AMP) 广告 | ARA 是否支持 AMP 广告? | 您可以点击此处查看我们关于如何支持 AMP 的提案,我们也欢迎您提供更多反馈。 |
规格 | 对于 ARA 的多层嵌入式广告,哪个网址将被视为“来源网站”? | 顶级网站的网址。 |
(也已在上一季度报告) 功能请求 |
请求将 event_report_window 最小值从 3600 秒(1 小时)降低到 1800 秒(30 分钟)。 | 确定最短报告期需要平衡实用性和隐私保护方面的考虑。 为确保隐私保护并防范特定类型的历史重建攻击,事件级报告必须设置最短 1 小时的报告期。 欢迎您点击此处,就此请求提供更多反馈。 |
噪音 | 深入了解 ARA 事件级报告中如何实现噪声,以确保准确解读和利用数据。 | 如需了解详情,请点击此处和此处。 |
报告 | 默认情况下,汇总报告的 shared_info 不再包含 source_registration_time。 | 这是由于 API 发生了变化,详情请参阅此处。 |
报告 | chrome://attribution-internals/ 界面的“可汇总报告”标签页中缺少 filtering_id 。 |
目前,当您点击某行时,“触发器注册”标签页详情中会显示 filtering_id ,以便您确认其有效性。我们知道在“可汇总的报告”标签页中显示此维度很有用,并已在此处解决了这个问题。 |
归因来源 | 请求说明归因来源的运作方式。 | 如需了解详情,请点击此处。 |
应用到网站归因 | 请求有关实现的指导,因为不确定来源是操作系统还是网站。 | 如需相关指南,请点击此处。 |
汇总服务
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
功能请求 | 请求为 AgS 配置超时设置,以及/或者为长期运行的作业提供更高的作业状态可见性。 | 我们正在考虑推出一些功能来支持监控长时间运行的作业。 我们欢迎您就此提供更多生态系统反馈。 |
Terraform | Terraform 会尝试修改账号 IAM 政策,即使未设置 service_account_token_creator_list 也是如此。 | 开发者可以在其本地 modules/adtech_setup/main.tf 文件中添加其添加的权限。 |
文档请求 | 请求文档或 Codelab,了解如何监控汇总服务运行状况。 | 如需了解可用于监控服务和作业运行状况的现有警报,请参阅 coordinator-services-and-shared-libraries 仓库中的相关操作器 Terraform 文件 (alarms.tf 和 monitoring.tf)。 我们将发布有关如何监控汇总服务作业的更多文档和指南。 |
扩缩 | 如何监控扩缩问题? | 我们发布了此指南的更新版本,其中记录了汇总服务的更高规模。 目前没有直接信号表明作业因机器无法支持其规模而失败。间接信号包括:失败前内存用量达到 90%、作业反复失败。我们欢迎生态系统就是否需要此类信号提供更多反馈。 |
规格 | AgS 报告批次的典型运行时间是多少? | 请参阅此处的指南。 |
Private Aggregation API
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
功能请求 | 请求允许将浮点值(包括负值)贡献到 contributeToHistogramOnEvent,敏感度为 2^16 | 我们目前正在此处讨论此提案,欢迎您提供更多反馈。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
本季度未收到任何反馈。
IP 保护(以前称为 Gnatcatcher)
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
地理定位 | 请求 IP 保护地理位置文件。 | 如需获取用于 IP 保护的 IP 地址与大致位置的映射文件,请点击此处。请注意,此文件会定期更新。 |
跳出跟踪缓解措施
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
许可名单 | 更新后的立场不再涉及与 Google 的决策流程无关的许可名单或类似机制。 | Google 不打算创建任何与弹跳率跟踪缓解措施 (BTM) 相关的许可名单;这些保护措施会统一应用于所有网域。 |
合规性 | ICO 应对隐私权相关合规性拥有管辖权。 | 合规性状态与 BTM 的应用无关,Google 不会就 BTM 实施的合规性做出任何决定。 |
竞争程度 | 似乎 Google 可以使用 BTM(或其他措施)排除 PET 竞争对手,然后自行决定是否允许他们重返市场。目前的申诉流程可能会暂时禁止 PET 竞争对手使用 BTM 或类似措施。 | 当前的 BTM 提案旨在将跳出率跟踪作为一种技术。虽然 Google 旨在避免破坏可能涉及类似技术的特定用例,但没有计划针对 BTM 提供个别豁免。因此,Google 是否应对竞争对手的存在情况行使自由裁量权的问题不存在。 |
增强跨网站隐私边界
Related Website Set(以前称为 First-Party Set)
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
(也已在上一季度报告) 相关网站集 (RWS) 网域数上限 |
目前,关联网域的数量上限为 5 个,这还不够用来实现跨网站衡量用例。 | 我们的回复与上几个季度类似: 目前,我们不打算提高数字上限。此限制是根据用户隐私保护方面的考虑、W3C 生态系统利益相关方的反馈以及其他浏览器中的类似实现情况 而制定的。如需了解详情,请参阅我们的博文 (1、2)。 我们建议您检查需要超出数字限制的跨网站 Cookie 访问权限的用例,并考虑利用我们针对身份用例、经过身份验证的嵌入和广告用例的指南。 欢迎您点击此处就此问题提供更多反馈。 |
Fenced Frames API
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
原生广告 | 在围栏框架中呈现原生广告会带来挑战,因为由于 iframe 与发布商网页之间的通信受到限制,因此继承发布商的样式受到限制。 | 对原生广告的进一步支持(包括在强制执行围栏框后提供支持)是一个热门研究领域。 欢迎您点击此处就此问题提供更多反馈。 |
Shared Storage API
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
API 应用 | 在某些设备上,即使其他 Privacy Sandbox API 可用,共享存储空间 API 也不可用。 | 参与“共享存储空间”隔离实验的一小部分用户(约 1%)可能会出现这种行为。此实验设置用于评估 API 在各种场景中的性能和采用情况。 |
API 应用 | 对共享存储空间的写入是发生在发布商来源还是出价脚本来源下?初步测试表明,当发布商来源与脚本来源不同时,不会进行任何写入。 | 此问题已得到解决,仅在可能存在 devtools 错误的情况下仍保持打开状态。如需了解详情,请点击此处。 Shared Storage 会在 generateBid 调用的出价上下文中写入买方来源。写入操作与发布商来源无关,即使发布商网页位于其他网域也是如此。 |
API 应用 | 为了防止不法分子读取“共享存储空间”报告,我们采取了哪些保护措施? | 通过调用origin 对共享存储空间进行分区,以便恶意行为者或广告技术平台无法从其他广告技术平台读取共享存储空间数据。私密汇总报告会通过 TLS 直接发送到同一来源,因此无法被拦截。 |
CHIPS
反馈主题 | 摘要 | Chrome 回复 |
---|---|---|
分区 Cookie | Chrome 和 Firefox 中对不同 localhost 端口的 Cookie 处理方式不一致,尤其是在使用 Partitioned 属性时。 | Firefox 会将使用不同端口的 localhost 视为不同的分区键。虽然此行为符合安全原则,但与规范和 Chrome 的方法不符。 我们预计会在 HTML 规范讨论中与其他浏览器讨论此问题,如果这导致 CHIPS 分区键发生变化,我们会通知整个生态系统。欢迎您点击此处,就此问题提供更多反馈。 |
分区 Cookie | Clear-Site-Data 草稿错误地允许清除发送方网站的分区之外的数据,这与此处提及的先前讨论相矛盾。 | 这是标准规范文档中的 bug,我们打算尽快修复。说明文档的此部分中指定了正确的行为,该行为与存储分区说明文档代码库中与其他浏览器一致的行为一致。Chrome 的实现已正常运行。 |
FedCM
本季度未收到任何反馈。
打击垃圾内容和欺诈行为
Private State Tokens API(及其他 API)
本季度未收到任何反馈。