2023 年第 4 季度的季度报告，总结了生态系统收到的关于 Privacy Sandbox 提案和 Chrome 响应的反馈。
根据对 CMA 的承诺，Google 同意公开提供季度报告，说明其 Privacy Sandbox 提案的利益相关方互动流程（请参阅承诺的第 12 段和第 17(c)(ii) 段）。这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈概览中列出的各种来源收到的反馈生成的，这些来源包括但不限于：GitHub 问题、privacysandbox.com 上提供的反馈表单、与行业利益相关方召开的会议，以及网络标准论坛。Chrome 欢迎您从生态系统中获得反馈，目前正在积极探索将所得知识整合到设计决策中的方法。
反馈主题按每个 API 的普遍性进行排名。为此，Chrome 团队会汇总 Chrome 团队就特定主题收到的反馈量，并按数量降序整理。我们通过查看公开会议（W3C、PatCG、IETF）、直接反馈、GitHub 以及通过 Google 内部团队和公开表单提出的常见问题，确定了常见反馈主题。
具体而言，我们查看了 Web 标准机构会议的会议记录，对于直接反馈，还考虑了 Google 的 1 对 1 利益相关方会议记录、个人工程师收到的电子邮件、API 邮寄名单和公共反馈表单。然后，Google 协调参与这些各种推广活动的团队，以确定每个 API 新出现的主题的相对普遍性。
Chrome 对反馈的回应说明是根据发布的常见问题解答、对利益相关方提出的问题的实际回应，以及出于此公开报告练习目的专门确定的立场制定的。体现当前开发和测试的重点，以及所收到的问题和反馈，尤其是与 Topics API、Protected Audience API 和 Attribution Reporting API 相关的问题和反馈。
当前报告期结束后收到的反馈可能尚未被视为 Chrome 响应。
首字母缩略词词汇表
- 条状标签
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- Federated Credential Management
- FPS
- First Party Set
- IAB
- 美国互动广告局
- IdP
- 身份提供方
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- 源试用
- PatCG
- Private Advertising Technology Community Group
- RP
- 依赖方
- 供应方平台 (SSP)
- 供应方平台
- TEE
- 可信执行环境
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- 开发中
- 自愿 IP 盲目
一般反馈，不涉及具体 API 或技术
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 3PCD 时间表 | 分享有关第三方 Cookie 时间轴的更多信息。 | 为方便测试，自 2024 年 1 月 4 日起，Chrome 默认限制 1% 的用户使用 3PC。为了解决 CMA 中仍有待解决的问题，Chrome 计划从 2024 年第 3 季度开始逐步停止对 3PC 的支持，并会在 2024 年余下的时间里继续完成。 |
| 3PCD 时间表 | 3PCD 在 2024 年第 4 季度的影响，因为正好恰逢节日季，可能会对发布商产生负面影响。 | 目前目前还没有弃用 3PC 的最佳时机。一年多来，我们都明确表示我们打算在 2024 年下半年弃用 3PC。我们对 CMA 的承诺（包括可能进入“停滞期”的时间）没有发生变化。虽然我们理解对第 4 季度时间安排的担忧，但实施时间表上的变化会减少行业准备，而非更多。 |
| Chrome 测试（模式 a/b） | 模式 A 和模式 B 的测试设置是按实例还是按 Chrome 配置文件设置？ | 我们已在此处的文档中发布澄清说明，此处的 Chrome 浏览器指的是 Chrome 客户端：在设备上安装 Chrome。各个用户数据目录构成不同的客户端。 |
| 弃用试用 | 分享有关第三方试用的更多信息。 | 我们在此处分享了有关第三方 Cookie 试用的更多信息。 |
| 弃用试用 | 时间不足，无法在 2024 年 1 月之前为所有网站提供弃用试用令牌。 | 我们了解，从弃用试用注册开放到 Chrome 协助测试期开始屏蔽 1% 的 Cookie 之间要过一小段时间。为了解决这些时间限制，Chrome 为参与该计划的来源提供了宽限期，让他们在部署弃用试用令牌期间会遇到这种情况。在宽限期（一直到 2024 年 4 月 1 日）内，对于已注册弃用试用的源，即使尚未部署其令牌，也能在 Chrome 中访问 3PC。此宽限期的目的是防止过渡阶段出现 Web 兼容性问题。参与计划的源必须在宽限期结束之前部署弃用试用令牌，才能在宽限期结束后继续访问第三方 Cookie。 |
| Chrome 测试（模式 a/b） | 模式 B 的样本过小，无法准确衡量性能下降情况。 | 因此，您需要在流量百分比和对整个网络的用户和功能产生影响的风险之间找到平衡。 |
| 测试控件 | 只有拥有大量开发资源的大型发布商才能在测试期间了解效果，并将这些数据传递给 CMA。 | 我们已经看到发布商服务提供商在与更广泛的生态系统中公开分享数据洞见，预计随着 Privacy Sandbox 测试的增多，这种情况将持续下去。我们还预计，基于 Privacy Sandbox API 构建的广告技术公司将继续开发其客户所需的功能，例如基于标签的报告。 |
| 第三方数据 | 第三方数据公司的顾虑。 | 第三方数据公司有不同的风格。有些网站可能会双倍投入，转向更加不透明的跨网站跟踪方法。其他公司可能会利用可强化隐私保护的技术并针对其客户提出新的价值主张。我们希望更多人选择后者，并朝着用户和监管机构要求越来越高的方向前进。变革将带来进化和创新的机会。 |
| Google Ad Manager | 需要就发布商如何测试 Privacy Sandbox 提供更多 Google Ad Manager 指导。报告不足，发布商无法了解相关影响。 | Google Ad Manager 提供的回复： Google Ad Manager 在其帮助中心中解释了将如何使用 Chrome 协助测试标签进行测试。 Ad Manager 目前向发布商提供关于 Topics 和 Protected Audience 的报告。截至提交这份反馈报告时，Ad Manager 可以报告通过 Protected Audience API 投放的展示，并且可以指明给定展示中是否存在来自 Topics API 的数据。 如果发布商希望使用更复杂的报告（例如根据 Chrome 协助提供的标签来细分报告），则可以直接在 Chrome 中读取标签（参阅 Chrome 文档），然后在广告请求中将这些标签作为键值对传递到 Ad Manager，然后以键值对报表的形式为标签生成报告。 |
| 测试奖励 | 广告客户担心 Privacy Sandbox 有足够的时间进行测试，以及 API 可能发生重大变更。 | 我们理解有些人希望有更多时间，但业内反复听到，改变时间表可能会导致生态系统准备减弱，而不是更多。虽然 CMA 对弃用 3PC 的时间安排有待解决，但我们也鼓励所有人为 2024 年 3PCD 做好准备。 与所有技术一样，Privacy Sandbox API 也将不断发展。这种发展源于技术进步和生态系统投入。我们在做出改变时将继续负责，不会认为技术的变化会无限期地阻碍人们使用。 |
| 联网电视 | 没有支持线性视频广告或联网电视视频广告的路径。 | 我们期待进一步探索联网电视用例，但不要认为适用于 CTV 设备的 API 会阻碍 Chrome 中的第三方 Cookie。 |
| 广告客户广告服务器 | Google 似乎在将广告定位转移到 DV360。将为广告客户的广告服务器提供哪些支持？ | Chrome 提供的响应： PA API 旨在帮助广告主的广告服务器使用 iframe / 围栏框架和信标报告来投放和衡量向用户展示的广告。此外，他们还会与上游和下游各方合作，以便集成到投放流程中，就像现在一样。 |
| Google Ads 数据管理器 | 近期宣布了“Google Ads 数据管理器”，它以目标客户匹配和增强型转化为基础，让广告主能够与 Google 共享自己的第一方客户数据，从而维持 3PC 所执行的所有营销功能。这项新功能如何与 Google 对 CMA 的承诺相符？ | Google Ads 提供的响应： Google Ads 数据管理器只是方便广告主从广告主数据存储系统（云系统）上传第一方数据，以供广告主用于目标客户匹配 (CM) 和增强型转化 (EC)，从而为技术资源较少的中小型企业带来便利。对于 Google 自有自营 (CM) 或第三方发布商投放的广告的可寻址或可衡量性，Google Ads 数据管理器不会为 CM 或增强型转化启用任何全新功能。 Google 的广告平台可使用的 Privacy Sandbox 技术中提供的功能与其他广告技术公司相同。 |
| Chrome 浏览器设置 | Chrome 的内部设置页面应提供有关 Cookie 大小的更多信息。 | Chrome 开发者工具中已提供请求的功能。欢迎大家就为何应在设置页面中优先使用此功能提供反馈意见。 |
| 启发词语 | Chrome 部署了哪些启发法来在 3PCD 期间保留关键用户体验？ | 请参阅我们对 GitHub 上此问题的回复。 |
| 浏览器版本 | 区分稳定版与不稳定的 Chrome 浏览器？ | 这样即可粗略匹配 Chrome 主要版本与稳定发布周期。 |
| 法规遵从 | Chrome 能否提供与 SOX 相关的报告？ | Chrome 不会提供与 SOX 相关的报告。Privacy Sandbox API 是 Chrome 可供用户访问的网站使用的众多网络 API 之一。与所有网络 API 一样，API 调用方不会与 Chrome 签订关于使用 Privacy Sandbox API 的协议；访问权限仅取决于 API 调用方是否符合任何技术要求，以及用户是否启用了相应设置。如果是这样，API 调用方将单独决定如何使用该 API，包括要存储的数据、要的出价、要请求的报告等。 |
| 法规遵从 | 扩展了 Privacy Sandbox 合规性常见问题解答，以解决更多问题。 | 非常感谢您的反馈，我们计划进一步完善常见问题解答。 |
| Chrome 问题 | 在 Chrome 上弃用 3PC 是否会影响 Android WebView（嵌入式浏览器）上 3PC 的可用性？ | 除了支持跨应用和跨网站归因衡量之外，我们目前不在 3PCD 或 Privacy Sandbox API 的此阶段推出和测试 WebView。 |
| API 问题 | 如何跟踪赞助商产品的点击次数和展示次数？ | Attribution Reporting API 已涵盖此用例。 |
| 时间表 | 为什么 3PCD 的时间表发生了变化？ | 我们已在此处讨论了原因。 |
| Chrome 扩展程序单点登录 | 在启用 3PCD 之后，允许在网站和 Chrome 扩展程序之间进行单点登录。 | 我们正在讨论此问题，欢迎针对其他用例提供反馈。 |
| API 用量 | Google 能否确认用来测试 API 的合作伙伴名单？ | 对于以下 API，您可以前往 GitHub，详细了解已公开表明自己身份的测试人员： - Topics API - Protected Audience API - Attribution Reporting API - 共享存储空间 - CHIP |
| Utiq 计划 | Chrome 对 Utiq 计划有何看法？ | 我们将在此处讨论这一点。 |
| Chrome 问题 | 如何检测在不使用 3PC 的情况下浏览的用户？ | 没有明确设置可用于检测 3PC 屏蔽。对于常规的“功能检测”方法，我们建议您创建 iframe / 跨网站请求，并尝试根据所需用例设置类似的 Cookie，这是最接近的解决方案。 |
| Chrome 问题 | 在无痕模式下浏览与运行 flag 测试（使用 --test-third-party-cookie-phaseout 命令行 flag 启动 Chrome）一样吗？ | 无痕模式与 Google 旗帜模式不同。该标志不仅可以阻止 3PC，还会启用 FedCM 和第三方存储分区。 |
| Chrome 问题 | 详细了解当 1% 的地区实现 3PCD 时，每个国家/地区的预计影响是什么。 | 在全球范围内，客户会随机计入这 1%，但可能会因地区而异。例如，设备类型和 Chrome 版本可能存在差异。 |
| 替代性隐私保护增强技术 | 应允许替代性隐私保护增强技术执行可保护隐私的跨网域跟踪，以防止 Chrome 和 Android 上出现数据霸权。 | 开发者有充足的机会基于我们提供的基础组件以及非 Privacy Sandbox 基础组件构建隐私增强技术产品。 |
| CookieGraph 研究 | Chrome 如何看待这篇白皮书在 Privacy Sandbox 框架内使用 CookieGraph 方法？ | 我们正在审核此白皮书，欢迎您提供其他反馈。 |
注册和证明
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 注册有限制 | Google 推出了 Privacy Sandbox API 的具体使用条款。条款可有效防止那些专门帮助发布商识别已同意访问者测试和/或将 Privacy Sandbox 功能集成到其身份解决方案中的公司。条款及条件不公平地限制了其在 Privacy Sandbox 中的运作能力。 | 注册和证明流程不涉及同意 API 使用条款。注册和证明机制旨在更清楚地了解哪些开发者调用了 Privacy Sandbox API 以及他们如何使用所访问的数据。具体而言，证明是一种公开声明，表明证明开发者不会使用这些 API 跨网站或应用识别用户身份，也不会以其他方式规避 API 的隐私保护。该证明不要求声明开发者使用其他数据或技术的情况。 |
| Privacy Sandbox 注册 | 如何更新用于证明的联系人 / 电子邮件地址？ | 您可以使用注册表单更新注册信息。如需了解更多详情，请点击此处。 |
| Privacy Sandbox 注册 | 能否请您说明一下在证明不可用的情况下，访问权限被禁用的情况。 | 在拒绝已注册公司访问（衡量和相关性 API）之前，Privacy Sandbox 可让技术联系人为已注册的网站重新建立证明文件 3 周时间。 |
| Privacy Sandbox 注册 | 如何使用非生产端点在本地环境中测试 API？ | 我们已在此处回复了此问题。 |
展示相关的内容和广告
主题
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 对不同类型的利益相关方的实用性 | 发布商担心主题对以数据为依据的销售的影响。较大的网站会分配到一个常规的“新闻”主题，而不会有数据将其链接到特定发布商。专业发布商会泄露自己的数据，但只能获得有限的信息。 | 我们了解，与具有小众兴趣域的网站相比，具有一般兴趣域较多的网站所贡献的主题可能较少。但是，并非所有小众网站都会提供具有商业价值的主题。此外，这种变化也反映了现状，即在基于 3PC 的广告相关性系统中，一些网站能提供比其他网站更多的价值。Topics（以及整个 Privacy Sandbox）使发布商能够更好地控制与其合作的广告技术公司如何使用其信息。此外，通过 Topics 提供的信息也比现有信号更为粗略。 |
| 发布商广告服务器 | 使用专用广告服务器的发布商广告服务器可能无法直接观察 Topics API。 | 我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| 证明 | 扩大证明要求，以解决信息跨上下文传输的已知不良后果。 | 目前，认证的意图并非涵盖这一广泛风险，而是旨在解决 API 滥用问题。 |
| Topics 流量 | 目前获得的展示次数不足以进行测试。 | Chrome 了解了关于程序化生态系统中可用 Topics 数量的反馈。我们正在调查此问题的潜在原因，同时涉及浏览器内部和相关测试人员的调查。如有必要，Chrome 会评估潜在的 API 设计变更，以便在保护用户隐私的同时提高覆盖率和实现足够规模的测试。 |
| API 用量 | Topics API 是否有速率限制？ | 我们设置了一些 Topics 速率限制，以防止滥用行为并保护用户的网络体验。您可以点击 此处了解更多详情。 |
| V2 分类 | IAB 关于将主题详情包含在开放实时出价协议中的指南？ | 能，您可以点击 此处查看 IAB 关于在 Open RTB 协议中包含 Topics 的指南。 |
| 对第一方信号的影响 | 如果将精细主题分类 v2 与返回此精细细分的最高值（热门主题）的流程结合使用，广告数据市场就会失真。 | 与第 3 季度相比，我们的回答保持不变： “虽然更精细的 Topics 分类可能会间接地降低其他解决方案的吸引力，例如基于发布商第一方数据的解决方案或依赖于直接交易的解决方案，但在我们开发 Topics API 的过程中，我们的主要目标是确保它能够尽可能有效地支持所有利益相关方在采用 3PCD 之后针对用户兴趣投放的广告用例。我们坚信，提高 Topics 的实用性将会提高整体的竞争力，并使整个生态系统受益。” |
| 测试人员列表 | 您的发布商对 Topics 和 PA API 的采用情况如何？ | 我们无法分享此类信息。您可以参考测试人员 列表，在该列表中，发布商可以选择分享自己的测试状态。 |
| 主题选择 | 是否允许用户主动选择感兴趣的主题？ | 我们当然考虑过允许用户主动添加主题。我们不打算在短期内解决这一问题，但乐于在较长时间里进一步探索。 |
| 主题选择 | 如果广告技术平台在网站上放置代码来观察主题，他们能否知道可能会观察到哪些主题？ | 广告技术公司可以确定与网站关联的主题。此 API 不会实时共享此信息，因为它可能会产生延迟成本。 |
| V2 分类 | 由于 Topics 最多可返回 3 个 Topics，随着分类 v2 逐步推出，预期的行为是什么？ | API 仍会最多返回 3 个主题，并在响应中包含每个主题的相关分类版本。 |
| （在前几个季度也有报告） Topics 观察 |
允许发布商授权 Chrome 根据网页内容（例如头部或正文）对主题进行分类。 | 与第 3 季度相比，我们的回应保持不变： “我们之前考虑过提供根据网页内容对网站进行分类的功能；但出于隐私和安全方面的考虑，我们决定不再继续更新。该建议或许能缓解其中的部分顾虑，但目前尚不清楚这一点。由于 CMA 实验期即将到来，我们预计这项更改不会在 3PCD 之前发生。欢迎在此处提供其他反馈。” |
| 主题选择 | 主题是宽泛的，如何对网域进行分类？ | 我们仅使用主机名将网站归类到主题中。被广泛分类的网站不会因此而受到影响。这是因为网站的情境信息始终可用于其网站上的竞价，从而能够为宽泛的主题提供更具体的信息。 |
| V2 分类 | 希望主题与其他标准（例如 IAB）更加一致。 | 我们想要详细了解为什么他们希望 IAB 类目和 Topics 类目更加一致。他们需要采取哪些步骤才能采用 Topics API？更加明确的分类对这些步骤有何影响？我们正在考虑发布主题类目和 IAB 内容类目之间的对应关系。了解这样做能否解决发布商面临的挑战将大有裨益。 |
| 数据存储和使用 | 您能否详细了解数据的存储和传输位置？ | 主题信息生成并存储在用户设备本地。根据请求，该 API 最多向调用方返回 3 个 Topics。Google 认为，调用方在处理和存储 Topics 信息时有责任遵守当地法规。此外，所有调用方都必须证明他们没有使用 Topics 跨网站重新识别用户。如需了解更多详情，请参阅与隐私权相关的合规性常见问题解答。 |
| V2 分类 | 从 v1 转换为 v2 时，主题分类升级以及浏览器状态的影响。 | 使用之前的类目推断的主题仍然可用，并且广告技术平台最终可提取这些主题，直至其过期（4 周）。 |
| API 说明 | Topics API 的用户体验具有误导性。 | 我们已将此反馈分享给用户体验团队。 |
| API 问题 | 考虑到 Yahoo 域名的宽泛性，系统如何将其归类到主题中？ | 我们仅使用主机名将网站归类到主题中。请务必注意，被广泛分类的网站不会因此而受到影响。 |
| 主题可用性率较低 | 测试人员从 Google Ad Manager 收到的 Topics 信号较少。 | Google Ad Manager 采取了多项优化措施来扩大覆盖面，买方应该会发现覆盖率有所提升。某些预期因素可能会限制覆盖率（例如用户偏好设置、调用方的观察要求，以及可能存在某些延迟/超时）。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 区分 | 缺乏清楚说明 SSP 如何在新竞价中带来差异化优势。 | 我们听说过将 Protected Audience 和/或其他 Privacy Sandbox API 作为核心的战略计划。 总体而言，生态系统的卖方通常会将减少无处不在的跨网站标识符视为一项积极措施，这不仅在隐私保护方面，而且在商业方面。接受这一变革的大大小小的企业都很有可能发现机会。 |
| 广告呈现 | Chrome 作为呈现广告的唯一途径，会阻碍创新。Protected Audience 呈现降低了现行原生广告标准的可行性。 | 浏览器中的广告呈现方式往往是采用浏览器技术来呈现的。这一点不会改变。或许这种担忧只是因为我们未来计划要求将围栏框架与 Protected Audience 搭配使用。之所以制定这些计划，部分原因就是我们想借助 Fenced Frames 技术，在广告展示方面支持生态系统创新和差异化优势。感兴趣的开发者和公司总有时间研究一下围栏框架的发展方向，其中包括如何支持原生广告方法。 |
| 输入 | 随着许多广告技术平台开始探索 Privacy Sandbox API，Concern Protected Audience API (PA API) 的完成程度已经基本上差不多了。 | 基于我们从使用情况中汲取的经验以及来自 Chrome 内部和外部的新想法，这些 API 将会不断完善。如今已正式发布的相关性和效果衡量 API 已经很稳定，但这并不意味着开发就此停止，我们欢迎您提供更多反馈。 |
| 竞价设计 | Protected Audience 设计可将所有受众群体构建和广告选择逻辑都交给买方平台，让 SSP 无法为在其平台上投放的广告系列提供受众群体构建和广告选择逻辑。 | Protected Audience 无法知晓受众群体创建者是谁，以及谁针对受众群体出价。SSP 可以创建可供出价使用的兴趣组 (IG)。SSP 也可以提供出价逻辑，这似乎与许多 SSP 直接联系代理机构的方式一致。虽然始终还有更多应用场景可供使用，但 Protected Audience 的基础足够灵活，能够支持许多不同的受众群体创建和启用方法。这些基础的隐私特征也意味着，网站之间不会共享用户级原始数据。 |
| 竞价设计 | Protected Audience 竞价是否与生态系统供应路径优化 (SPO) 举措相悖，以减少广告主与发布商之间的中间方总数和/或给定广告机会的重复情况？ | 不会。如果买方与发布商建立直接集成，Protected Audience 中的胜出广告将最多传递两个卖方实体（例如 SSP 和发布商广告服务器），甚至可以不传递任何实体。 发布商可以自行选择通过多个中介复制同一请求。Protected Audience 不应以这种方式或两者产生影响。 Protected Audience 竞价不会泄露跨网站用户数据，而是发生在当今的服务器到服务器的实时系统之外。有人可能会说这重复了广告请求。从技术层面来说，隐私保护确实需要做出一些取舍。不过，从长远来看，生态系统有可能决定使用 Protected Audience，而不使用传统的服务器端竞价。这种选择可能会带来更加优化的供应路径。 |
| 竞价设计 | Protected Audience 会转为采用一种模型，在这种模型中，SSP 很少是在网页上进行的“最后一次”竞价，但被 API 设计强制采用这种模型。 | 我们不认同。我们见过的尝鲜者实现方案实际上就是这样：参与组件竞价的 SSP 可以胜过内容相关竞价（发生在 Protected Audience 竞价之前）的输出。完成完整的内容相关竞价后，Protected Audience 中的 SSP 组件竞价输出将作为最后考虑因素。 |
| 竞价设计 | 内容相关竞价可能只用于提供有关竞价机会的数据信号，以便为 Protected Audience 竞价提供相关信息。 | 我们预计内容相关竞价仍会出于各种原因保持相关性，例如交易、非第一方受众群体定位广告系列和大量情境情景。当没有 IG 时，或者 Protected Audience 中的出价未能达到底价或不符合广告质量规则时，此出价策略也很有用。 |
| 根据流量情况调整投放速度 | DSP 以固定的 QPS 运行。适合的 Protected Audience 竞价会降低旧版基础架构的效用。 | 据我们所知，每秒查询数方面发生了一些变化，即许多 SSP 使用跨网站 ID 这一功能来确定是否向 DSP 发送请求。无论发布商是否希望运行 Protected Audience 竞价，都是如此。 我们探索了使用许多 SSP 来调整流量情况，并找到了缓存和基于情境过滤等解决方案。随着时间的推移，我们希望开发者能够充分利用不公开汇总，进一步帮助理解 DSP 出价偏好设置并进行相应过滤。 最终，一些围绕跨网站标识符构建的旧版基础架构将无法再使用。 |
| 可用信号 | 无法清楚了解竞价时可用的所有信号，以及内容相关竞价的触发顺序会对其造成不利影响。 | 一般来说，对于出价方而言，在创建 IG 时可以通过内容相关竞价和实时键值对查找来提供信息。对于记分者，可以在配置竞价时提供信息，包括有关网页和内容相关竞价的上下文信息，以及通过对广告 renderUrl 的实时键值对查找。 |
| （在前几个季度报告） 视频呈现 |
支持使用 Protected Audience 和围栏框架呈现视频。 | 我们的回应与之前几个季度相比没有变化： “Protected Audience API 支持使用依赖于 iframe 的机制呈现视频。不过，我们尚未设计出与围栏框架兼容的解决方案，这也是我们决定将把围栏框架的违规处置推迟到 2026 年的原因之一。这意味着，如果合作伙伴现在决定实施围栏框架，则将无法为该合作伙伴提供对视频的支持。” |
| 视频呈现 | 针对 iframe 中的视频的 PA API 支持仅限于 HTML5 视频，并且不支持广泛使用的 VAST 标准。 | 目前，您可以使用 Protected Audience 中提供的 iframe 呈现机制来实现基于 VAST 的广告。Google 承认，这需要买方、卖方和发布商广告平台进行新的工程工作，因此我们将继续努力，简化 VAST 以前的运作方式。 |
| （在前几个季度报告） 顶级竞价 |
能够使用 Google 的发布商广告服务器，而无需让 Google Ad Manager 控制顶级 PA API 竞价。 | 我们的响应与之前季度相比没有变化： “Google Ad Manager 提供的响应： Google Ad Manager 针对 Protected Audience API 的方案不支持在不受顶级 Protected Audience 竞价控制的情况下支持 Google 的发布商广告服务器，原因如下： 为了在发布商广告投放市场中为我们的客户提供恰当的服务，Google 的发布商广告服务器需要保留对顶级 Protected Audience 竞价的控制权。作为发布商广告服务器，我们的职责是为发布商提供预测，使他们能够协商直销广告系列而不会超量预订，并以最佳方式安排和投放直接预订。为此，您需要运行最终竞价，比较所有符合条件的直接和间接需求。 预测和投放节奏是发布商期望广告服务器能够使用的核心功能。如果不能进行准确的预测，发布商最终可能会超量销售自己的广告资源，给商业声誉带来负面影响。投放安排也至关重要，因为无法履行与广告客户的预订合同也可能会破坏发布商与广告客户的直接关系，对发布商的业务产生重大影响。 因此，简而言之，我们不会将发布商广告服务器开展顶级 Protected Audience 竞价的活动与发布商广告服务器的其他活动区分开来。” |
| （在前几个季度报告） directFrom 卖方信号 |
directFromSellerSignals 允许 Google Ad Manager 阻止发布商查看其内容相关竞价的价格。 |
我们的响应与之前几个季度相比没有变化： "Chrome 响应： 除非卖方从自己的 iframe 调用 runAdAuction()，否则无法知道传递到 runAdAuction() 的信息来自卖方。在多卖方竞价中，不可能让所有卖方都创建调用 runAdAuction() 的框架。directFromSellerSignals 通过从从卖方源加载的子资源包加载内容解决了这个问题。这样可以确保来自卖方竞价配置传入竞价的信息的真实性和完整性不会被操纵。如果发布商想使用 Protected Audience API 来了解其技术提供商传递到 Protected Audience 竞价的任何信息，可以请求这些技术提供商提供此功能。 Google Ad Manager 提供的回应： 我们多年来一直非常关注竞价的公平性，包括我们承诺：在发布商参与竞价之前，我们不会与其他买方分享任何来自发布商的无保证广告来源的价格（包括无保证的订单项的价格），而后来我们在与法国竞争管理局的承诺中再次确认了这一点。 对于 Protected Audience 竞价，我们打算利用 directFromSellerSignals 兑现我们的承诺，在多卖方竞价完成之前，不与任何其他竞价参与者共享任何竞价参与者的出价。需要明确的一点是，内容相关竞价的价格也不会与我们自己的组成部分竞价共享，如此次更新中所述。” |
| （在前几个季度报告） K-匿名性值 |
如何确定从“K”到“k-anon”的值？何时发布？ | 我们于 2023 年 12 月发布了 K-匿名性值。3PCD 流程开始后，我们会将 k-匿名性阈值提高到最终值 50 (k=50)，并将更新周期设置为 1 小时 (p=1)。K-匿名性值 50 被评估为在效用和隐私之间实现了最佳平衡。此值足以阻止基本的机器人攻击并保持差分隐私，同时还足够低，以至于 API 对其预期用例继续有用。 |
| （在前几个季度报告） forDebuggingOnly |
在 3PCD 后， forDebuggingOnly.reportAdAuctionWin 可能会被滥用。 | 我们在此处分享了有关如何长期继续为调试用例提供支持的提案。欢迎针对该提案提供更多反馈。 |
| （在前几个季度报告） 同源政策 |
请求放宽同源政策以允许子网域。 | 我们正在审核您的请求，我们已在此讨论了这一点。 |
| （在前几个季度报告） 广告组件尺寸 |
将广告组成部分的数量从 20 个增加到 40 个。 | 我们一直在 10 月 4 日的 WICG 通话和这个 GitHub 问题中讨论了这项请求，并计划在 2024 年第 1 季度底之前解决它。 |
| （在前几个季度报告） 键值对服务器密钥有效期 |
讨论了在相应的 IG 过期后移除服务器密钥。 | 最好在 TEE 外部管理 TTL，以降低复杂性。不过，欢迎您在此处提供其他反馈。 |
| InterestGroup 触发器 | 单个 IG 在一次（组件）竞价中可以触发多个 generateBid 吗？ | 每次浏览器调用某个 IG 的 generateBid() 函数时，该 IG 都会返回出价值。例如，在多卖家竞价中，某个 IG 可能会被多次调用，每次都是在某个组成部分竞价中调用。 IG 的所有者无需执行任何操作即可启用/支持此行为。 |
| 合规性问题 | 通过用户的 Chrome 浏览器征求用户意见的范围是什么？ | 如需了解详情，请参阅与隐私权相关的合规性常见问题解答中的“Privacy Sandbox 如何在 Chrome 中实现与隐私权相关的合规性？”。 |
| 多代码竞价 | 如何适应多代码竞价？ | 我们正在评估此申请，欢迎您点击此处提供其他反馈。 |
| IP 保护适用范围 | 对 Protected Audience 功能时间表（例如，强制执行围栏框架以及移除或移除事件级报告功能）有何影响（如果在所宣布的日期之前 IP 保护尚未就绪？） | 如此处所述，我们认为 Protected Audience 时间轴应与其他隐私保护功能的发布时间表相关联。 |
| modelingSignals | 除了能够对展示广告和点击信息进行编码的 modelsSignals 之外，还请求其他新字段。 | 我们了解这样做能为效用带来好处，目前正在评估请求，欢迎点击此处提供其他反馈。 |
| IG 负值 | 能否允许普通 IG 指定否定 IG 名称？ | 目前，根据铺垫消息无法做到这一点，但我们欢迎生态系统中的其他反馈来了解这项要求。 |
| API 用量 | 在 generateBid() 级别生成汇总报告并传递 | 可以在 generateBid 内调用不公开汇总。 |
| 宏 | 通过 iframe 中的宏将 perBuyerSignals 的信号传送至第三方。 | 我们将在此处讨论此用例，欢迎您提供其他反馈。 |
| API 用量 | 如果可信评分信号提取返回错误，系统是否仍会调用 scoreAd()？ | 如果抓取调用未成功，ScoreAd() 仍应运行。 |
| API 用量 | 在 riegeli 文件中为增量/快照文件写入 metadata.slice_num。 | 我们现在正添加对 Dagger_num 的支持，以解除屏蔽。Riegeli 的采用率不及 Avro 等示例，但也不会被弃用。由于 TEE 的限制和开销更多，因此我们权衡了性能而非用户体验。我们正在考虑提供 gRPC 服务，以便基于请求创建文件。此外，我们可能还会评估其他格式（例如 Avro）对性能的影响。 |
| API 测试 | PA API 和 Measurement API 将如何为增量测试提供支持？ | Privacy Sandbox 没有办法通过基于事实的预竞价来衡量增量。您可以使用共享存储空间和不公开汇总，但事实陈述仅在竞价之后显示。 |
| API 用量 | 使用 biddingWasmHelper网址 进行每日更新是否会影响 k-匿名性阈值？ | 由于 在进行 IG 更新时不再考虑 k-匿名性，因此 biddingWasmHelper网址 可以在不影响阈值的情况下进行更新。 |
| API 用量 | 我们能否收到 PA API 错误通知？ | 我们欢迎生态系统中的用户提供反馈，告诉我们他们需要什么样的错误通知才能排查 PA API 问题。 |
| 广告尺寸 | 广告尺寸不会显示在竞价中，也无法生成报告。 | 我们正在努力解决此拉取请求的问题。 |
| API 用量 | 如果 IG 未参与此次竞价，是否会调用更新 IG 端点？ | 是的。系统会为特定所有者的所有 IG 调用 update网址，即使他们未在该特定竞价中出价也是如此。只需满足以下要求： - 所有者必须参与指定竞价（即，作为买方包含在实时出价配置中） - 指定所有者的 InterestGroup 在过去 24 小时内必须没有更新过。 |
| PA API 中的 Prebid | 测试阶段需要使用哪个版本的 Prebid.js？ | 根据我们的技术文档，版本应该不低于 8.9.0。 |
| 在 PA API 中启用第一方数据 | 他们如何运用自己的第一方数据来定义和使用 IG？ | 您可以使用“权限委托”和“排除性兴趣群体”来完成此任务。 |
| PA API 和服务器端代码植入 | 如何将 PA API 与服务器端代码植入配合使用？ | 用户浏览器上的基本代码需要将 API 调用重定向到服务器端的其他代码，这样他们也可以注册调用。 |
| Chrome 测试（模式 a/b） | 是否希望 SSP 也会在实时出价请求中传递这些标签？如果传递，应如何传递？ | 是的，前提是标签会从 SSP 传递到 DSP。建议实体访问该标签，并通过此设备扩展与合作伙伴共享未经修改的值。 |
| 数据存储和使用 | 您能否详细了解数据的存储和传输位置？ | 我们不提供法律指导，但更多是为了提供我们对于数据存储、保留和其他隐私权问题的方法/总体思维。请参阅此处的隐私权相关合规性常见问题解答，可能会对您有所帮助。 |
| API 安全 | 担心恶意客户端代码操纵 generateBid() 函数的返回值。 | 我们已在此处 讨论了该问题，并且部分反馈已被纳入到不公开汇总提案中。 |
| 自定义目标位置 | 在使用自定义目标 reportEvent 调用时，您是否碰巧知道，需求方平台（而不是针对买方或卖方）在 allowReportingOrigins 中作为 IG 的一部分预注册时是否需要由 DSP 在 reportWin 中使用 registerAdBeacon 声明相应来源？ | 不需要，您无需在 reportWin 中重新注册，可以直接在 reportEvent 中使用，如此处所述。 |
| API 限制 | 创建和更新过程中的 IG 大小。 | 更新大小已更新为 1 MB，与 IG 创建的新上限（从 50 KB）一致。 |
| K 匿名性限制 | 包含不同尺寸的广告的 K-匿名性。 | 我们于 2023 年 12 月发布了 K-匿名性值，其中规定了 K-匿名性将“2025 年之后的某个时间”开始检查广告尺寸。正如 10 月 11 日的 WICG 通话中所述，排除尺寸是跨网站跟踪向量，因此没有办法排除尺寸。 |
| API 安全 | 恶意玩家会伪造网页的“主机名”吗？ | 该 API 支持将子键设置为发布商主机名。由于浏览器正在设置密钥，因此似乎很难规避此机制。 |
| API 用量 | 不建议将 ForDebuggingOnly 函数用于生产用途。 | 我们即将向生态系统重申，forDebuggingOnly 函数仅适合在 3PCD 之后进行问题排查。 |
| 需要更多调试工具 | ForDebuggingOnly 不足以了解在 scoreAd() 之前可能发生的问题。 | 我们正在收集有关这一差距的更多反馈，欢迎在此处提供其他意见。 |
| 永久选择退出兴趣小组 | 请求允许用户永久选择拒绝创建特殊 IG。 | 我们的策略一直是不让用户在 IG 层面选择停用，因为用户的真实情况是无法理解的。 |
| 改进文档 | 在规范和铺垫消息中，对 renderUrls 参数使用相同的大小写。 | 感谢您提供反馈，并会跟进更新文档。 |
| Protected Audience 交易支持 | 请求获取 Protected Audience 交易支持方面的其他选项。 | Chrome 团队目前正在评估 3PCD 可以采取哪些措施来支持此功能。 |
| 宏 | 需要支持宏，以确保 IG 的大小小于最大 IG 大小。 | 近期对铺垫消息的更新部分解决了这项要求。 |
| 事件级 ReportLoss API | 请求事件级 ReportLoss API。 | 虽然事件级损失报告会带来严重的隐私风险，但我们相信可以通过对 Private Aggregation API 进行适当修改来实现此请求的基本目标。欢迎点击此处提供其他反馈。 |
| API 用量 | 如果没有出价得分大于 0，forDebuggingOnly 方法会如何行为？ | 如果得分 <= 0，则自动失败。因此，系统将调用 reportAdAuctionloss 。 |
| 标准化 | PA API generateBid() 函数的输入/输出值用户之间未对齐。 | 我们建议所有提交此问题（或类似问题）的合作伙伴向 IAB Tech Lab 提出。该团队专门负责制定 Protected Audience 等 API 的业界标准。 |
| API 安全 | Google 可以查看来自 Instagram 的哪些数据？ | K-匿名性依靠强大的隐私保护措施来避免将用户敏感数据泄露给任何一方（包括 Google）。Google 还在开发该层的第三方实现 (Fastly)，以最大限度地降低这种风险。 |
| Chrome 测试（模式 a/b） | 是否可以从测试中排除“k-anon”受限用户？ | 如此处所述，我们会在报告中公开 k-匿名性状态。 |
| 品牌保障 | 支持根据被屏蔽的网站或关键字列表不投放广告的品牌保障用例。 | 此类品牌保障用例应该可以通过 PA API 实现。 如果广告系列要排除某一组网域，可以将该网域屏蔽名单存储在 IG 中，如果列出每个网域屏蔽名单会占用过多空间，则可以使用“布鲁姆”过滤器。或者，他们可以使用 UDF 从其键值服务器返回允许或拒绝决策，UDF 根据标识广告系列的键和包含在键值请求中的域名的组合来查询答案。 Protected Audience API 还允许 SSP 和 DSP 向竞价传递有关网页上下文的任何信息。例如，这可能包括网页上的敏感主题或关键字列表。DSP 的出价逻辑可将这些信息与所存储的任何有关广告不应出现位置的信息进行比较，从而在适当的时候选择不出价。 我们欢迎 YouTube 生态系统针对他们认为不可行的特定应用场景提供反馈。 |
| 权限委托 | 权限委托的工作原理是什么？ | 我们在此处分享了有关权限委托的文档。 |
| 批量请求 | 对某些 PA API 网址使用 POST 请求，以便支持批量请求。 | 我们欢迎该方案，并欢迎您在此处提供其他反馈。 |
| 改进 API | 可能不应使用的字段（例如 X-fledge-bidding-signals-format-version）。 | 我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| 改进 API | 请求将 GDPR 意见征求消息转给第三方广告投放和衡量服务供应商。 | 如此处所述，此功能可通过已弃用的 ReplaceInURN 宏替换 API 获得支持。 |
| 动态广告素材优化 | Protected Audience 如何支持动态广告素材优化？ | 我们将在此处讨论此用例并分享潜在的解决方案。 |
| 改进 API | 关于能够获取与赢得竞价的 IG 对应的 IG 上下文主要 IG 名称的第三方广告投放网址。 | 此类请求可能会增加用户的跟踪风险。我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| API 安全 | 担心“IG blob”的大小会泄露所选 IG 的相关信息。 | 正如 Chrome B&A API 说明文档中的“隐私权注意事项”部分所述，blob 的大小并不依赖于 navigator.getInterestGroupAdAuctionData() 的任何输入。它只是打包设备上的所有 IG。这样可以确保 blob 大小在页面上相对一致，并限制泄露跨网站信息的能力。正是出于这个原因，我们才设计了这款应用。 |
| Chrome 测试（模式 a/b） | 关于设置 Cookie 和 Chrome 协助测试，其他 SSP 对缺少首次加载的立场是怎样的？ | 我们还没有听到任何重大疑虑（尽管其他人也对此表示了解），但如果这是一个重大问题，我们非常欢迎生态系统中的用户提供反馈。 |
| A/B Testing 支持 | 请求支持 PA API A/B 测试。 | 我们在 11 月的 WICG 会议上讨论了这项请求，欢迎点击此处提供其他反馈。 |
| 广告尺寸 | Protected Audience 竞价的尺寸由谁选择？ | 此常见问题解答回答了这个问题。 |
| 改进 API | 请求将键值对服务配置为接受 /bidding-signals/v1/getvalues 路径。 | 我们在此拉取请求中添加了支持路径前缀。 |
| API 用量 | 如果发布商应该以广告客户为基础，那么发布商如何使用其代码创建 IG 代码，以便广告客户对其出价？ | 答案必须来自某个广告技术合作伙伴，即希望参与 Protected Audience 竞价并为这些受众群体构建来自外部来源的 DSP 或 SSP 提供答案。我们在此 GitHub 问题中进一步讨论了这一点。 |
| 改进 API | 请求将否定 IG 关联到“正面兴趣组”中的广告。 | 我们正在考虑此要求，并在此处分享了有关如何支持这项要求的潜在方案。 |
| 分片数 | 请求有关在元数据中传递“hard_num 支持”的支持。 | 根据此反馈，我们添加了对 Dagger_num 的支持。 |
| API 用量 | 请求估算 K/V 服务器中密钥开销。 | 我们已分享自己的想法，欢迎您在此处提供其他反馈。 |
| K-匿名性 | 请求阐明和增强 K-匿名性计数器粒度。 | 我们在此处提供了有关 K-匿名性计数器粒度的说明。 |
| 调试 | 在最近提议对 forDebuggingOnly 进行更改后，请求改进 PA API 调试功能。 | 我们正在此处讨论该请求，欢迎点击此处提供其他反馈。 |
| 广告尺寸 | 请求广告位尺寸，作为额外的 BTS 信号。 | 我们已就这项请求分享了一项提案，欢迎点击此处提供其他反馈。 |
| API 安全 | 能否根据来源限制“runAdAuction()”的使用？ | 我们在此处分享了详细回复。 |
| IG 生命周期 | 申请将 IG 的生命周期从 30 天延长至 90 天。 | 我们正在考虑此申请，欢迎点击此处提供其他反馈。 |
| API 用量 | 能否在标头出价和发布商的广告服务器调用的同时进行 Protected Audience 竞价？ | 我们正在讨论此请求，欢迎点击此处提供其他反馈。 |
| 调试 | 请求更好地支持与开发者工具通信的 Chrome PA API 调试扩展程序。 | 我们支持提供更多调试工具，欢迎您在此处提供其他建议。 |
| API 用量 | 如果组件卖家的出价均未进入畅销排行榜，则不会触发损失通知。 | 我们已在此处解释背后的原因。 |
| 改进 API | 请求在 Protected Audience 出价 Worklet 中支持 TextEncoder。 | 我们正在考虑此申请，欢迎您点击此处提供其他反馈。 |
| API 用量 | 网络调用和客户端中的运行逻辑可能会阻塞主线程并导致 JS 执行挑战，进而影响搜索引擎优化 (SEO)。 | 我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| API 用量 | DSP 是否可以使用目前的服务器端出价漏斗来评估和发送候选广告（作为 perBuyerSignal 的一部分用于设备端竞价？） | 我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| 扩展出价机会数据 | 请求将浏览器传递的出价机会数据扩展到 SSP，并提供浏览器中有效 IG 的唯一来源网域列表。 | 我们正在讨论此请求，欢迎点击此处提供其他反馈。 |
| 实时出价 | 在 ORTB 中请求为 biddingConfig 和 generateBid 响应自适应两个新钩子。 | 我们正在审核此问题，欢迎点击此处提供其他反馈。 |
| 上一次获胜 | 请求 IG 定义 prevWinsTransformer，它接受之前 IG 的胜利并输出可序列化的内容。 | 我们正在审核此问题，欢迎点击此处提供其他反馈。 |
| 内容类型 | 内容类型演变策略，例如从 JSON 到 CBOR 之类的内容。 | 我们正在审核此问题，欢迎点击此处提供其他反馈。 |
| Protected Audience API 中的 Prebid | 请求使用 Prebid 的示例发布商页面，以便为 Protected Audience 竞价运行端到端流程。 | 我们正在考虑此申请，欢迎 YouTube 生态系统提供其他反馈，说明为什么应优先考虑这项要求。我们还发现，生态系统参与者提供了示例发布商页面，供生态系统中的其他人进行演示。 |
受保护的竞价服务
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 可信执行环境 (TEE) | 在公有云中运行可信执行环境的成本要高于本地广告技术数据中心？ | 我们目前的 TEE 安全模型受益于公有云实现的做法。特别是，目前基于硬件的 TEE 无法防范所有物理攻击。我们目前支持的公有云提供商 AWS 和 GCP 针对物理访问风险（包括员工）设计和实施了缓解措施。如需进一步了解本地支持，请参阅下文 。 广告技术平台向我们提到，运行云服务比本地广告技术数据中心成本更高。虽然我们无法评估这些陈述，但欢迎您就费用提供进一步反馈，并继续评估扩大 TEE 支持的范围。 |
| （在前几个季度报告） 本地 TEE |
要想成为 TEE 提供商，需要满足哪些要求？ | 我们的应对措施与前几季度类似： “尽管我们在继续探索支持其他公有云解决方案以外的方案，包括从安全角度考虑哪些部署可以接受，但我们目前没有支持本地 TEE 的计划。在这一阶段，考虑到 Privacy Sandbox 的安全性要求以及本地部署带来的重大挑战，我们认为继续扩展和改进基于云的部署对生态系统最有利。不过，我们欢迎您就隐私保护和安全限制提供额外反馈，说明为何此类要求是必要且可行的。” |
| 键值对服务器的限制 | 每个服务器每次竞价的密钥限制 | 我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| K 匿名性限制 | 确认未来不会针对 K/V 密钥强制执行 K-匿名性。 | 目前，我们没有对 K/V 服务器请求的密钥强制执行 k-anon 的计划，因为我们的目标是将来让 K/V 服务器迁移到 TEE。 |
| 建筑物 K/V 服务 | Google 是否提供适用于 K/V 服务的预构建工件？ | 我们目前还没有为 Protected Audience 键值对服务器提供任何预构建工件，但如果生态系统对相关需求有强烈需求，我们可能会考虑提供这些工件。 |
| B&A 中的 EgId 支持 | 请求在出价和竞价代码中支持字段 experimentGroupId，以及 BuyerFrontEnd 向 KeyValue 服务发出请求 | B&A 目前不支持 experimentGroupId，但打算在 Beta 2（目前预定于 2024 年 2 月）之前推出此功能。我们在此处分享了更多信息。 |
| API 用量 | HTTP 中的请求合并功能有助于防范路径攻击者，但 TEE 运营商会了解数据大小。 | 我们正在讨论此请求，欢迎点击此处提供其他反馈。 |
| 改进文档 | 该规范不清楚 k-v 服务器的处理方式。 | 我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| API 用量 | “Ad-Auction-Result”和 adAuctionHeaders 的用途是什么？ | 我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| 改进文档 | 不确定 v2 设计是否已传播到 FLEDGE.md。 | FLEDGE.md 介绍了 Chrome 如何将请求发送到 BYOS-KV。v2 协议设计仅限于 TEE-KV，目前不受 Chrome 支持。 |
衡量数字广告
Attribution Reporting（及其他 API）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 跨环境衡量 | 在过渡阶段，从移动版 Chrome 中移除 3PC，但 Privacy Sandbox for Android 尚不可用，Chrome 打算如何支持此过渡阶段的跨环境衡量？ | 在 Android 方面，我们正努力扩大 PSB/ARA 的覆盖范围 - Attribution Reporting API (ARA) 适用于 Android 13 和 14。我们计划于今年晚些时候开始扩展到 Android 11 和 12，不过可能会发生变化。我们无法扩展到 Android 10 或更低版本，但我们预计仍在使用 Android 10 或更低版本的 Android 设备比例在 3PCD 时会比较低，并且会随用户升级而自然降低。 我们欢迎 YouTube 生态系统就此请求提供更多反馈。 |
| 过滤 | 从广告素材扫描中滤除“转化”。 | 我们联系了该利益相关方，以便更好地了解他们的请求，并欢迎生态系统就此问题提供更多反馈。 |
| 第三方广告服务器 | PA API 和 ARA 如何与第三方广告服务器代码配合使用？ | 与目前在展示代码和点击代码中搭配使用像素的操作方式类似，广告服务器可以自行设置 ARA 的来源和触发器注册（包括通过 Protected Audience 竞价），也可以设置重定向以传递和接受 ARA 的来源和触发器注册。 |
| DCM | DCM 和其他第三方广告服务器支持 Attributionsrc。 | 这是一个与 DCM 相关的问题，DCM 团队已在此 GitHub 问题中得到解决。 |
| 分层汇总键 | 是否有必要将所有贡献预算拆分到所有这些分层键中？ | 我们已讨论并提供了与此利益相关方的答案。使用分层键结构时，广告技术平台必须考虑贡献预算将在针对相应展示输出的所有键之间共享。 |
| 使用不同的子网域 | 让归因报告能够与在不同子网域但同一 eTLD+1 上注册的来源和触发器配合使用？ | 我们已与利益相关方讨论了此问题，并提出了以下解决方案。他们可以更改其网址设置，在来源和触发器上具有相同的报告来源，或者从当前网址重定向到同一网址，然后再执行注册。如果建议的解决方案不适用于这些生态系统的用例，我们愿意接受其他生态系统反馈。 |
| （前几个季度也进行了报告） 正式版支持 |
使用 ARA 的合作伙伴可以使用哪些级别的服务？ | 我们对前几个季度的回应没有变化： “Google 提供了多种渠道，让广告技术平台可以报告技术问题，并通过任何必要的上报来解决此类问题。此外，Chrome 团队希望进一步构建和扩展相关流程，以解决影响生态系统健康的技术问题和上报情况。Chrome 会全力确保资源投入支持这项工作。 如需详细了解用于提供反馈和上报的公共论坛和非公开论坛，请参阅我们的开发者帖子。 |
| （也曾在前几个季度报告） 时间轴 |
在 CMA 定量测试开始时，Google 是否会准备好“第 2 阶段完全灵活事件级”？ | 第 2 阶段完全灵活事件级预计将于 2024 年第 1 季度在 Chrome 中推出。您可以点击此处跟踪状态。 |
| （也曾在前几个季度报告） 转化漏斗 |
报告转化中使用的多个网域。 | 由于添加了多个目的地，此用例是可能的。欢迎提供更多反馈。 |
| 报告测试标签 | 测试人员能否通过报告功能报告用户（Chrome 浏览器）属于哪个群组（模式 A/B）？ | 我们正致力于发布一份测试指南，以了解如何在 ARA 中捕获 Chrome 测试标签。 |
| 文档 | 关于 Attribution-Reporting-Register-Source 的文档指出，有效期将四舍五入为最接近的天数，如何四舍五入？ | 四舍五入为最接近的天数，意味着 1.5 天将四舍五入为 2 天。 |
| 使用不同的子网域 | 请求在作为来源和触发器注册的其他子网域中接收 Attribution Reporting API 报告。 | 不可能。可以应用 HTTP 重定向，但无需为此进行任何设置。我们欢迎 YouTube 生态系统提供进一步反馈，说明这项请求为何有用。 |
| 事件级报告延迟 | 归因和报告期为 7 天，但由于事件级报告延迟，所有报告可能需要 8 天以上才能生成。 | 我们深知大家的反馈，并欢迎整个生态系统提供更多反馈，指出这种事件级报告的延迟是否问题，尤其是在从固定事件报告期改为灵活的事件报告期时。 |
| 转化触发器 | 在第一个 event_report_window (1h) 与过期时间（1 天）结束之间发生的转化触发器不会生成报告。 | 我们推出了灵活的事件级配置，将其从固定报告期移至灵活的事件报告期。 |
| 噪音 | 事件级报告是否如 GitHub 说明文档中所述，存在噪声虚假转化？ | 是的，噪声应用于事件级报告，代表所有可能的输出状态（包括不同的 trigger_data），在实际发生触发器时根本不报告任何内容，或者可能会报告该事件的多个虚假报告。噪声百分比是开源的，可以通过灵活的事件级配置进行灵活设置。 |
| 过滤 | 将过滤与 Attribution Reporting API 搭配使用仍会消耗贡献预算，即使它不会记录汇总键也是如此。 | 这是正常的，因为 aggregatable_trigger_data 仅支持对触发器键部分本身进行过滤，而不支持对值 / 键进行过滤。顶级过滤条件可以支持对键本身进行过滤，但这由事件和汇总共用，因此不适用于此处。如果有必要根据密钥进行过滤，欢迎点击此处，从生态系统中获得其他反馈。 |
| 存储空间限额 | 请求引入存储空间限制，同时考虑报告来源。 | 此限制由 1024 个增加到 4096 个，将于 M120 生效。欢迎点击此处，从生态系统中提供更多反馈。 |
| 直接归因 | 标准归因报告流程不涵盖用户直接访问广告客户而不与发布商接触的情况，如何获取相关指标？ | ARA 仅用于恢复跨网站信息（即跨发布商/广告客户网站合并信息）。如果不需要跨网站信息，ARA 将不会为您提供帮助。我们正在讨论此问题，欢迎点击此处提供其他反馈。 |
| 报告时间 | 从时间服务器获取 schedule_report_time 时间，而不是使用本地机器时间。 | 我们目前还没有关于使用时间服务器的计划，也没有收到广告技术平台对这项服务的需求。我们很期待收到相关生态系统的更多反馈，以了解该功能是否实用。 |
汇总服务
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| （在前几个季度也进行了报告） 本地解决方案 |
汇总服务是否可以部署在本地数据中心内？ | 虽然我们正在探索在基于云的解决方案之外可能支持其他方案，但由于本地安全限制，需要对 Privacy Sandbox 进行耗时的评估，因此目前无法支持本地 TEE。考虑到 Privacy Sandbox 的安全性要求以及本地部署带来的重大挑战，我们认为继续扩展和改进基于云的部署（例如，在 AWS 之外支持 GCP）对整个生态系统最有利。不过，我们欢迎您在此处提供进一步的反馈，了解为什么需要此类要求。 |
| 飞地 | 如果 Enclave 未启动或突然收到错误，Aggregation Service API 会如何处理错误？ | 如果隔离在启动时失败，我们将重试；如果实例被视为运行状况不佳，则会通过自动扩缩来启动新实例。广告技术平台还可以使用日志调查故障。 如需调试 AWS 上的 Enclave 故障，广告技术平台可以登录 AWS 控制台管理器来检查其 EC2 实例的状态。广告技术平台还可以登录 Nitro Enclave 主机实例，并使用 nitro-cli 工具检查 Enclave 状态。如果存在任何错误/失败，他们可以使用 AWS 命令行界面查看日志并展开进一步调查。 如需调试 GCP 上的 Enclave 故障，广告技术平台可以通过 Cloud 控制台检查其实例的状态。他们还可以使用 list-errors-command 检查错误。 |
| 使用不同的子网域 | 请求注册多个（子）网域，以便在开发环境和生产环境中使用汇总服务的多个实例。 | 网站注册功能已推出，因此广告技术平台可以在一个 AWS 帐号或 GCP 项目中注册同一网站的多个子网域。他们还可以在多个 AWS 帐号或 GCP 项目中注册同一域名。我们欢迎生态系统中的各方人士提供反馈意见。 |
| 隐私预算 | 如何更好地调试隐私权预算耗尽相关问题？ | 目前，我们正在寻找解决方案，以提供有关用尽预算的更多详细信息，并改进我们的文档，以概述广告技术平台可用于最大程度减少此类错误的策略。一旦有提案，我们将更新汇总服务 GitHub 页面。 |
| 艾普西隆值 | 请求增加 epsilon 值。 | 汇总服务的 epsilon 值将保持在 64 这一范围内，以方便在 3PCD 期间针对不同参数进行实验和提供反馈。在 epsilon 范围值更新之前，我们会提前向生态系统发出通知。 |
| 二进制文件 | 针对汇总服务版本发布一组更完整的二进制文件。 | 我们正在审核此申请，欢迎其他反馈。 |
| API 用量 | 根据 Coordinator 服务条款与协调者共享数据。 | 我们正在寻求关于此问题的说明，欢迎其他反馈。 |
Private Aggregation API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 调试 | 启用模式 B 测试期间用于调试的其他选项。 | 正如此 GitHub 问题中所分享的，我们未来将允许在模式 B 下使用调试模式。从 1 月 31 日起，此资格条件将在 M121 Beta 版中发生变化，即模式 B 流量的 50%。在过渡到稳定版之前，我们会发出通知。 |
限制隐秘跟踪
用户代理缩减/用户代理客户端提示
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| ChromeOS | 针对 Chrome 操作系统的位数支持用户代理客户端提示。 | 我们已在此处回复了这项要求。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 滥用行为 | Google 或许能够通过 IP 保护查看用户的浏览数据。 | IP 保护通过两个代理（一个由 Google 运行，一个由另一家公司运行）传送流量。这样可以确保 Google 看不到浏览数据。Chrome 和代理之间的所有流量都经过加密处理，因此 Google 代理不知道用户正在浏览哪些网站。此外，系统使用盲化身份验证令牌，以尽量减少对代理上用户标识符的访问。Google 代理只能看到位于特定 IP 的未知客户端正在使用代理系统。没有关于访问过的网站或已加载的广告的信息。 |
| 无头模式支持 | 如何管理使用插件和无头模式的聊天机器人？ | 减少 IP 保护功能滥用是该团队工作的重点。我们仔细考虑了这些场景（以及许多其他潜在威胁），并正在寻找有助于降低滥用或欺诈成功概率的方案。虽然目前我们无法提供更多详细信息，但我们希望在不久的将来提供这些详细信息，并希望能继续讨论。 |
| 现有代理 | IP 保护如何与 Chrome 上的现有代理设置配合使用？ | 现有的代理配置仍将受支持。用户将能够像以前一样配置自己的自定义代理。 |
| 举报滥用行为 | 滥用行为举报是如何处理的？ | 我们近期会分享更多详细信息，但我们计划为组织和用户建立一种机制来分享报告和滥用证据。 |
| 法规 | IP 保护如何遵守当地法律法规？ | Google 会全力遵守当地法律法规，因此我们不允许用户规避此类国家/地区级别的屏蔽。此功能不可规避。 |
| 限制功能 | IP 保护是否会阻止我们的网络响应？ | 我们致力于在防止系统根据用户的 IP 地址在网络上跟踪用户的同时，最大限度地减少对服务器正常操作的干扰（包括使用 IP 地址进行防滥用）之间的平衡。虽然目前我们无法提供更多详细信息，但我们希望在不久的将来提供这些详细信息，并希望能继续讨论。 |
| 时间表 | 如果这项变更在 2024 年底之前开始实施，几乎不可能为此做好准备。 | Chrome 最初会将 IP 保护作为一项自选设置推出，供特定地区的用户选择使用。我们了解，这可能会给一些公司使用 IP 地址的方式带来重大改变，并力求在生态系统调整时尽可能减少中断。IP 保护最早将于 2025 年转换为默认保护功能。 |
| API 用量 | 用户首次打开 Chrome 时能否选择开启 IP 保护？ | 我们计划让用户选择是否要使用 IP 保护。向用户提供此选项的机制仍在开发中。 |
| API 用量 | 系统会记录多少数据？这些数据会保留多长时间？ | 我们将来会分享更多详细信息，但我们计划记录的数据量极少。 |
| 负面反馈 | 如果用户喜欢使用 VPN，则可以使用 VPN。无需 PS API。 | IP 保护的目标是防止将 IP 地址用于跨网站跟踪，而不是作为 VPN 服务。 |
| API 安全 | 如何防止第一方通过标头中的参数访问 IP 地址和转发信息？ | 我们一开始重点关注第三方，因为我们认为其影响最大。我们将继续监控整个生态系统，确定是否需要改进我们的方法以防止规模化规避。 |
| API 用量 | 如果对 API 使用情况的理解正确无误，则需要确认。 | IP 保护使用基于列表的方法来识别通过代理的第三方流量。对于名单中列示的可在第一方环境中访问的源站，系统将不会通过此服务代理这些源站。 例如，如果某分析公司在网域列表中，并且用户直接前往该网站，该网站仍能观测到用户的 IP 地址，而非代理的 IP 地址。但是，如果列表中的该网域在第三方环境中发出网络请求，该连接将被代理，并且网站将无法显示用户的原始 IP 地址。 我们的最终目标是阻止跨网站跟踪网络上的用户。我们正在研究一些细节，随后再详细说明我们计划在一开始主要侧重于哪些第三方网域。 |
| VPN | 担心 Google 的建议可能会对其他 VPN 提供商不利。 | IP 保护的目标是防止将 IP 地址用于跨网站跟踪，而不是作为 VPN 服务。 |
| 时间表 | IP 保护时间安排是怎样的？ | IP 保护最初会选择启用。这有助于确保用户能够控制隐私权决定，并且 Google 能够以较低的频率监控用户的行为。IP 保护将分阶段推出，并最早于 2025 年开始转换为默认功能。与所有隐私保护提案一样，我们希望确保不断学习和了解，同时了解可能还需要考虑地区性因素。我们采用的是基于列表的方法，只有列表中位于第三方环境中的网域会受到影响。我们意识到这些提案可能会对合法用例造成不必要的中断，因此我们只专注于被视为跟踪用户的脚本和网域。 |
| 限制功能 | 无法再在 WHOIS 中查询用户的 IP 地址。 | 我们的立场是，IP 地址是一个稳定的标识符，其使用可能会给用户隐私带来影响，包括使用与其关联的元数据（例如 ASN）。通过 IP 保护，我们力求在隐私权与为用户提供实用的网络体验（例如我们的 IP 地理定位方法）之间取得适当的平衡。如果这些元数据不足以满足您的使用需求，我们可以进一步讨论。 |
| HTTP 引荐来源网址 | 系统会保留原始 HTTP 引荐来源网址吗？ | 我们没有计划在 IP 保护过程中更改引荐来源网址标头（如此处所述）。 |
| 开源 | IP 保护源代码会是开源代码吗？ | 此处的大部分软件在 Chromium 和 Envoy 代理项目中都是开源软件，但有些组件是闭源的，如此处所述。 |
减少跳出跟踪
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 删除存储空间 | 跳出跟踪缓解措施 (BTM) 是否会删除共享存储空间和归因报告存储空间？ | 我们不打算让 BTM 删除 Privacy Sandbox API 存储空间（ARA、PA API、共享存储空间、不公开汇总、Topics）。BTM 应仅删除在第三方环境中访问时存在隐私风险的存储类型。正在修复 bug。 |
| API 用量 | BTM 将启用哪个 Chrome 版本？10 秒后的重定向/跳出跟踪是否会被视为 BTM 的跳出跟踪？ | 在 M116 中，BTM 向所有阻止了 3PC 的用户推广。目前，10 秒后的重定向不会被视为跳出。 |
| “登录”用例 | 在多个网域之间自动同步/维护登录状态，而不会因类似跟踪的行为而受到惩罚？ | 我们将在此处讨论此请求，欢迎生态系统提供其他反馈。 |
| 用户体验历程 | 目前，BTM 导致用户转化历程非常复杂。 | 我们正在此处讨论该问题，并就此分享我们的看法。 |
| Storage Access API | Chromium 中的 BTM 将遵循 Storage Access API (SAA) 的 3PC 授权。 | 我们已在 TPAC 2023 大会上与生态系统参与者讨论了此问题，欢迎点击此处提供其他反馈。 |
| 对广告报告的影响 | 反弹跟踪缓解措施可能导致生态系统中规模较小的公司依赖其他 Privacy Sandbox API（如 ARA）来执行广告用例。 | 跳出跟踪缓解措施旨在防止规避 3PCD。ARA 是企业将在 3PCD 之后提供的诸多替代效果衡量解决方案之一，但企业无需使用它。 |
隐私预算
本季度未提供任何反馈。
强化跨网站隐私边界
Related Website Set（以前称为 First-Party Set）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| （在前几个季度也会报告） Related Website Set (RWS) 网域限制 |
申请增加关联网域的数量。 | 目前，我们预计不会提高数值限制。该限制是基于用户隐私方面的考虑、W3C 生态系统利益相关方的反馈以及对其他浏览器的类似实现的考虑。如需了解更多信息，请参阅我们的博文（1、 2）。 我们建议检查需要超出数值限制的跨网站 Cookie 访问权限的用例，并考虑利用我们针对身份用例、经过身份验证的嵌入和广告用例提供的指南。 |
| Cookie 的使用范围 | 担心 RWS 中的所有网域都被授予读取和写入所有网域的所有 Cookie 的权限。 | RWS 中的成员资格不会导致成员能够访问彼此的 Cookie。而是允许成员在嵌入相同 RWS 的其他网站上时（在调用 Storage Access API 之后）访问自己的 Cookie。 |
| （前几个季度也会报告） RWS + CHIPS 集成 |
请求进行 RWS + CHIPS 集成，以便为 A/B 测试等用例提供支持 | 我们会继续在 此处收集此功能的用例和请求。目前，我们正在权衡对此功能的需求与跨浏览器互操作性风险。 |
| API 用量 | 如果用户从本地的 Chrome 设置中手动移除网站，会怎么样？ | 目前，我们还没有相应的方法供用户手动从组中删除网站。用户可改为使用“阻止第三方 Cookie”下方的切换开关来关闭“相关网站”功能；也可使用新的“跟踪保护”设置面板上的“阻止所有第三方 Cookie”开关。 |
| 跨域通信 | RWS 是否允许跨网域通信？ | 我们目前正在开展一项源试用，通过 Storage Access API 扩展对某些类型的未分区存储（包括 localStorage 和广播通道）的访问，从而实现这种通信。此功能适用于所有受支持的 Storage Access API 配置、同一 RWS 系统，以及 非 RWS 站点。这篇 博文提供了更多信息。 |
| requestStorageAccessFor | document.requestStorageAccessFor(origin) 是否可以返回使用源跨网站 Cookie 进行解析的 promise？ | 不可能。由于调用是从顶级源（不同于作为参数传入的源）进行的，因此这样做会违反同源政策。 |
Fenced Frames API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| （前几个季度也有报告） 原生广告 |
为原生广告提供围栏框架支持。 | 我们之前曾表示，未来必须使用一些 Privacy Sandbox 技术，以进一步加强隐私保护。例如，对于 Protected Audience，我们将要求您在 2026 年之前使用围栏框架进行广告呈现，并停止使用事件级报告。我们已为这些未来要求提供了“不早于”日期，因此业界对 API 的预期演变十分清晰。这段额外的时间让我们能够继续与业界合作，针对更广泛的关键用例设计和实现支持。例如，我们将提前改进 Fenced Frame，从而提前于 2026 年以后的要求，继续使用 Protected Audience API 来继续支持视频广告和原生广告。根据我们的承诺，我们将就此类变更向 CMA 征求意见，并在实施这些“不早于”要求之前，继续听取生态系统的反馈。 |
| 各平台的大小差异 | 报告称“围栏框架”中显示的内容大小在桌面设备和智能手机上看起来有所不同。 | 我们正在调查此问题，欢迎点击此处提供其他反馈。 |
| 呈现 adComponent | 提供关于如何在围栏框架中呈现 adComponents 的示例代码？ | 我们将提供相关文档，说明如何在围栏框架内使用 navigator.adAuctionComponents(numComponents) 来展示由多个部分组成的广告。 |
| 改进 API | 向 FencedFrame 提供更多信号（例如提升品牌保障）。 | 我们欢迎该方案，并欢迎您在此处提供其他反馈。 |
共享存储空间 API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 防滥用 / 防欺诈用例 | 可能会使用共享存储空间检测欺诈或异常情况。 | 我们在此处讨论了这种可能性，欢迎您提供其他反馈。 |
| 频次上限 | 在 PA API 之外提供跨网站频次上限的方法。 | 我们非常感激大家的反馈，认为 PA API 之外的跨网站频次上限非常有用。目前，Privacy Sandbox 仍然侧重于目前适用于 3PCD 的一组 API。不过，我们欢迎生态系统中的用户就此用例提供其他反馈，请点击此处。 |
条状标签
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 弹出式窗口/重定向 | CHIP 如何为涉及弹出式窗口和重定向的嵌入式身份验证用例提供支持？ | 我们最近分享了一些指南，介绍了如何查看逐步淘汰第三方 Cookie 对您的登录工作流程有何影响。欢迎您点击此处提供其他反馈。 |
| 分区限制 | 将每个站点每个分区的总体限制减少到 1 KiB。 | 我们正在考虑此申请，欢迎您点击此处提供其他反馈。随着我们持续推出 3PCD，以及开发者采用芯片并提供反馈，我们将继续密切关注反馈。 |
| Cookie 迁移 | 建议迁移 Web 应用以按分区发出 Cookie 的流程，该流程不会破坏正在进行的 Cookie/会话？ | 我们在 此处的回复中提出了一种可能的迁移方案；但开发者能够提出一种更适合其配置的 替代解决方案。 |
| API 用量 | 如果用户未选择启用广告隐私权 API 设置，系统是否会停用对分区存储的访问权限？ | 即使用户未选择启用广告隐私权 API 设置，也会启用分区存储和分区 Cookie (CHIP)，因为这些设置不支持任何跨网站信息传输。一般来说，信息跨网站传输会受到限制、检查或用户选择接受；但这些目前不适用于 CHIPS。 |
| API 用量 | 为什么最终阻止未分区的 Cookie，而不是浏览器只是“静默”地对这些 Cookie 进行分区？ | 这是不可能的，短期内无法实现，具体可参阅此处的说明。 |
FedCM
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| API 用量 | 无法在开发环境内在 eTLD+1 上提供“well-known file”。 | 我们更新了 Chrome Canary 版，以跳过提取已知问题（如此处所述）。 |
| API 用量 | 对于请求第三方登录权限或使用 FedCM，是否规定了任何特定的用户互动要求？ | 如此处所述，没有特定的用户互动要求。 |
| API 安全 | 是否有计划使客户端启动 FedCM，但实际上将令牌从 IdP 传输到 RP 的后端系统？ | 我们正在讨论，欢迎点击此处提供其他反馈。 |
| 选择启用 | 允许 IDP 选择接收 RP 的客户端 ID，以便用户可以决定是否信任该 IDP。 | 我们正在讨论此请求，欢迎点击此处提供其他反馈。 |
| API 用量 | 请求获取有关 FedCM 的更多文档。 | 我们非常重视这些反馈，并会随着我们继续开发此 API 继续完善文档。 |
打击垃圾内容和欺诈行为
Private State Token API（和其他 API）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 文档 | 请求提供有关私密状态令牌的详细开发者指南，以帮助进行测试。 | 我们在 2023 年第 4 季度发布了有关私密状态令牌的开发者指南。 |
| 年龄/性别验证 | 在 3PCD 后，很难对受众群体进行“年龄和性别”验证。 | 私密状态令牌目前不适用于年龄和性别验证。我们希望更好地了解用例以及目前是如何完成的，并欢迎您提供其他反馈。 |