2024 年第 1 季度的季度报告，总结了生态系统收到的关于 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 响应。
首字母缩略词词汇表
- ARA
- Attribution Reporting API
- CHIPS
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- Federated Credential Management
- FPS
- First Party Set
- IAB
- 美国互动广告局
- IdP
- 身份提供方
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- 源试用
- PAT API
- Protected Audience API（以前称为 FLEDGE）
- PatCG
- Private Advertising Technology Community Group
- RP
- 依赖方
- RWS
- Related Website Set（以前称为 First-Party Set）
- 供应方平台 (SSP)
- 供应方平台
- TEE
- 可信执行环境
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- 开发中
- 自愿 IP 盲目
一般反馈，不涉及具体 API 或技术
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 治理 | 有意向就 Privacy Sandbox 治理方面的任何更新在公开评论期结束。 | 如果 Privacy Sandbox 有任何重大进展（包括 Privacy Sandbox 的未来治理措施），我们欢迎合理的利益相关方反馈。 |
| 测试 | 除了当前的 1% Chrome 协助测试以外，还针对 3PCD 增加了额外的测试阶段。 | 自 1 月初以来，我们不打算在当前 1% 的 Chrome 流量之外再提供 Chrome 协助测试。 |
| 网站到应用 | 在网站和应用实现完全互操作之前，移动设备上的 3PCD 不应发生。 | 我们认为，支持应用与网站的互操作性是需要的。我们已经推出了跨应用和跨网站归因衡量功能，并且正在探索网站到应用的定位解决方案。不过，我们不打算延迟在移动网站上使用 3PCD。我们没有在 3PCD 结束时实现 100% 覆盖率的目标。相反，我们预计 Android 上的跨应用和跨网站衡量在 3PCD 时能够实现相当高的兼容性，并随着用户更新手机而不断提升。 |
| 浏览器的角色 | Chrome 似乎充当了广告服务器或 SSP 的角色。 | Chrome 并未扮演广告服务器或 SSP 的角色。借助 PA API，Chrome 为广告服务器、SSP、DSP 和其他广告技术平台提供了一个容器，可支持自己的出价和评分逻辑。 |
| 用例指南 | 就 Privacy Sandbox API 将支持哪些用例提供更明确的指导。 | 在 Privacy Sandbox 项目开始时，开发者文档主要侧重于吸引开发者参与所有提案的讨论和反馈流程。这意味着，在大体上，这些内容围绕着项目背后的动机和概念设计，然后是每个提案的早期开发和测试细节的详细信息。 这在开发提案的过程中有效地建立了真正的生态系统协作，但随着 API 的全面推出，越来越多的开发者在这里构建 API，而不是为底层开发做出贡献。 最近，我们更新了 Privacy Sandbox 中 以 Task Sandbox/Privacy Sandbox 为主题的 IAB 导航界面。今后，我们将继续采用这种基于用例的文档编写方法。 |
| 本地开发环境 | 当 Cookie 为 SameSite=Secure 且后端以 CDN 为前端时，我们该如何继续在 http://localhost 上本地开发和测试前端？ | 我们将在此处讨论此问题，欢迎 YouTube 生态系统提供更多反馈。 |
| 缓解 3PCD | 是否有办法通过程序化方式得知 3PC 被屏蔽或何时使用了启发法？ | 在 Chrome 中，功能检测和在 iframe 中调用的 document.hasStorageAccess 都有助于开发者了解 iframe 中的来源是否可以访问 3PC。 |
| 视频测试 | 目前无法在 Privacy Sandbox 中测试视频广告。 | Chrome 今天发布了讨论和演示，介绍了使用 PA API 实现视频的几种可能方式（请参阅 GitHub 上的演示代码库中的 242 和 254）。请注意，这些内容并不是广告技术平台会批量采用的示例代码，而是作为概念验证和技术演示，支持通过 PA API 支持 VAST 视频呈现。 在讨论过程中，我们还清楚地了解到，尽管现在已经可以进行视频呈现，但 Chrome 也可以做出一些更改来简化 PA API 的实现。例如，我们已根据对第三方广告验证程序品牌保障用例的反馈对宏替换进行了（ 此处讨论）的更新，也解决了视频用例中的反馈（买方正在寻找要在呈现中使用的卖方宏）。 到目前为止，我们讨论的大多数讨论都特别侧重于呈现 VAST 视频广告。呈现原生广告可以利用同样的方法，而且在很多方面更简单。原生广告目前获得的关注似乎不如视频广告，但这只是广告技术行业优先考虑的问题，不存在任何技术障碍。 |
| 衡量非广告 | 第三方 Cookie 可能会影响与广告无关的受众群体衡量解决方案。 | 衡量 API 不要求用例与广告相关。 ARRA 更特定于典型的广告历程，而 不公开汇总则是通用目的。这两个基础组件可用于解决大范围的衡量活动。 |
| 内容创作者 | Privacy Sandbox 旨在鼓励内容创作者为 YouTube 创作更多内容，而减少在自己网站上创作的内容。 | Privacy Sandbox 计划专注于在开放且免费的互联网上确保用户活动的私密性。我们知道，发布商依靠广告来制作内容，并尽可能为更多人提供内容。广告客户可帮助人们发现他们可能想要的新产品或优惠。借助 Privacy Sandbox 功能，各种网站（包括与内容创作者合作的网站）可以根据用户与不同各方的活动，向用户展示有用的广告，而不会向各方透露用户身份。 |
| 时间轴更清晰 | Privacy Sandbox 技术的发布时间表更加清晰、更加详细。 | Privacy Sandbox API 文档包括 API 状态和可用性页面。这些页面列出了即将推出的功能及其时间表（例如 PA API、 ARRA）。您可以在此处集中查看这些状态。 |
| 机器学习 | 除非 3PCD 的比例超过 1%，否则广告技术平台将无法正确训练机器学习模型。 | 将 3PCD 扩展到更多浏览器进行测试并不能保证 API 能够获得更多使用量，这很可能是广告技术平台为了进一步训练机器学习模型而寻找的内容。如果广告技术平台为了进一步训练机器学习模型而追求的不是更广泛的生态系统使用，那么就没有理由扩展 3PCD，因为希望基于更多流量训练模型的广告技术平台如今可以在不增加 3PCD 的情况下实现这一目标。如果 Chrome 在待机模式结束之前在 3PCD 模式下继续运行，则不需要 Chrome 这样做。 |
| 不支持的用例 | 目前不考虑自助式 DSP 用例。 | 有多个自助式需求方平台会定期就这些 API 提供公开反馈。其中一些定期提供公开反馈的 DSP 也将自己列为测试人员。 此外，Chrome 还在积极参与常见的自助式 DSP 主题，例如视频和第三方广告服务器。最近的每周 PA API 调用涵盖了这些主题。 |
| 源试用 | 希望针对 3PCD 采取更积极的磨合期并测试覆盖率的网站申请 OT。 | Chrome 目前正在开发第一方 OT，它允许源站选择实施第三方逐步淘汰行为。对于已注册此试用并部署令牌的顶级源，系统会阻止 3PC，就像该用户设备启用了跟踪保护一样。在最终逐步淘汰 3PC 产品之前，此 OT 将为网站提供有价值的机会，使其能够更广泛地测试 3PC 的长期替代方案。 我们仍在努力确定 OT 的推出时间表。 |
| IAB Tech Lab 报告 | 从 IAB Tech Lab 报告中收到关于 Privacy Sandbox 的反馈。 | 我们已在此处对 IAB Tech Lab 报告进行了详细回复。我们也承认，“该报告会提出与碎片化的文档、商业要求、第三方审核、行业认证、可伸缩性、透明度和未来治理相关的问题，我们将就这些问题与生态系统展开合作，并相应地更新我们的公开常见问题解答。” 我们之前处理的是碎片化的文档。我们在此处列出了“数据保证”下的商业要求，一些 Google 广告产品已经分享了他们采取的方法。我们在此处介绍了“算法完整性保证”下的第三方审核。在认证方面，我们希望这些机构继续对产品（包括对技术的使用）进行认证，而不是自行认证相应技术。在可伸缩性方面，我们将继续接受开发者提供的问题数据。在透明度和治理方面，我们继续在 GitHub 上和 W3C 等论坛上进行公开开发，同时根据承诺与 CMA 互动。 |
| Google 登录功能 | Google 登录可能会导致 Google 使用与承诺相反的交叉标识登录数据。 | Google 登录不会使 Google 能够使用与承诺相悖的数据。 |
| 兼容性 | Privacy Sandbox API 支持和向前 / 向后兼容性方面有哪些计划？ | 当 Chrome 推出某项功能正式版后，我们的目标是继续支持该功能。当然，我们未必总能保持向后兼容性。在这种情况下，我们有明确的弃用和移除现有功能的流程，详见此处。 随着生态系统的反馈，这些用例将从改进的支持中受益，我们预计会随着时间的推移不断为 Privacy Sandbox API 添加更多功能。在这种情况下，我们倾向于包含某种特征检测技术，这样一来，有兴趣试用新功能的广告技术平台就可以直接询问浏览器是否支持该功能。这比要求开发者检查特定 Chrome 版本号更好，因为某些功能可能不会同时面向 Chrome 的所有用户推出。例如，如需查看 PA API 的功能检测工作，请点击此处。 |
| 服务器实现 | Chrome 应指定可信信号服务器、聚合服务器以及任何其他必需的非浏览器组件的理想实现所必须满足的行为，而不是与自己的实现相结合。这有助于在可接受的隐私边界内实现创新。 | 我们很感激并欢迎外部各方进行创新。对于所有 API 和服务，我们的目标是让广告技术平台能够灵活地实现其功能。例如，我们允许广告技术平台使用机密商务信息为竞价设计出价逻辑。此外，我们会持续积极听取广告技术平台的反馈，并在合理的情况下将反馈整合到我们的设计中。 为了让其他人能够在可信执行环境中运行自己的代码，Privacy Sandbox 需要审核代码（及任何更改），确认其符合隐私保护保证。这将需要 Privacy Sandbox 团队的大量工作。因此，我们希望了解利益相关方希望实现什么，而我们目前无法达到这些好处。 |
| 启发词语 | 启发词语的长期计划是什么？ | 根据其他浏览器的说明，我们打算最终弃用这些启发式方法，因为替代解决方案被广泛使用，并进一步进行可行性分析。我们在此处分享了这些信息。 |
| 测试卷 | 比较不同维度时的流量不同。 | 这 1% 的实验设有排除条件，这会导致不同 Chrome 客户群体参与实验的资格有所不同。例如，实验排除了 Chrome 企业版用户，因此带有实验标签的流量比例预计会在周末偏高。不同数据细分（例如地理位置、日期和平台）显示的流量百分比是正常现象，这与我们在 Chrome 数据中看到的流量一致。 |
| 手动重新启用 3PC | 在强制执行第三方 Cookie 后，网站能否知道有多少用户 (%) 手动重新启用了 Cookie？ | 如果用户遇到服务中断，可以通过“用户绕过”在网站级别重新启用第三方访问。也可以通过其他措施（例如 Storage Access API）重新启用 3PC。网站可以检测是否启用了 3PC 等技术措施，例如 hasStorageAccess()。不过，Chrome 不会帮助网站了解重新启用的原因。 |
| 跟踪保护 | Chrome 的“跟踪保护”界面功能可以使用多久？ | 预计在弃用 3PC 之后，地址栏中的“跟踪保护”界面仍会继续显示。 |
| （在前几个季度也有报告） 跨浏览器支持 |
采用 Privacy Sandbox API 的其他浏览器供应商。 | Apple、Mozilla 和 Microsoft 等其他浏览器供应商都在讨论隐私权原则和基于浏览器的方法的公共论坛上积极参与。在最近的 W3C 年度 TPAC 会议和正在进行的 W3C PATCG 论坛等论坛上开展的协作讨论让我们得到了一些鼓舞，我们在这些论坛中看到了共识。例如，Microsoft Edge 最近宣布了其计划，其“旨在最大限度提高语法与 PA API 和 ARA 的兼容性，同时也为开发者提供更多功能。 |
| 3PCD 后不兼容的嵌入的后备选项 | 提供 API 钩子，以检测第三方 iframe / 嵌入代码是否符合 3PCD。 | 我们将在此处讨论这项请求，欢迎 YouTube 生态系统提供更多反馈。 |
| 测试 | 请求在 Chrome 的受管实例中用于暂时关闭自定义行为的其他标志。 | 我们正在考虑这项针对 Chrome 托管实例的请求，欢迎整个生态系统的用户提供更多反馈（如果有帮助的话）。 |
注册和证明
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 认证验证 | Google 如何确保证明的真实性？ | 所有注册者在使用 API 时都必须保留证明文件。Google 会验证文件是否已设置妥当且语法正确无误，但 Google 不会验证广告技术平台在认证语言方面的行为。 |
| Private Aggregation API 注册流程 | 是否可以检查 Private Aggregation API 的注册状态？ | 注册得到验证后，注册支持团队会为所有获得批准的注册者发送电子邮件通知。如果注册者在此过程中遇到任何问题，可以联系支持团队（提交注册表单时即会联系支持团队）。支持团队会回复并解答问题，并提供所需的额外指导。 |
展示相关的内容和广告
主题
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| （也会在前几个季度进行报告） 分类器时间表和文档 |
应该设置某种形式的机制来接受分类审核，或者至少提高对分类模式如何确定类别的透明度。 | 我们的回应与之前几个季度相比没有变化： “网站分类错误可能会使 Topics 信号作为一个整体的信号略有下降，但被错误分类的特定网站受此影响的可能性不会比任何其他网站多，也不会减少。这是因为网站的上下文信息始终可用于其网站上的竞价，即使分类有误，这些背景信息也能提供与正确主题相当的信息。我们欢迎您在此处就此主题提供反馈。” |
| Google Ad Manager | 大多数网站都已嵌入 Google Ad Manager，与网站数量较少的竞争对手相比，Google Ad Manager 可提供更广泛的用户主题信息。 | 观察要求是为了确保 Topics API 分享用户数据的实体不会超过其所取代技术（包括 3PC）的数量。Prebid 等其他行业解决方案支持数万个网站，让市场参与者能够通过他们的技术调用 Topics API。此外，值得注意的是，每周最多 5 个热门主题的限制可能会产生相等的影响，因为许多网站的市场参与者在使用 3PC 学习的主题数量超过 5 个的情况下，最多只能使用 5 个主题。 |
| （在前几个季度也有报告） 对不同类型的利益相关方的有用性 |
根据网站的流量水平或内容的专业程度，为网站创造的价值以及对价值的分配有所顾虑。 | 我们发现，与一般兴趣域相比，专门的网站更有可能提供更具体的主题。不过，并不是所有专业网站都提供具有商业价值的主题。此外，这种变化也反映了现状，并且完全独立于 Chrome 不再支持第三方 Cookie。另外，在当前环境下，在基于第三方的广告相关性系统中，一些网站能提供比其他网站更多的价值。 此外，专业网站之间的主题可能是彼此互利的，因为不同的广告客户可以针对不同主题投放广告系列，并且出价逻辑可以观察广泛主题的价值。 |
| 主机名与完整网址 | 与完整网址相比，基于网站主机名进行分类是否足够有效？是否能够降低隐私风险？ | 我们考虑过使用信息网址或网页标题以及主机名，并且认为用户隐私和安全方面的风险将抵消潜在收益。举例来说，用户隐私风险的一个示例包括将网址或网页标题中的敏感信息分类为用户的主题。 |
| 将主题作为信号 | 请求获得有关如何将 Topics 与其他信号结合使用的指导，以及哪些其他信号可能有用。 | 广告技术解决方案可将所有可用工具（例如，机器学习、来自可保护隐私的 API 的注重隐私保护的信号）与情境数据、广告素材数据和第一方数据相结合，从而实现最佳效果。如需进一步指导，请点击此处。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 测试流量 | 测试人员报告称，针对 PA API 竞价的出价响应数量较少。 | 1. 出价密度与生态系统对 PA API 的参与率相关，我们预计该 API 将在 2024 年及以后继续提高。预算分配方式最终将由广告客户、其代理机构和技术提供商决定。我们预计，一些生态系统参与者可能会在 3PCD 之后推迟对各种“无 Cookie”解决方案（包括 PA API）的投资。届时，我们预计他们可能会增加为此类解决方案分配的广告系列预算。 2.PA API 竞价中的出价请求数可能会受到以下因素的影响：(1) 如果发布商及其广告技术提供商认为需求较低，可能会决定不发起 PA API 竞价。更新网页及参与此计划的优先级由发布商决定。出于这些原因，我们预计发布商可能需要一些时间进行测试并逐步增加流量。此报告还包含 Google Ad Manager 关于其发布商针对 PA API 参与使用的控件的回复。 |
| （此前几个季度也有报告） 欺诈 / 滥用 |
生态系统如何降低风险，并阻止不法分子或买方将自己定位为理想的受众群体？ | PA API 广告的报告机制会保留用于区分真人和机器人流量的信息。此外，目前基于网域的技术（包括或排除网域）可用于 PA API。如需了解详情，请参阅我们回复 IAB Tech Lab 就 Privacy Sandbox 发布的报告。 |
| 针对 IG 所有者和出价逻辑网址的同源限制 | 如果有同源要求，IG 所有者的端点将不得不通过同一负载平衡器，这可能会导致重定向遭拒。 | 脚本加载的同源要求是一项重要的安全保护。请参阅此处，了解有关建议的解决方案的一些详细信息，以在生态系统反馈和其他注意事项之间取得平衡。 |
| 多广告位私下竞价 | 通过使用噪声以及与广告当前做法更紧密的集成，在隐私保护边界内允许进行多广告位私下竞价的大有空间。 | 我们正在考虑这些反馈，并评估这项多代码竞价请求，以便防范因此功能而增加的复杂性和隐私风险。我们在此处的 PA API Web Incubator 社区小组 (WICG) 通话中进一步讨论了此问题。 |
| 顶级卖家 | 相较于发布商或组件卖方，PA API 的当前结构为顶级卖方提供的数据和对展示机会相对价值的理解要多得多，并且其数据要多得多。 | 在多卖家竞价中，每个卖家将有一个最佳出价。此外，我们还从生态系统中了解到，发布商可能希望在与其合作的每个卖方的最高出价旁边考虑直销需求。为了确定要投放哪个广告，一定要分析所有这些潜在的创收机会。在这种情形下，一些参与者需要查看完整的选项集以选择要投放的广告，这种情形在 PA API 之前就已推出。 PA API 旨在支持多卖家竞价，支持发布商在直销广告系列（在后者适用的情况下）旁边考虑每个卖家的最高出价。这意味着，需要一种机制，让您从像现在这样创收机会中进行选择。我们不认为应该由浏览器的角色来选择投放哪个广告。因此，从许多可能性中选择胜出的广告时，有必要遵循顶级卖方的概念。该顶级卖方的逻辑必须能够考虑发布商选择合作的每个卖方的最佳出价。卖方的逻辑可能会选择在获得发布商的直销广告系列的情况下提供该信息。可以在顶级广告选择逻辑中考虑所有这些信息。这意味着，顶级逻辑会查看 PA API 竞价的最佳出价，以及在适用的情况下查看发布商的任何直销广告选项，以确定胜出者。 在此报告中，Google Ad Manager 以“信息访问”为主题，以顶级卖方的身份详细说明了 PA API 的实现情况。 |
| 竞争性广告分离 | 请求分离竞争性广告，例如防止来自竞争品牌的广告彼此并排展示。 | 在当今的程序化、出价、多卖家数字广告生态系统中，我们不知道有方法可以确保竞争隔离。 但是，PA API 让卖方能够根据 render网址 和主机名（代表发布商网域）的组合，提取更多实时信号，在对广告素材进行评分时，可以在 scoreAd() 中使用这些实时信号。如果发布商要强制执行此规则，卖方可以使用此属性来防止来自竞争品牌的广告彼此相邻。 |
| 信息有限 | PA API 可减少发布商可用的信息，例如广告价值、组件买方名称、广告客户名称、着陆页网址、广告素材尺寸、响应时间和出价率，以及落败出价。 | 我们在此处提出了一些潜在解决方案，欢迎生态系统方提供更多反馈。 |
| 事件级报告 | 在事件级报告 PA API 弃用后，发布商无法获取关于所投放广告的足够信息。 | 我们了解了各种报告用例，在事件级报告功能停用后，我们必须继续支持这些用例。因此，我们将事件级报告功能的停用日期指定为不早于 2026 年。在此期间，我们诚邀您积极参与，因为我们会与生态系统合作，共同探索长效的前进道路，其中可能包括以保护隐私的方式获取信息的新想法。 |
| 多个 SSP | 对于发布商而言，拥有多个 SSP 带来的附加价值太低。 | 我们不认可您的观点，欢迎生态系统提供其他反馈，以了解理由。 |
| 策展活动 | 无法通过 PA API 进行精选活动。 | 我们听到了关于卖方可以使用 PA API 向整个网络上的买方提供受众群体信息（也称为受众群体扩展）这一功能的反馈。我们相信，通过使用 PA 的委托功能以及业务协议，现在已经可以实现这一目标。同时，我们正在积极考虑是否以及如何更好地适应这些类型的应用场景。 |
| 买方选择停用 | 买方默认拒绝联系可能会导致组件竞价结果变差。 | 无论是定义单卖方竞价还是多卖方 PA 竞价，卖方都必须在 ConversionConfig 的 InterestGroupBuyers 字段中明确列出买方。这基于生态系统反馈，卖家与部分买方（而非其他买方）签订合同协议，因此需要明确控制让哪些买方参与竞价。 欢迎在 GitHub 上展开进一步讨论。 |
| Adsize | 无法根据 adsize 和 adSlotSize 进行预过滤。 | 我们正在努力添加此功能，如需了解更多详情，请点击此处。 |
| 支持排除性 IG 定位 | 一个支持否定 IG 定位的 API：仅在用户不属于某个 IG 时展示广告。 | 此 GitHub 问题提出了一种实现排除性定位的替代方法，即浏览器直接告知广告服务器应针对特定广告请求应用哪些排除性定位规则。虽然这种方法看似很有吸引力，但我们研究的这种想法的所有版本都让服务器能够唯一标识用户。 |
| 数字服务法案 | 发布商如何使用围栏框架来阻止呈现包含受《数字服务法案》约束的信息的响应？ | 与任何新技术一样，每个公司都有责任确保自己对 Privacy Sandbox 的使用符合法律规定；Google 无法向他人提供法律建议。对于每个 API，我们都发布了详尽的技术文档，这些文档应该为进行必要的法律评估提供依据。从 2026 年开始，在 PA API 中无需使用围栏框架，这让利益相关方有更多时间来确保其对这项技术的使用符合所有相关法律法规。 |
| 文档 | updateAdInterestGroups() 是临时的吗？ | 我们尚未宣布任何弃用 updateAdInterestGroup 的计划。未来，我们可能会采用我们公开讨论过的其他 IG 更新机制类似的隐私保护措施，例如同时使用 IP 地址代理，并在更新之前增加一定的延迟。 |
| 面向非 DSP 的买方元数据和逻辑所有权支持 | 请求提供某种方式作为 DSP 的代理。 | 我们已了解到非 DSP 细分受众群提供的反馈，并且正在考虑此要求。欢迎生态系统中的其他反馈。 |
| 报告 | 请求为不公开汇总报告中的信号范围 / 价值添加自定义处理程序功能。 | 我们已经了解，此功能请求已排队等待进一步发现。欢迎点击此处，从生态系统中获得其他反馈。 |
| 文档 | 是否有可供查看需要由广告客户和（受托）所有者网域设置的所有响应标头的链接？ | 我们计划更新文档以阐明这一点，并欢迎生态系统提供其他反馈。 |
| 多塔出价 | 请求通过架构 / 方块图对工作流（训练和推断）进行说明，说明如何在 PA API 上下文中构想多塔方法。 | 感谢您的反馈。我们针对此主题提供一些演示文稿，预计会据此编写其他文档。 |
| 排除性定位 | Privacy Sandbox 能够保护敏感受众群体和未成年人免受不当广告（例如赌博）的侵扰。 | PA API 不会考虑所展示广告的内容。这由使用 PA 的广告技术开发者控制。一般来说，发布商及其广告技术提供商可以在 Protected Audience 竞价中屏蔽广告素材，方法是使用来自网页的情境信息以及发布商规则集。这反映了我们目前理解生态系统如何应对这些挑战。对于买方而言，否定 IG 定位功能对某些合规用例可能也有用。 |
| API 设计 | Google 正在回绝，希望广告技术平台使用通用出价功能，从而增加延迟时间，而不是在不同 IG 中使用不同的 biddingLogic网址（这是允许的）。 | 在讨论竞价延迟时间的过程中，我们强调了在买方的所有 IG 中重复使用同一脚本可以提高该买方的出价运行速度。此处更详细地介绍了这一点，以及我们针对缩短 PA API 竞价延迟时间的其他建议。 |
| 基于账号的营销 | PA API 不是基于帐号的营销用例的简洁 API。 | 我们欢迎生态系统中的用户就他们认为不可能实现的任何特定用例提供反馈，并鼓励生态系统参与者通过我们的公开 GitHub 代码库或每周通话继续进行讨论。 |
| A/B 测试 | 如果您在 GAM 中为发布商配置了 PA API，那么目前必须为所有广告资源启用此 API 或者不为任何广告资源启用 PA API。这会限制发布商进行可行的 A/B 测试的能力。 | Google Ad Manager 提供的响应 ：Google Ad Manager (GAM) 中的 PA API 控件会影响 GAM 能否使用该 API，前提是该 API 可用。因此，发布商可以使用 Chrome 的权限政策功能来禁止对一部分流量使用该 API，从而将其用作 A/B 测试的对照组，从而运行 A/B 测试。 |
| 机器学习 | 发布商需要更好地控制 GAM 提议的机器学习用途。 | Google Ad Manager 提供的回答： 2024 年 1 月，我们推出了一个控件，使发布商能够针对其所有流量停用我们的机器学习限制器，并针对非 Google 卖方启用 PA API 竞价。如需详细了解此控件，请访问我们的帮助中心。 |
| （也会在前几个季度进行报告） 顶级竞价 |
能够使用 Google 的发布商广告服务器，但不让 GAM 控制顶级 PA API 竞价。 | Google Ad Manager 提供的响应： 出于 Google 2023 年第 3 季度的报告中所述原因，GAM 的 PA API 集成计划不包括支持发布商将 GAM 用作发布商广告服务器，而无需控制顶级竞价。 |
| 信息访问 | GAM 可以获取竞争对手的宝贵信息，包括内容相关竞价的价格、买方为 PA API 竞价向 SSP 提供的信号，以及来自 SSP 的配置参数。 | Google Ad Manager 提供的回应： 多年来，我们一直非常看重竞价的公平性，包括我们承诺：在另一买方参与竞价之前，发布商的任何无保证广告来源（包括无保证订单项的价格）都不会与其共享价格，我们后来在我们对法国竞争管理局的承诺中重申了这一点。 对于 PA API 竞价，在完成多卖方竞价中的竞价之前，我们致力于兑现我们的承诺，不会在竞价完成前与任何其他竞价参与者共享任何竞价参与者的出价。需要说明的是，正如本次更新中所述，我们不会与任何组成部分竞价（包括我们自己的竞价）共享内容相关竞价的价格。 此外，我们自己的竞价不使用组件竞价配置的相关信息，包括买方向 SSP 提供的信号。事实上，我们非常欢迎对 PA API 进行更改，让组件卖方可以采用与顶级卖方混淆的方式指定组件竞价配置。 |
| 零部件拍卖 | 作为顶级竞价，GAM 会控制哪些 SSP 针对每个广告机会进行组成部分竞价。 | Google Ad Manager 提供的响应： 作为发布商广告服务器，GAM 为 SSP 提供了一个轻量级 API，发布商可能会与 SSP 合作，通过 Google Publisher Tag (GPT) API 指定其组件竞价配置。如需了解详情，请点击此处。 如果 SSP 通过此 API 提供组件竞价配置，他们就会被纳入该广告机会的组件竞价列表中。GAM 不会对所含的组成部分竞价施加任何限制。任何想要运行组件竞价的 SSP 都可以参与竞价，但前提是发布商允许其在发布商网页上执行必要的代码。 |
| 零部件拍卖 | GAM 可以对每个在竞价中胜出的出价应用特定且未披露的底价。 | Google Ad Manager 提供的回复： 多年来，GAM 一直非常关注竞价的公平性。为了维持公平透明的竞价机制，我们不支持仅适用于特定需求细分的底价。这也是我们产品中的一项原则，在 PA API 竞价中也将继续如此。 |
| 第三方广告服务器 | 第三方广告服务器无权参与 Google 的更高级别竞价，因此在使用 PA API 的情况下，从 Google SSP 需求中获益的能力有限。 | Google Ad Manager 提供的响应： 目前，GAM 支持通过此处所述的 API 在 GAM 上与多个卖方一起测试 PA API。目前不支持将 GAM 作为组件竞价参与其他顶级竞价。 |
| （在前几个季度也会报告） PA API 竞价的效果 |
测试人员报告称 PA API 竞价的延迟时间较长。 | 我们听说过对延迟的担忧，为此，我们在 PA API 中开发了许多功能，这使得 SSP 既能设置 DSP 延迟的限制，又进行改进，从而减少延迟。我们最近更新了延迟时间最佳做法指南，其中详细介绍了如何充分利用这些功能。我们还在继续开发新的延迟改进措施，其中的部分内容可在此处查看。 |
| （也会在前几个季度报告） 视频呈现 |
支持使用 PA API 和围栏帧呈现视频。 | 我们在 1 月发布了一份演示视频在私下竞价竞价中的运作方式，并进一步详细说明了其他方法。我们还看到，生态系统播放器开始提议与合作伙伴集成视频渲染的工作原理，例如 GAM 关于视频兼容渲染网址构建方案的提案或完整的端到端流程。 此外，我们正在倾听生态系统的反馈，了解我们可以采取哪些更改来提高采用率，GitHub 中详细说明了一项此类更改。 我们一直积极与生态系统互动，以发现我们在采用视频渲染的过程中可能遇到的任何其他障碍，并加以解决。 |
| （也曾在前几个季度进行过报告） 数据处理政策 |
IG / PA API 的数据处理政策是什么？ | 在 PA API 设计中，所有存储在 IG 中的数据或与 IG 中人员有关的数据都会：(i) 保留在设备端，或 (ii) 在可信执行环境 (TEE) 中运行的出价和竞价 (B&A) 服务中处理。在这两种情况下，数据不会被任何其他方读取，也不会以任何其他方式使用这些数据，除非是在竞价中生成出价。 Chrome 正在探索的一些隐私保护增强功能确实会涉及与 Google 运行的 k-匿名性服务器互动。这种互动方式经过精心设计，避免分享用户信息，而且会在 TEE 中运行，以确保整个广告生态系统中的信息保持一致。 Google 已承诺 CMA 设计和实施 Privacy Sandbox 提案，以确保不会因自谈 Google 自己的业务而影响竞争，同时考虑到对数字广告领域的竞争以及发布商和广告客户的影响。我们将继续与 CMA 密切合作，确保我们在工作中履行这些义务。 |
| （在前几个季度也进行了报告） IG 生命周期 |
申请将 IG 的生命周期从 30 天延长至 90 天。 | 此类更改需要仔细评估，权衡对行业带来的好处和对 Chrome 用户和其他利益相关者的影响。我们正在考虑此申请，欢迎您点击此处提供其他反馈。 |
| （在前几个季度也会报告） 建模信号 |
除了 modelsSignals 之外，还请求一个新字段，只能对展示广告和点击信息进行编码。 | 我们已在此处回复了此反馈，并提供了抗辩通知。我们正在积极与业界互动交流，以了解他们对我们的提案的看法，并将对行业带来的益处与对 Chrome 用户和其他利益相关方的影响进行权衡。 |
| reportWin() 中的其他位 | 在 reportWin() 中提供额外的位（超出 3PCD 之前当前上限 12）。 | 我们目前正在探索支持此用例的方法。这需要一些时间，因为我们也在寻找方法来帮助确保我们拥有长期的隐私保护计划。 |
| 竞价设计 | 针对会返回呈现网址及其相应得分的单次竞价的请求。 | 我们曾考虑在单次 PA 竞价中共享多个 render网址 及其各自的得分，但由于隐私问题，我们并未实施。我们理解，开发者希望避免在一个页面上多次向用户展示同一广告，也欢迎在 GitHub 上展开进一步的讨论。 |
| reportWin | 在 reportWin() 函数中记录任意字段。 | 目前，在整个测试期间，这种情况已然发生。Chrome 停止对 3PC 的支持后，API 的 forDebuggingOnly 版本将迁移以启用下采样调试（详见此处）。 |
| 组件卖方 | 具有独立的机制来统计自己的展示次数和其他事件，而无需仅依赖于广告技术平台的报告。 | 此功能请求已排入我们的队列，等候进一步发现。我们预计不会在 Chrome 协助的测试期间解决此问题。 |
| 每次点击费用结算 | 在 PA API 中实现每次点击费用结算。 | 我们正在考虑此处提出的这项请求，目前，这项请求旨在提供关于如何通过当前的 API Surface 实现该 API 的建议。 |
| browserSignals | 向卖方的报告 browserSignals 规范添加了 IngressBidInSellerCurrency。 | 我们正在考虑此申请，欢迎您点击此处提供其他反馈。 |
| 为非 DSP 提供买方元数据和逻辑所有权支持 | 目前的 API 设计可能会导致产品级重访定位广告活动发生重大转变，在这种情况下，广告系列可能需要迁移到同时充当 DSP 和 DCO 提供商的平台。 | 我们正在讨论此问题，欢迎点击此处 提供其他反馈。 |
| 为非 DSP 提供买方元数据和逻辑所有权支持 | 分享需求方平台不是 IG 所有者的示例。 | 据我们了解，非出价方希望使用 IG 的部分功能，而不使用其他功能。我们正在积极评估这些用例的解决方案，欢迎在此处提供其他反馈。 |
| 超时控件 | 发布商应该能够决定能够参与的 IG 数量以及顶级超时 / 全局超时。 | 我们理解，人们希望加强超时控制，并提高顶级销售人员和组件销售人员的可见性，因此我们正在考虑这一要求。 |
| 多个广告尺寸 | 针对多广告尺寸用例的 PA API 支持。 | 我们正在考虑此申请，并欢迎您提供生态系统的其他反馈。 |
| 文档 | 是否有受 k-匿名性影响的 IG 属性列表？ | 我们已在此处回复了此问题。 |
| 调试 | 改进了 PA API 的调试功能。 | 我们认识到，强大的调试工具对于使用 PA API 的开发者来说非常重要。我们致力于通过探索将 .well-known 文件提取与开发者工具更好地集成的方法，从而提升开发者体验。我们的目标是在开发环境中提供更透明的问题排查功能。我们将在此处进一步讨论此问题，欢迎其他反馈。 |
| 标签 | 处于模式 B 实验组标签的所有用户都是否启用了 Privacy Sandbox API？ | Chrome 实验组分配情况是随机确定的，与用户配置的 Chrome 设置无关。 虽然这些 API 可能可供特定实验组（例如 treatment_1.* 中的用户）使用，但其功能可通过 Chrome 设置进行修改或停用。 模式 B control_2 群组：如果纳入此群组，就一定会停用 Privacy Sandbox 相关性和效果衡量 API，并且用户无法在 Chrome 设置中覆盖此设置。 |
| API 应用 | 对 reportWin() 的调用与广告呈现是并行进行的，还是相继进行？ | 系统会在 runAdAuction() 完成后直接调用 reportWin()。同时，当竞价结果置于 iframe 或围栏框架中时，广告呈现过程可能会开始。当两个 reportWin() 完成执行并且广告开始呈现后，就会获取提供给 sendReportTo() 的网址。 |
| （前几个季度也有报告） A/B Testing 支持 |
请求支持 PA API A/B 测试。 | 我们将在此处讨论此请求，欢迎您提供其他反馈。 |
| 根据流量情况调整投放速度 | Google 就通过 KV 服务器管理所需决策的提案没有帮助，因为销售人员无法与后端互动，这使得流量分析具有挑战性。 | 如 GitHub 问题中所述，公开某个 DSP 是否有 IG 可能会让用户担心指纹识别。我们已就此问题建议了其他替代方案，并愿意进一步提供建议。 |
| 根据流量情况调整投放速度 | 缓存机制进一步增加复杂性，使 DSP 无法了解其要出价的真实流量情况。 | 缓存机制只是作为一项建议提供。广告技术平台可以选择采纳适合其应用场景的建议，欢迎点击此处进行其他讨论。 |
| 标签 | Chrome 应在向买方和卖方可信服务器发送的请求中以参数形式分享该标签。 | 这似乎是合理的请求，因为它似乎与负责任的 IG 数据利用的目标大体一致。不过，我们正在考虑此要求，并由内部审核人员进行审核，并会随着讨论的进展提供有关此事的公开动态。 |
| API 应用 | 在“针对测试的第三方的其他 CMA 指南”文档中阐明了“control_1”组的明确定义。具体而言，人们担心措辞更改可能会被误解为需要从 control_1 中排除所有 Privacy Sandbox API。 | 我们在 这个 GitHub 会话中表达了自己对此问题的看法。不过，我们无权代表 CMA 发声，建议您直接向 CMA 提出与解读其 测试指南有关的任何问题。 |
| API 应用 | Chrome 是否允许在重定向到其他资源时在空白页面上调用 joinAdInterestGroup()？ | 如果用户正在访问某个网站，则网站所有者可以将调用 joinAdInterestGroup 的权限委托给第三方。这种委托机制让第三方无需通过空白页面添加任何类型的重定向即可构建 IG。 我们欢迎大家针对在重定向过程中创建 IG 的具体原因提供反馈，而不是使用预期的委托机制。 |
| API 应用 | 广告交易平台应能将 IG 写入其合作发布商所拥有的网页，然后便可将对 IG 出价的权限委托给任何给定的买方或 DSP。 | 我们已收到反馈，并且正在评估此类请求是否受支持。欢迎生态系统中的其他反馈。 |
| API 应用 | 如果没有人在 PA API 竞价中胜出，系统不会显示调试损失通知。 | Chrome 的 reportWin 和 reportResult 函数旨在生成隐私竞价 (PA) 系统内的事件级胜出报告。如果在 PA 竞价期间所有出价都被拒，由于无法确定胜出者，因此系统应该不会调用这些函数。 Chrome 的近期更新可能会说明传递到 forDebuggingOnly.reportAdAuctionLoss() 的网址未显示在开发者工具的“Network”面板中的差异。我们建议使用 Chrome 的 Canary 版或开发版 build 验证此功能。 |
| API 应用 | generateBid 返回的 adCost 是否为负数（已随机四舍五入为 2 个字节）？ | AdCost 是指广告客户的从 generateBid() 传递到 reportWin() 的点击或转化费用。该值可以为 Null 或双精度值。系统会忽略负值，且不会传递负值。传递后，该值将随机舍入。 |
| API 改进 | 可以使用可信和加密执行服务器（而非 Chrome 浏览器）来处理定位 / 同类群组 / 归因和竞价吗？ | 我们建议您探索 PA API 中基于 TEE 的组件和选项（例如 KV 服务器和 B&A 服务），以及归因报告和不公开汇总中基于 TEE 的组件（例如汇总服务），以便解决此问题。 |
| API 改进 | Privacy Sandbox 竞价响应可以是出价响应（例如标头出价）而不是广告响应（例如广告代码）吗？ | 此类更改从根本上改变了 PA API 的隐私权属性，因此我们并没有考虑此类更改。 |
| 发布商控件 | 发布商能否在其网页上屏蔽 PA API 广告素材？ | Chrome 有一项实时广告素材扫描提案，不过目前还不能进行测试。 尽管这一功能尚不可用，但我们发现大多数 SSP 都创建了用于实现此功能的解决方案。 |
| API 应用 | perBuyerSignals 的大小限制是多少？ | 在经典形式中，perBuyerSignals 在 Chrome 中不存在固有的大小限制。主要约束条件是数据保持 JSON 可序列化，并且不会导致过多的内存消耗。但请注意，非常庞大且复杂的 perBuyerSignals 可能会对广告效果产生不利影响。 我们可以使用另一种方法通过 directFromSellerSignalsHeaderAdSlot 传递 perBuyerSignals。此方法在标头内传输 perBuyerSignals，但需要遵守整个标头响应的大小上限 (10kb)。此外，各个服务器可能会强行限制其最大标头大小。 |
| 文档 | 需要更改有关从 generateBid 内部调用 registerAdBeacon 的文档。 | 我们于 2 月 17 日更新了此文档 。 |
| API 应用 | reportEvent 如何从多个注册选项中选择正确的信标网址？ | 每次竞价都会生成单独的配置，进而生成单独的报告映射。具体竞价（及其生成的框架）彼此完全独立，不会共享数据。 “围栏框架广告报告”铺垫消息就此主题提供了更多详情。 |
| Chrome 界面 | 在 Chrome 开发者工具的“应用”->“兴趣组”标签页中添加过滤条件，以便按 IG 所有者（或者也可按 IG 名称）进行过滤。 | 我们正在评估该请求，欢迎生态系统提供其他反馈。 |
| 无头 Chrome | 无头 Chrome 中的 PA API 支持。 | PA API 中有一些组件与 Chrome 相关联，例如对 Google 服务器的 k-anon 调用，这些组件在“旧版”无头 Chrome 中可能无法正常运行。 我们认为，Chrome 112 中发布的 “新版”无头 Chrome 可能会解决此问题。 |
| API 应用 | 在使用 reportAdAuctionLoss 报告损失的情况下，我们经常会看到“topLevelWinningBid=0”。这句话的解释是什么？ | topLevelWinningBid 值源自顶级卖方组件中的 scoreAd() 函数。此值在决定顶级竞价的结果方面起着重要作用。 根据解释器的说明，topLevelWinningBid 值为零或任何负数都表示相应广告没有资格赢得竞价。例如，可使用此机制来滤除未超越内容相关定位候选内容的兴趣群体定位广告。 当值为 0 的 topLevelWinningBid 可能表明内容相关竞价已胜出，但 PA API 规范也承认其他因素也可能会影响这一结果。 |
| 模式 A/B 测试 | 阐明了模式 B 和模式 A 的流量选择和停用提示。 | 模式 A 和模式 B 的计入条件相同。我们的目标是建立能代表正常 Chrome 流量的群组，前提是这些群组支持 Privacy Sandbox API 和标签方法（例如某些客户端配置不兼容）。出于实验目的，请务必只比较被标记的流量与其他已标记的流量。 模式 B 中的用户已启用“跟踪保护”功能，因此用户会收到关于该功能的通知。 |
| API 改进 | “lifetimeMs”是否可以作为直接属性包含在 joinAdInterestGroup 调用中，或者作为单独的参数进行管理？ | 我们正在仔细考虑网络开发社区对于 PA API 提案中“joinAdInterestGroup”功能的反馈。一个关键的讨论点侧重于管理 IG 生命周期的最佳方法。我们正在评估为“lifetimeMs”参数使用单独的参数的好处，该参数可以提高灵活性和适应性，以便未来可能对规范进行改进。我们在此讨论此问题，欢迎其他反馈意见。 |
| API 应用 | 由于与低熵浏览器 ID 发生冲突，PA API 框架中的假负例率可能会增加。 | Chrome 团队正积极参与不断完善 PA API 框架。我们探讨了由于浏览器 ID 冲突引起的潜在假负例率问题，对此我们深表感谢。我们会仔细评估这些反馈，并努力确保更新后的分析全面反映所有相关因素。我们的承诺是打造一种在保障准确性和可靠性的同时，实现所需的隐私保护成效的解决方案。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 为了防止客户端在 k-匿名性系统中重复提交针对同一对象的“加入”请求，是否需要使用低熵浏览器标识符？ | 我们一直在讨论如何在实现 k-匿名性系统中使用浏览器标识符，对此我们深表感谢。我们理解，人们对于此类标识符可能会对隐私保护造成的潜在影响，已有不少担忧。虽然我们在初始实现中采用了低熵标识符作为反滥用机制，但我们也在积极探索替代技术，例如匿名计数令牌，以优先考虑用户隐私，同时保持系统完整性。我们致力于寻找合适的解决方案，在负责任地使用数据与强大的隐私保护措施之间取得平衡，欢迎与研究社区继续保持对话。我们将在此处 讨论这一点，欢迎您提供其他反馈。 |
| API 应用 | AMP (Accelerated Mobile Pages) 是否支持 PA API。 | AMP 目前不支持 PA API。如果 AMP 支持非常优先，欢迎社区提供更多反馈。 |
| API 改进 | 请考虑从 k-匿名性检查中移除该类型。 | 我们正在仔细考虑有关可能会优化 k-匿名性请求结构的反馈。我们理解整合参数并可能统一类型以简化流程的建议。我们的目标是确保效率和可维护性，并且我们正在评估所有选项，以持续开发我们的隐私保护解决方案。我们在此讨论此问题，欢迎其他反馈意见。 |
| Chrome 界面 | 要求提供相关机制，让非技术用户轻松查看和管理其所属的 IG，包括提供选择停用功能的潜在网站级控制选项。 | 我们深知提供方便用户使用的工具来帮助了解和管理 IG 的重要性。我们仔细考虑了各种方法，发现按 IG 加入网站识别 IG 的方式最能平衡内容清晰度与隐私保护。目前，IG 的全局管理位于 Chrome 的设置中。我们在不断探索进一步改善这方面的用户体验的方法。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 安全 | 即使是在围栏框架中，PA API 是否也容易因富有创意的广告互动而导致隐私泄露？ | 我们深知复杂的广告互动可能会导致信息泄露。我们正在积极调查围栏框架、PA API 和潜在攻击途径之间的相互作用。缓解隐私风险是我们的首要任务，我们致力于开发强大的解决方案，在创新与用户保护之间取得平衡。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| 延迟时间 | 买方出价逻辑的 50 毫秒超时默认值是否切合实际？ | 我们理解，各方对于规范与网络请求出价逻辑的时间安排之间可能存在不一致的情况，对此我们表示理解。我们正在积极审核规范以确保其准确性，并研究最佳的默认超时设置，以平衡性能和可行性。我们在此讨论此问题，欢迎其他反馈意见。 |
| 文档 | 规范中可能存在时间泄露问题，网站可通过该漏洞推断广告是否未达到 k-匿名性阈值，并可能对跨网站跟踪造成影响。 | 我们了解到，用户提出的问题可能造成时间泄露。我们已确认规范中的情况存在，并将采取措施确保在竞价之前确定广告的 k-匿名性状态，以防止此类泄露。我们非常重视这些问题，并会更新规范以反映这些更改。我们在此讨论此问题，欢迎其他反馈意见。 |
| API 应用 | 在 PA API 中实现 SSP 屏蔽名单的方法。 | 我们认识到需要一些机制来管理 SSP 的广告限制。我们鼓励您探索相关解决方案，优先考虑设备端评估，利用现有广告元数据保护用户隐私，同时实现灵活性。我们致力于与开发者合作，在 PA API 中找出最佳方法。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 有没有可能让浏览器以网站无法检测到的方式假装执行 PA API？ | 我们了解，就目前的形式而言，网站可以检测到选择停用 PA API。我们正积极开发更多出价、排除性定位以及围栏框架呈现等功能，以加强隐私保护并努力提供无法检测到的停用选项。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| 模式 A/B 测试 | 声称要实验组 1.1 的数据中心流量。 | Chrome 团队已向 GAM 团队确认，此项流量正在从实验中滤除。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 在 PA API 中实现 InterestGroupBuyers 的效率和公平性。 | 我们深知，大家在 PA API 竞价中对“interestGroupBuyers”字段的效率和公平性进行了持续讨论。我们深知效率、隐私权和市场公平之间的权衡取舍。虽然卖方需要管理与买方的业务关系，但我们正在探索优化匹配流程的方法。这可能包括基于实时数据和混合模型的动态调整。我们会一如既往地致力于寻找能将用户隐私放在首位并支持竞争激烈的广告生态系统的解决方案。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| Chrome 界面 | 与 Chrome 中的 IG 相关的潜在内存问题和界面清晰度问题。 | 我们理解，在开发者工具中显示 IG 时引起了人们的担忧。虽然当前视图反映了所有 IG 事件以便进行历史跟踪，但我们深知更清楚地了解已存储 IG 的当前状态。我们将探索优化措施和潜在的界面改进，以深入了解开发者。 在内存管理方面，IG 实现旨在防止内存泄漏，但我们会持续监控和优化资源使用情况。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| 文档 | 原始发布者在尝试直接在“joinAdInterestGroup”函数的“sizeGroup”字段中使用已命名的广告尺寸时，会遇到错误。他们想知道这是否属于预期行为。 | 我们认识到在“joinAdInterestGroup”函数中简化广告配置的价值。我们正努力突破此限制，并计划在未来的更新中启用此功能。这一增强功能与我们承诺向开发者提供灵活高效的广告管理工具相一致。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| Chrome 协助测试标签 | 要求在 sendReportTo 中获取关于模式 A 与 B 的直接数据，以及确切的标签，以便我们能够一致地跟踪实验。 | 我们将在此处讨论此请求，欢迎其他反馈 |
| 文档 | 向卖方的可信服务器发出的请求中是否已包含卖方的域名，以便进行验证？ | 我们确认，Protected Audience KV Server API 文档中一开始省略了主机名参数。我们希望向开发者保证，向卖方的可信服务器发出的请求中，卖方的域名会自动包含在请求中。此功能对于强大的广告验证流程至关重要。我们更新了相关文档，以解决此监督问题，并将一如既往地优先考虑为开发者社区提供清晰透明的信息。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 可能的方法为在广告展示跟踪调用中添加 IG 名称，以便生成报告。 | 我们致力于平衡对强大报告机制的需求与用户隐私基本原则。将 IG 名称纳入广告展示跟踪范围时，需要遵守 k-匿名性保护措施，该保护措施旨在防止识别个人身份。我们将继续探索在这些隐私保护限制下创新的报告解决方案。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 功能 | 请求买方可信服务器接收 Client Hints HTTP 标头。 | 我们将在此处跟踪此功能请求。 |
| API 应用 | 委托文件是否应要求加载“Access-Control-Allow-Origin”标头（前提是该标头规定了浏览器的 IG 成员资格行为）？ | 我们致力于遵循网络安全最佳实践。授权文件使用“Access-Control-Allow-Origin”标头这一要求可确保符合 CORS 原则，并防止敏感信息意外泄露。我们正在寻找优化此过程的方法，同时保持可靠的安全状况。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 允许广告服务器在 PA API 框架内对广告素材进行个性化设置。 | 我们了解广告服务器在广告素材个性化方面可以发挥的作用。我们正在积极探索各种解决方案，以便通过 PA API 为广告服务器赋能，例如可将出价和广告素材选择逻辑结合起来的“联合 IG”模型。我们的目标是在实现强大的广告素材功能与保护用户隐私之间取得平衡。我们欢迎您就此 API 的改进展开进一步协作，并提供反馈，以满足所有利益相关方的需求，详见此处。 |
| 隐私问题 | 备用标识符（例如RampID、ID5）通过促进跨网站数据收集，可能会破坏 PA API 的隐私保护目标。 | 我们深知跨网站标识符与 PA API 的隐私保护目标之间的潜在冲突。虽然发布商可以选择共享此类标识符，但 PA API 的设计根本目的是将广告选择与跨网站跟踪的需求分离。我们致力于打造以隐私保护为中心的广告生态系统，并鼓励开发者优先采用 PA API 方法。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| 缓存 | 有没有办法防止在多个竞价中重复使用出价脚本？ | 我们确认观察到在 PA API 框架内观察到出价脚本的缓存行为。虽然支持标准 HTTP 缓存机制，但由于设备挂起行为和出价执行程序的设计，脚本在各竞价中重复使用的可能性仍存在。该团队正在研究相关解决方案，让买方能够更好地控制脚本缓存，从而有效管理其出价策略。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 针对 DSP 集中报告所有 IG 中的出价活动，同时尊重用户隐私。 | 在设计 PA API 时，我们将用户隐私放在首位。由于跨网站跟踪风险，直接报告个别出价事件的做法不可行，但我们提供了共享存储空间和不公开汇总等机制。这样一来，需求方平台便能以保护用户隐私的方式，获取有关出价活动的汇总数据洞见。 |
| API 应用 | 与通过 forDebuggingOnly.reportAdAuctionWin() 注册抓取操作相比，在 reportResult() 中的 sendReportTo() 中发生抓取事件有 94% 发生。 | 虽然它们的时间可能不同，但可以同时获取这两个网址。 在某些情况下，组件卖方的 Worklet 会被处理并需要重新加载，然后才能运行 reportResult() 函数。不过，提取评分逻辑和重新加载 Worklet 所需的时间都不会影响 reportResult() 的 50 毫秒超时。请注意，在需要重新加载 Worklet 时，Chrome 会使用缓存标头来定义其提取行为。 您可以点击此处详细了解 PA 竞价的各个阶段。 |
| K-匿名性 | 请求确认兴趣组的名称不会影响广告投放的 k-匿名性。 | 要将广告素材视为 k-匿名性，IG 所有者网址、出价脚本网址、广告素材网址和广告尺寸的元组在过去时间段 (w) 内必须达到指定的阈值 (k)。k-匿名性状态会定期更新 (p)。 |
| Chrome 界面 | 提议提供大量 MVC、ORM 等框架所提供的“内部可见性”类型。例如，首先将选定的内部事件简单记录到“开发者工具”-->“应用”-->“应用”部分中的新面板上。 | 我们将在此处讨论该提案，欢迎您提供其他反馈。 |
| Chrome 界面 | 开发者工具 IG 联接不显示与优先级相关的元素。 | 我们已在此处解决此问题。 |
| API 改进 | 最好是允许广告素材广告服务器跟踪自己的事件。是否可对允许的跟踪网域列表进行配置？ | 我们在此处分享了一项提案，欢迎相关生态系统提供其他反馈。 |
| API 功能请求 | 能否扩展 PA API 以支持非实时出价媒体交易，以及维护广告投放和展示广告系列优化工具等关键用例？ | 我们将在此处讨论该问题，欢迎您提供其他反馈。 |
| 发布商竞价超时 | 发布商需要控制竞价时长，以防止错失展示机会，尤其是在依序选择广告的标头出价设置中。 | 我们深知让发布商能够精确控制广告竞价超时的重要性。我们正在积极探索如何实现全局竞价超时机制（可能在“auctionConfig”对象内），同时仔细考虑极端情况。此功能旨在为发布商优化展示填充率，我们将继续与社区合作，共同寻找最佳解决方案。我们将在此处讨论该问题，欢迎您提供其他反馈。 |
| API 改进 | 当前在 PA API 中采用 IG 的设计会导致元数据大小过大，这是因为 render网址 很长。测试人员想要一种压缩这些网址以提高效率的方法。 | 我们认识到优化 IG 元数据大小的重要性，尤其是对于效率敏感型广告竞价。我们认为，使用基于模板来压缩 render网址 的解决方案具有巨大的潜力。我们会仔细评估所提议的模板设计，并确保实施的所有解决方案都包含强大的滥用行为防范机制，以保持浏览器的稳定性。 在考虑到这些因素的前提下，与网络标准社区协作开发最佳方法仍然是首要任务。我们将在此处讨论该问题，欢迎您提供其他反馈。 |
| API 应用 | 处理原生广告格式的测试人员希望通过在一次调用中检索多个广告结果来优化 Privacy Sandbox 竞价流程，以减少网络负载并提高广告呈现速度。 | 我们深知，在 Privacy Sandbox 中呈现原生广告时存在性能方面的问题。我们致力于在效率与强有力的用户隐私保护措施之间取得平衡。虽然返回多个具有完整得分的广告会损害隐私，但我们正在积极探索优化竞价流程的方法。 我们致力于加强对原生广告格式的 PA API 支持，并研究替代机制，以在 Privacy Sandbox 的严格隐私保护限制下提高效率。我们将在此处讨论该问题，欢迎您提供其他反馈。 |
| API 应用 | 可以灵活地在 Privacy Sandbox 中对广告进行评分和排序，尤其是要代表优先级或私下交易市场规则。 | 我们了解需要在 Privacy Sandbox 中对广告评分和排序进行精细控制，尤其是在复杂的出价场景中。我们认可使用元组和数学函数提出的解决方案，可以在不牺牲用户隐私的情况下实现多维评分。虽然这些方法可能会给开发者带来复杂性，但它们能够提供必要的表现力。 我们致力于探索各种方法来简化这些流程（可能包括通过辅助函数或相关准则），确保以最佳方式利用 Privacy Sandbox 功能实现高级竞价逻辑。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| reportEvent() | 添加在包含广告素材的帧初始化后由浏览器触发的新预留事件（也许是自动信标）。 | 我们将在此处讨论此请求，欢迎您提供其他反馈。 |
| adCost | 允许细分 adCost。 | 每个成本值都是一个机会，可发送有限数量的信息以参与竞价。如果允许完整列表包含这些费用 N，则足以发送完整的用户标识符，从而实现跨网站跟踪。我们将在此处讨论这一点，欢迎您提供其他反馈。 |
| resolveToConfig | 是否应该从顶级继承 resolveToConfig 并在 browserSignals 中公开？ | 我们将在此处讨论此请求，欢迎您提供其他反馈。 |
| 更好的工具 | 有没有什么内容类似于 chrome://topics-internals，但适用于 PA API？ | 没有什么完全相同的。不过，丰富的开发者工具适用于 PA API。 |
| 标签 | Chrome 能否使用标签来识别这 20% 的 k-匿名性群体？ | 我们正在考虑此申请，并欢迎您提供生态系统的其他反馈。 |
| 文档 | Privacy Sandbox 竞价 Worklet 会成为标准 Worklet 类型吗？ | 由于独特的隐私和安全要求，这些 Worklet 与标准浏览器 Worklet 类型有很大不同，因此我们预计它们很快不会成为 HTML 规范中的标准 Worklet 类型。 我们致力于增强开发者资源，明确解释竞价 Worklet 的实现和执行环境，让 Privacy Sandbox 参与者更容易获取这些信息。我们已在此处进一步讨论了这一点。 |
| 自带服务器 (BYOS) 键值 (KV) 服务器 | 各方在 BYOS KV 服务设置中，通过 KV 服务查询，可以获知用户联接的多个 IG（来自同一所有者）。 | 当 KV 服务器在 TEE 中运行后，我们将不再能够做到这一点，我们可以确保它们能够遵循已发布的信任模型。 |
| userBiddingSignals | 更新部分“userBiddingSignals”，同时维护其他部分。 | 无需对 API 进行任何更改即可实现这一目标。 |
| API 应用 | 在 Privacy Sandbox 中跨多个 IG 实现频次上限（可能会使用 KV 服务器或修改后的“prevWinsMs”数据）。 | 我们深知，期望在 Privacy Sandbox 中实现高级频次上限功能。我们认识到，当前限制 IG 之间的数据共享可能会给实施这些策略带来挑战。 虽然 KV 服务器提供了一种具有适当隐私保护措施的潜在机制，但我们鼓励开发者在单个 IG 模型中探索解决方案。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
| API 应用 | 组件卖方（在 Privacy Sandbox 中参与嵌套竞价的卖方）需要了解顶级竞价超时，以优化自己的配置并避免不必要的延迟。 | 我们认识到，需要改进 Privacy Sandbox 中顶级销售人员和组件销售人员之间的超时协调。我们正在积极调查新增超时机制的添加情况（包括可能存在的整个竞价超时），并探索对组件竞价使用顶级超时的方法。我们的目标是提高 Privacy Sandbox 竞价流程中所有参与者的效率和可预测性。我们将在此处讨论此问题，欢迎您提供其他反馈。 |
Protected Audience 服务
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 可信执行环境 (TEE) | 在公有云中运行 TEE 的成本要高于本地广告技术数据中心？ | 我们的应对措施与前几季度类似： 我们当前的 TEE 安全模型受益于公有云实现的做法。特别是，目前基于硬件的 TEE 无法防范所有物理攻击。我们目前支持的公有云提供商 AWS 和 GCP 针对物理访问风险（包括员工）设计和实施了缓解措施。有关本地支持，请参阅下文的更多详细信息。 广告技术平台向我们提到，运行云服务比本地广告技术数据中心更贵。虽然我们无法评估这些陈述，但欢迎您就费用提供进一步反馈，并继续评估扩大 TEE 支持的范围。 |
| TEE | 对非公有云环境中的 TEE 的支持 | 我们的应对措施与前几个季度类似： 虽然我们在继续探索如何支持除公有云解决方案之外的其他方案，但目前没有支持本地 TEE 的计划。在这一阶段，考虑到 Privacy Sandbox 的安全性要求以及本地部署带来的重大挑战，我们认为继续扩展和改进基于云的部署（例如，在 AWS 之外支持 Google Cloud）对生态系统最有利。不过，我们欢迎您就隐私保护和安全限制提供进一步反馈，说明为何此类要求是必要且可行的。 |
| 其他云服务商 | 针对其他云服务提供商的支持 | 我们随时乐于接受其他云服务提供商的建议，但目前我们计划在强制执行 3PCD 时至少支持 GCP 和 AWS。如需了解详情，请参阅此铺垫消息。 |
| B&A 服务 API | Google 对 B&A Services API 的发展方向是怎样的？它在设备竞价中的优先级是高于还是低于 Chrome 浏览器 Protected Audience 竞价？ | 我们的应对措施与前几个季度的应对措施类似： 我们会一如既往地致力于遵循最新的 Protected Audience 设备端出价设计。人们提议使用 B&A 服务来探索可能的解决方案，以便在设备的计算能力或网速可能有限的用例中提供支持。 |
| 标准化 | B&A 服务尚未经过标准化流程。 | B&A 服务提案正处于标准化流程的一个阶段，欢迎其他参与者参与进来，为实现这一目标提供支持。 它从一项提案（基于之前的提案）开始，通过在 W3C 上进行广泛的公开讨论公开策划，感兴趣的开发者就可以开始试验该提案并提供反馈。这是网络功能开发的常见模式，详见此处的博文。 |
| KV 服务器 | 向买方的 KV 服务器提供完整网址，以进行内容定位 / 内容相关定位 / 网站定位。 | 我们将在此处讨论此请求，欢迎生态系统提供其他反馈。 |
| 文档 | GitHub 上有关“可信/强制执行的组件与可选”的文档与一些拥有自己的部署映像和基础架构的广告技术平台感到困惑。 | 我们希望改进关于“可信赖/强制组件与可选组件”的文档，也希望在需要优先处理此类工作时收到生态系统的反馈。 |
| API 改进 | KV 服务器调用的 HTTP 状态代码也应作为参数提供给 scoreAd() 函数使用。 | 我们正在评估该请求，欢迎生态系统提供其他反馈。 |
| 文档 | 详细了解如何在使用 UDF 执行时准确处理 JS 和 WASM 工作负载。 | 我们正在研究能否提供这些信息，欢迎您点击此处提供其他反馈。 |
| 文档 | 请求更新代码库名称。 | 我们已将该代码库重命名为“protected-auction-key-value-service”。 这与它所属的服务集合的术语相符，该代码库还包含其他代码库，例如 Protected Audience Services 讨论和 Protected 竞价服务文档代码库。 |
| 文档 | 移除了 bidding_auction_services_gcp_guide.md 中对 Cloud 调试程序 API 的引用。 | 我们更新了文档并移除了参考资料。 |
| API 应用 | KV 查找导致的延迟时间超过了 50 毫秒。用时将近 100 毫秒。 对于其他销售人员在哪些方面表现良好，你们有什么指导吗？您对如何衡量超时和时间有什么建议吗？ |
KV 服务器调用在脚本运行程序环境（即 Chrome 浏览器内的特殊受保护环境）内进行。它旨在保护这些脚本运行程序中的信息，防止任何非 API 访问。我们在此处提供了详细说明。 |
| API 应用 | KV 服务器在特定时间内响应是否有超时？ | 卖方可以在竞价配置中指定“perBuyerCumulativeTimeouts”字段。此超时包括获取可信出价信号所需的时间。 |
| 延迟时间 | Privacy Sandbox 团队如何努力解决延迟问题？ | 如需了解我们正在探索的将延迟时间保持在可接受限制范围内的策略，请参阅此处。 |
衡量数字广告
Attribution Reporting（及其他 API）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 手动优化广告系列 | ARA 不支持人工广告系列优化。 | 我们与广告技术平台讨论了这种情况，并展示了使用 ARA 来支持人工广告系列优化的方法。ARA 旨在支持广告技术平台自定义，并能够灵活地解决一系列广告技术用例。我们提供了一些建议，这些建议使用不同的灵活事件级配置，以及使用包含摘要报告的事件级报告，以减少噪声的影响并满足手动和自动优化需求。我们欢迎您就 ARA 配置的可自定义性和灵活性收到更多生态系统反馈。 |
| 转化类型 | Google 只允许添加 8 种转化类型，因此存在一定的限制。 | 我们实现了大部分的 灵活的事件级报告功能，使广告技术平台在报告期数量、归因报告数量以及可以使用的触发器数据位数方面具有更大的灵活性。广告技术平台可以选择一项配置，允许衡量多达 32 种不同的转化类型。 |
| 可汇总报告事件限制 | 对于预算有限的小型广告客户而言，每个可汇总报告中的转化事件至少要设为 20 个（以数字表示）无法采用。 | 每个可汇总报告所需的转化事件数量都没有最低数量要求。 此外，对于小型广告主，可以做出多项设计决策来优化可汇总报告，例如更改跟踪的关键结构 / 维度、测试不同级别的 epsilon、测试更长的批处理频率，以及测试不同衡量目标之间的不同贡献预算分配情况。小型广告技术平台也可以采用将衡量目标之间不同的贡献预算分配的方式进行实验，以结合使用事件级报告来减少噪声对报告的影响。 |
| 实时数据 | 不让 DSP 获取用于调整其出价策略并提升广告系列效果的实时数据（例如点击次数、会话数和转化次数），这违背了维护现有功能的承诺。 | 即使采用 ARA，点击次数和会话数仍会是实时数据，而转化始终是在事后发生，即使使用 3PC 也是如此。 |
| 未填写必填字段 | 未满足针对全方位灵活活动发布的要求：i) 币种字段，以及 ii) orderID / TransactionID 字段。 | 目前，我们不打算支持“币种”字段或“订单 ID”/“交易 ID”字段，因为目前的事件级报告中已经有一些可以满足这一要求的方法。我们欢迎您就这些字段提交更多反馈，并将重新考虑是否有其他用例需要这些信息。 使用 ARA 当前设计来衡量货币和订单 ID 类型信息的方式如下： 1.根据反馈，币种取决于用户的地理位置，可以将其添加到 source_event_id 中，以此来确定用户所使用的币种。 2.根据反馈，我们需要添加订单 ID 字段，以确保转化次数和价值不会被错误地重复统计，而您可以使用重复信息删除键来实现此目的。 |
| 隐私预算 | ARA 隐私预算限制了跨多个维度进行衡量的能力 | ARA 的设计方式允许广告技术平台自定义自己的 ARA 配置，以涵盖各种归因场景。在当前的 ARA 设计中，广告技术平台需要权衡利弊，即衡量哪些维度最为重要，以及噪声对其数据的影响。根据所衡量的维度的粒度向数据中添加噪声对于保护隐私至关重要。 对于生态系统的其他反馈，如果能够跨不同维度进行衡量，我们愿意接受这些反馈，但需要了解有此需求的具体应用场景。 |
| 更新规范 | 尽管 Google 表示其事件报告期已从固定报告期改为灵活的事件报告期，但 Google 的技术规范目前仍最短为一小时，但技术规范中并未反映这一点。 | 借助灵活的事件级报告功能，广告技术平台目前可以更改每个来源事件的归因报告数量、触发器数据的位数，以及报告期的数量/长度。对于事件级报告，ARA 仍然有至少 1 小时的报告期，这对保护隐私并防范某些类型的历史记录重建攻击至关重要。 由于摘要报告以汇总形式提供信息，因此广告技术平台可根据其使用情形选择即时接收可汇总报告，不会有任何延迟。 |
| API 设计 | 担心减少转化报告中的信息并添加噪声对生态系统的影响可能比 Google 更严重。 | Google 承诺 CMA 致力于设计和实施 Privacy Sandbox 提案，以确保不会因自述 Google 自己的业务而影响竞争，同时考虑到数字广告领域的竞争以及对各种规模的发布商和广告客户的影响。 |
| 归因更正 | ARA 不允许技术提供商控制和验证正确的归因。 | ARA 中有许多提供验证功能的解决方案： 1. 广告技术平台可以验证 ARA 行为是否符合其预期： - ARA 客户端代码是开源的。 - ARA 服务器端代码也是开源的，并且协调员可确保只有获得许可的汇总服务版本才能解密和处理可汇总报告。 2.Chrome 为广告技术平台提供了一个模拟库来验证归因行为，在该库中，广告技术平台可以测试 ARA 如何在模拟环境中执行归因。 3.ARA 支持多种调试信号，有助于验证是否未发生预期处理以及未发生的原因。 |
| （也曾在前几个季度报告） 噪音 |
反馈说噪声级别过高，影响了报告的实用性。 | 根据相同的反馈，我们与广告技术平台进行了交流，最终找到了可如何自定义 ARA 以更好地适应其用例的方法，即使有噪声也是如此。我们的开发者文档包含我们与广告技术平台讨论过的大多数设计决策和自定义设置。 ARA 的设计允许广告技术平台自定义自己的 ARA 配置，以涵盖各种归因场景。但广告技术平台需要权衡利弊，就要衡量哪些维度最为重要，以及噪声对其数据的影响。 我们愿意采纳生态系统中有关噪声影响的其他反馈，并且可以就 ARA 因素提供额外的指导，以改变噪声的影响。 |
| 跨网域归因 | 如何跟踪跨网域归因？ | 广告技术平台可以重定向到不同的报告网址来满足此用例的需要。我们欢迎您就 ARA 的这一设计方面收到更多生态系统反馈。 |
| API 改进 | 定期更改为 ARA 摘要报告注册归因时使用的缩放比例。 | 根据 GitHub 上的讨论，在汇总服务中处理多个扩缩因素似乎很可能会导致摘要报告增加大量噪声，而不是当前功能。 我们愿意接收更多反馈，了解在可汇总报告中是否需要调整系数，但我们希望权衡加重噪声的潜在权衡。我们还在评估未来的其他 ARA 功能是否也有助于解决这一用例。 |
| API 应用 | 有机会统一如何与所有参与者共享归因事件，这对 SSP、DSP 等有益。 | 我们计划与广告技术平台同步，以便更好地了解他们的反馈以及他们面临的任何限制。 |
| 测试流量 | 所有 Chrome 的模式 B 的测试流量是否都处于稳定状态？ | 是否纳入实验组不受 Chrome 设置（独立于）影响。 |
| 文档 | 支持对像素使用 ARA。 | 我们发布了相关信息，说明如何为此用例提供支持，欢迎生态系统提供其他反馈。 |
| API 应用 | 如果转化不是在最后一次联系时完成的，那么 ARA 可能无法归因于电子商务平台上的第三方卖家的正确来源。 | 公司可以使用过滤条件来防止出现错误归因（因为系统不会生成任何转化报表）。我们还在研究预归因过滤的提案，以帮助实现这一应用场景。 |
| 浏览器支持 | 其他浏览器是否支持 ARA？ | 我们欢迎其他浏览器采用 Privacy Sandbox API，并会继续专门花时间讨论我们在 W3C 大会上公开采用的方法。 我们明确表示互操作性是实施 ARA 的目标之一，ARA 的设计旨在让浏览器不依赖于浏览器，并为具有不同隐私保护立场的供应商提供灵活的供应商指定值。 其他浏览器正在自行选择是否能够跨网站标识符提供可行的替代方案。我们建议 Microsoft Edge 已表明将支持 ARA。 |
| API 应用 | 对于 registerAdBeacon/reportEvent（以及 navigation_start/commit 自动信标）进行 ARA 来源注册，预计的来源种类是什么？ | 这取决于这些信标是自动还是手动： - 预留。*（即自动）事件设为导航来源类型。 - 手动触发的事件属于“事件来源”类型。 |
| API 应用 | 每个来源最多 20 份可汇总报告的上限是否意味着每个来源事件？上限是全球性的还是每天的？是否有提高上限的计划？ | 每个来源 20 个可汇总报告的限制是一项全局限制，针对每个来源可以创建 20 个可汇总报告。该限制由浏览器设置，不可配置。此限制的目的是避免滥用 null 报告对真实归因报告的保护。我们已在此处进一步讨论了这一点。 |
| API 应用 | 支持使用 ARA 进行电子邮件营销。 | 目前，ARA 中不对此用例提供直接支持（如果您不控制电子邮件托管网站）。我们将在此处讨论这一点，欢迎您提供其他反馈。 |
| Epsilon | 何时确定汇总 API 的 epsilon 值？ | 广告技术平台可以配置当前的 epsilon 值，最高可达到 Privacy Sandbox 定义的预定阈值（目前为 64）。我们建议测试不同的 epsilon 值，确定您自己的用例的拐点并提供反馈。在更改 epsilon 值的范围之前，我们一定会提前与广告技术平台沟通。 |
| API 改进 | 支持一种用例，在该用例中，广告客户可以在 trigger_data 字段中插入标识符，以便与外部 CRM 数据进行匹配，从而验证转化的质量。 | 我们正在讨论该请求，欢迎点击此处提供其他反馈。 |
| API 应用 | 如何将重定向网址处理为目标网址。 | 广告技术平台可以执行以下任一操作： 1. 将最终的目标网址填入目标字段； 2. “目标网址”字段最多允许 3 个网址，让您可以在一个字段中输入多个网址。 这两个选项都需要知道最终的目标网址。我们在此处 对此进行了进一步讨论。 |
汇总服务
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 主要发现机制 | 请求密钥发现机制 | 我们有一个 关键发现方案，欢迎生态系统中的各方对此提案进行 反馈。 |
| API 应用 | 汇总服务可观测性的路线图 | 我们正在审核相关选项，以便提高可观测性，欢迎生态系统中的相关反馈（请点击此处）。 |
| API 改进 | 正在请求重新查询报告的权限。 | 汇总服务正在制定重新查询方案，广告技术平台可以针对每份报告拆分其 epsilon。这可能会增加每次查询的噪声，但可让广告技术平台重新查询并维护隐私。 |
| API 改进 | 希望能够将多个源关联到同一 AWS ID。 | Aggregation Service 现在允许在同一个云账号（GCP 或 AWS）上关联多个站点。这样一来，广告技术平台就可以使用相同的汇总服务隔区来处理来自多个网站和来自同一网站的多个源的报告。 |
| API 应用 | 当可汇总的批次失败时，不确定是否使用了预算，以及是否可以重新处理批次。如果汇总服务因重复报告而遇到预算错误，那么剩余报告将会丢失。如何最大限度地减少这种损失？ | 通常情况下，如果整个作业都失败，预算就不会被消耗。在极少数失败情况下，会消耗预算，广告技术平台可以请求恢复预算。 如果广告技术平台频繁遇到“预算用尽”错误导致的作业失败，则应确认自己的批处理策略。如需了解如何正确执行批处理操作以及避免报表重复和错误，请点击此处。 欢迎点击此处提供有关预算恢复的反馈。 |
| API 应用 | 如果将 Private Aggregation API 与此处介绍的触发器搭配使用，系统会为每次竞价生成可汇总报告。汇总服务的扩缩功能有哪些？ | 汇总服务本身并未对一个批次中的键或报告的数量设置上限，但由于所需的内存，因此目前不支持 10^14 个报告和 10^12 个键的规模。我们的 大小选择指南指出了我们根据预期负载和支持的 Cloud 虚拟机实例类型，经过测试和推荐，以达到最佳性能的范围。 |
| 数据处理 | 如果加密数据包含个人信息，那么向汇总服务提供加密数据的法律安排是什么？ 能否说明是否可以保证协调器不会访问加密的数据？ |
汇总服务不与协调者共享加密数据 / 用户数据。汇总服务使用协调器进行密钥管理和会计。如需了解协调者的一些详细信息，请点击此处。 对于会计处理，汇总服务仅会与 PBS 共享共享 ID 和报告来源，用于预算消耗。推出多网站后，我们将用网站取代来源。 请注意，汇总服务在 TEE 中运行，这是唯一能够解密客户端报告的位置。在 TEE 中运行的代码是开源的，并由外部各方审核（如此处所述）。 |
Private Aggregation API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| API 应用 | 组件销售人员能够将报告发送到 TEE 内的多个汇总服务器。 | 当前的 Private Aggregation API 状态不支持此功能。我们已在此处进一步讨论了此问题。 |
| 文档 | Google 在试验中使用的 epsilon 值是多少？ | 对于 Private Aggregation API，汇总服务查询中指定的 ≤ 值对应于 L1 贡献预算 2^16，每隔 10 分钟强制执行一次。此外，还有一个 2^20 的“后攻”L1 贡献预算，该预算将在 24 小时内强制执行。因此，从本质上讲，隐私参数的周期为 ≤ 以 10 分钟为单位，并且每 24 小时的值为 16 广告客户（而非 144 广告客户）。 汇总服务目前支持一系列 针对测试的 ear（最高可达 64 个），以便对不同汇总策略进行实验，并针对采用不同隐私汇总参数的其他 Private Aggation API 的效用提供反馈。随着来自测试人员的反馈信息，我们计划随着时间的推移重新审视允许的最大 epsilon 值，并添加能够更高效地利用隐私预算的功能。 |
限制隐秘跟踪
用户代理缩减/用户代理客户端提示
本季度未收到任何反馈。
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 解决方案 ID | Privacy Sandbox 需要更明确地指出，通常基于 IP 建立的分辨率 ID 对广告主来说是不可持续的。 | Privacy Sandbox 已明确说明，我们的目标是减少跨网站跟踪。我们的公开计划不仅仅是 Cookie，在 privacysandbox.com 和 GitHub 上都进行了公开宣传。我们努力减少跨网站跟踪，包括基于 IP 地址的跨网站跟踪。不过，是否主动启用跨网站跟踪最终还是由各个网站来决定。在监管合规审查日益严密的时代，各公司了解其服务提供商采用的做法是明智之举。 |
| Chromecast | IP 保护是否会影响 Chromecast 或其他 Chrome 设备？ | 目前没有为 Chromecast 设备应用 IP 保护的计划。 |
| IP 保护列表 | 是否会发布被认定为可能使用 IP 地址进行全网跨网站跟踪的第三方列表？ | 名单将在最终敲定后发布，如此处所述。 |
减少跳出跟踪
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 单点登录 (SSO) 豁免 | 跳出跟踪缓解措施 (BTM) 如何验证单点登录 (SSO) 用例是否豁免？ | Chrome 启发法将停用 BTM。如需了解详情，请点击此处。 |
| 弃用试用 | 是否为处于弃用第三方测试阶段的网站启用了 BTM？ | 不会，BTM 遵循弃用试用所产生的 Cookie 例外情况，如此处所述。 |
隐私预算
正如 GitHub 解释器和开发者网站中所述，Privacy Sandbox 提案已不再积极考虑隐私预算。
强化跨网站隐私边界
Related Website Set（以前称为 First-Party Set）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 功能请求 | 自动允许在整个 RWS 中访问 CHIP 和 / 或存储分区，而无需使用 Storage Access API，也无需用户互动。 | 我们正在考虑可能实现此功能的功能的益处和可行性。其中要考虑跨浏览器互操作性的潜在差距，RWS 利用 Storage Access API 解决了这个问题。目前没有其他浏览器支持所请求功能的等效功能。我们建议开发者在此处提交有关此问题的用例，以促进讨论。 |
| 移除不合规集 | 将不符合规定的集从存储库中移除的流程是怎样的？ | 我们正在努力确定一个流程，一旦有更新，我们将立即分享。 |
| 违规处置流程 | 关于 Google 在 RWS 违规处置流程中发挥的主观角色，则不够明确。 | 由于 RWS 是一个正在进行的项目，且我们不断收到新的提交内容，因此该流程的某些方面和我们的标准仍在不断完善。我们同意，在提交指南中完整说明提交要求非常重要，以后我们将为提交指南添加更多详细信息，以避免产生进一步的歧义和混淆。 我们的意图是让提交流程尽可能在技术上实现，这样我们就可以逐步减少人工干预，完全依赖于自动检查。诸如此类的公共关系需要更多的人际互动，因为它们包含我们意料之外的行为，但它们使我们能够发现更多自动化领域，并找到可以修正相关指南的方法，以避免以后出现此类问题。 |
| 分享数据 | 请求提供一项功能，让网域所有者表明他们希望第三方也在征得用户同意的情况下共享 RWS 数据。 | 请求的功能已通过 FedCM 和 Storage Access API 等 API 提供，这些 API 可在用户接受权限提示后允许访问经过身份验证的身份。我们欢迎 YouTube 生态系统针对他们认为不可能实现的任何特定应用场景提供反馈。 |
| 其他存储方法 | 保存在本地存储空间或会话存储空间中的信息是否也会解读为第三方 Cookie？ | 自 115 版起，本地存储空间、会话存储空间以及第三方使用的其他形式的非 Cookie 存储方式已在 Chrome 中进行了分区。如需了解更多详情，请参阅此博文。 |
| 关联的集限制 | 如果组织提交了超过 5 个域名，即使“关联的网站数量上限”为 5 个，单位会发生什么情况？ | 这些网域将通过 GitHub 流程接受，但浏览器 (Chrome) 只会将我们的 Storage Access API 自动授权规则应用于前 5 个网域，并忽略其余网域，如此处所述。 |
| find_robots_txt | find_robots_txt 检查不适用于重定向。 | 已提交修复方案以解决此问题，请点击此处。 |
| 用户手势 | 移除了对 accessStorage() 的用户手势要求。 | 此要求基于所有主流浏览器针对 requestStorageAccess API 实施的类似设计。我们诚邀您在此 GitHub 问题中提供其他反馈和用例，帮助我们确定该请求的优先顺序，并开展跨浏览器讨论。 |
| 用户手势 | Chrome 或操作系统重启后，是否需要通过用户手势来授予第三方存储空间访问权限？ | 可以，但欢迎生态系统提供进一步反馈，询问是否更改此行为，请点击此处。 |
Fenced Frames API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| adComponent | 缺乏文档记录，缺少将 AdComponent 与围栏框架结合使用的灵活性。 | 我们希望分享更多有关此用例的文档。此外，还要注意的是，使用 getNestedConfigs() 在围栏框架中支持广告组件，详见此处的规范。 |
| （在前几个季度也会有报告） Render adComponent |
请求获取有关如何在围栏框架中呈现 adComponents 的示例代码。 | 我们正努力在此处分享一些示例代码。 |
| 第三方广告验证 | 第三方广告验证在围栏框架环境中的作用需要更多详细信息，尤其是在内容安全/品牌保障方面。 | 目前，Fenced Frames 广告报告功能允许 DSP 将展示和竞价事件级数据发送给第三方广告验证程序，以进行呈现后品牌保障检查和结算。 |
| 展开式广告 | 请求支持展开式广告。 | 如果广告需要在具有相同宽高比的两种尺寸之间切换，并且两者之间没有功能差异（仅尺寸），则嵌入器可以使用第二个广告尺寸来调整围栏框架的大小，然后浏览器就会相应地缩放围栏框架元素。 |
| （前几个季度也会报告） 支持视频广告资源和原生广告资源 |
围栏框架是否支持视频广告资源和原生广告资源？ | 我们的响应与前几季度类似： PA API 使用依赖 iframe 的机制支持视频呈现。不过，我们尚未设计出可与围栏框架兼容的视频广告和原生广告呈现解决方案，这也是我们决定将围栏框架违规处置延迟至 2026 年的原因之一。这意味着，如果合作伙伴现在决定实施围栏框架，则将无法为该合作伙伴提供对视频和原生广告的支持。 |
| 咨询委员会 | 要求组建原生广告供应商顾问委员会，以确保围栏框架的实施符合业界标准。 | 2026 年之后，可在 PA API 中使用围栏框架。这段额外的时间让我们能够继续与业界合作，针对更广泛的关键用例设计和实现支持。我们之前已说明，我们将提前改进围栏框架，以达到对采用 PA API 的视频广告和原生广告的支持，提高其要求。我们会按照我们的承诺，与 CMA 互动并告知他们任何此类变化。在要求使用围栏框架之前，我们会继续听取生态系统的反馈。我们面向 W3C 的生态系统互动模型以及 IAB Tech Lab 等广告标准组织都利用此模式，让各种行业专家能够在需要相关设计之前就设计提供指导。 |
| （也曾在前几个季度报告） 不同平台之间的规模差异 |
报告称“围栏框架”中显示的内容大小在桌面设备和智能手机上看起来有所不同。 | 这是一个已知的 Chromium 问题，我们正在调查该问题。欢迎点击此处提供其他反馈。 |
| API 改进 | 围栏框架要求是否已推回 2025 年，以便 Privacy Sandbox 现在支持原生广告？ | 正如我们在不早 2026 年发布的有关围栏框架违规处置措施的公开公告中所指出的，我们了解到，为适应“围栏框架”这项规定做出了广泛的“重大努力”。当然，其中之一是原生广告，但不是唯一的因素。其目的是提供更多时间来确保生态系统做好充分准备，为关键应用场景（包括但不限于原生）提供支持。 |
Shared Storage API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 性能 | Worklet 之外的共享存储空间返回时间似乎取决于 Worklet 中的活动。 | 我们将在此处讨论此测试结果。 |
| 采用范围更广 | 共享存储空间应该是业界通用的标准，适用于所有浏览器。 | 我们欢迎并认可这些反馈。Chrome 将继续积极参与 W3C 论坛（包括 WICG），从而支持提案、征求反馈意见并推动客户采用该方案。 |
| 出价 Worklet | 是否有可能从 generateBid（已在 Worklet 中运行）中的共享存储空间中读取数据，以根据跨网站信息应用广告决策 / 业务逻辑（例如频次上限）并选择一部分广告？ | 不可以，无法从出价 Worklet 的共享存储空间读取数据。 |
CHIPS
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 分区容量 | 阐明了超出分区容量时的行为。 | 达到容量上限时，最早的 Cookie 会从最近最少访问的 Cookie 中移除，以释放内存，直至不再超过限制。开发者会在后续请求中看到更新后的 Cookie 标头。 |
| 第三方 iframe 访问 | 如果嵌入式第三方 iframe 内容打开新的标签页/窗口，指向同一第三方网站，则应能够访问与打开方相同的分区 Cookie。 | 我们正在讨论此使用场景，欢迎点击此处，从生态系统中获得其他反馈。 |
| Cookie 重复 | 如果有分区 Cookie 和未分区的 Cookie 同名，浏览器会决定发送哪个键值？ | 如果有两个名称相同的 Cookie（一个已分区，另一个不是），您将会获得两个 Cookie；遗憾的是，您无法区分哪个。您可以在此处查看关于此内容的 RFC 规范，其中说明了 Cookie 的发送顺序不应依赖于该顺序。 |
| 功能请求 | 选择启用源分区 Cookie。 | 我们正在考虑此申请，欢迎在此处提供生态系统的更多反馈。 |
FedCM
本季度未收到任何反馈。
打击垃圾内容和欺诈行为
Private State Token API（和其他 API）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| WebView | 私密状态令牌 (PST) 是否会保留在同一移动设备（配置文件）上的多个 WebView 中？ | 每个使用 WebView 的应用都具有不同的本地存储空间，这意味着 PST 颁发者无法在一个应用的网页视图中颁发令牌，之后又在另一个应用中允许兑换令牌。对于存储在 WebView 本地的其他形式的数据（例如 Cookie）也是如此。 WebView 中尚未全面提供 PST 功能。我们预计会在第二季度末提供有关此问题的最新消息。 |
| 新令牌类型 | 建议启用新令牌类型。 | 我们感谢此方案 以及对 PST 的应用和调整的持续探索，期待在 2024 年第 2 季度即将举行的反欺诈社区团体会议中详细了解此方案。 |
| 用户识别 | 如何防止系统根据用户使用的特定 PST 来识别用户？ | 目前，通过将一个网站上的兑换次数限制为两家发行商（无论该发行商是否提供令牌），可缓解这一问题。即使没有可用的令牌，您也需要将发行商计入限制，否则网站可能会遍历所有发行商，直到找到肯定匹配。 |
| 注册 | 使用 PST 需要注册多长时间？ | 在可预见的未来，仍然需要注册，详见此处。 |
| 对其他 Chromium 浏览器的支持 | 是否支持通过 Chrome 发卡机构注册代码库为其他基于 Chromium 的浏览器注册 PST 颁发者？ | Chrome 会提取密钥承诺，并通过一种名为“组件更新程序”的机制将其分发给 Chrome 客户端。随着其他浏览器更加全面地支持该 API，它们将需要建立一个流程，通过组件更新程序样式的方法或其他某种方法将密钥承诺提供给客户端。如需了解更多详细信息，请点击此处。 |