此页面由 Cloud Translation API 翻译。

反馈报告 - 2024 年第 1 季度
bookmark_border 使用集合让一切井井有条根据您的偏好保存内容并对其进行分类。

2024 年第 1 季度季度报告，总结了收到的有关 Privacy Sandbox 提案的生态系统反馈和 Chrome 的回复。

根据对 CMA 的承诺，Google 已同意每季度公开提供有关其 Privacy Sandbox 提案利益相关方互动流程的报告（请参阅承诺的第 12 段和第 17(c)(ii) 段）。这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈概览中列出的各种来源（包括但不限于 GitHub 问题、privacysandbox.com 上提供的反馈表单、与行业利益相关方举行的会议和 Web 标准论坛）收到的反馈而生成的。Chrome 欢迎从生态系统中获得反馈，并积极探索将所学知识融入设计决策的方法。

反馈主题的排名依据是每个 API 的普遍性。具体方法是汇总 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: 实时出价
加时赛: Origin 试用版
PAT API: Protected Audience API（以前称为 FLEDGE）
PatCG: “私密广告技术”社区群组
RP: 依赖方
RWS: 相关网站集（以前称为第一方集）
SSP: 供应方平台
TEE: 可信执行环境
UA: 用户代理字符串
UA-CH: 用户代理客户端提示
W3C: 万维网联盟
WIPB: 故意忽视 IP

一般反馈，无特定 API 或技术

反馈主题	摘要	Chrome 回复
治理	对 Privacy Sandbox 的任何治理更新进行公开意见征求的兴趣。	我们欢迎利益相关方就 Privacy Sandbox 的任何重大进展（包括 Privacy Sandbox 的未来治理）提供合理的反馈。
测试	除了当前的 1% Chrome 协助测试之外，3PCD 还有其他测试阶段。	我们不打算在 1 月初启用目前 1% 的 Chrome 流量之外，再提供由 Chrome 提供支持的测试。
Web to App	在 Web 和应用之间实现完全互操作性之前，不应在移动设备上进行 3PCD。	我们同意支持应用和网站互操作性，并已推出跨应用和跨网站归因衡量解决方案，并且正在探索网站到应用定位解决方案。不过，我们不打算推迟在移动网站上推出 3PCD。我们没有设定在 3PCD 结束时实现 100% 覆盖率的目标。相反，我们预计在 3PCD 时，Android 设备上跨应用和网站衡量的兼容性会相当高，并且随着用户更新手机，会逐渐提高。
浏览器的角色	Chrome 似乎在承担广告服务器或 SSP 的角色。	Chrome 不会充当广告服务器或 SSP。借助 PA API，Chrome 为广告服务器、SSP、DSP 和其他广告技术平台提供了一个容器，以便他们引入自己的出价和评分逻辑。
使用情形指南	关于 Privacy Sandbox API 将支持哪些用例的更清晰指南。	在 Privacy Sandbox 项目的早期阶段，开发者文档主要侧重于让开发者参与所有提案的讨论和反馈流程。这意味着，内容的结构通常围绕了解项目背后的动机和概念展开，然后详细介绍每个提案的早期开发和测试细节。这在开发提案时有助于建立真正的生态系统协作，但随着 API 的不断发展，我们迎来了新的开发者受众群体，他们主要是为了基于这些 API 进行构建，而不是为其底层开发做出贡献。我们最近更新了 Privacy Sandbox 开发者网站的导航栏，以使用场景为重点，采用了与 IAB Tech Lab 在其最近的 Privacy Sandbox 工作组报告中使用的类似分类。我们今后将继续采用这种基于用例的文档编写方法。
本地开发环境	如果 Cookie 为 SameSite=Secure，并且后端由 CDN 提供前端，我们如何继续在 http://localhost 上本地开发和测试前端？	我们正在此处讨论此问题，欢迎生态系统提供更多反馈。
3PCD 缓解措施	是否有程序化方法可以知道 3PC 是否已被屏蔽或启用了启发词语？	在 Chrome 中，通过功能检测和在 iframe 中调用的 document.hasStorageAccess，开发者可以了解 iframe 中的来源是否有权访问 3PC。
视频测试	目前无法在 Privacy Sandbox 中测试视频广告。	Chrome 发布了一份讨论和演示文档，介绍了目前可通过 PA API 实现视频的几种可能方式（请参阅 GitHub 上的演示文档库中的 242 和 254）。请注意，这些示例代码并非供广告技术平台直接采用，而是用于概念验证，以及演示可通过 PA API 支持 VAST 视频呈现的技术。在讨论过程中，我们还发现，虽然目前已经可以进行视频呈现，但 Chrome 可以进行一些更改，以简化使用 PA API 的实现。例如，我们已经计划根据有关第三方广告验证器品牌保障用例的反馈来解决宏替换（点此了解详情）方面的更新问题，这也将解决视频广告用例中的反馈问题，买方希望了解在呈现时应使用哪些卖方宏。到目前为止，大多数讨论都特别侧重于呈现 VAST 视频广告。原生广告的呈现可以采用相同的方法，而且在许多方面更为简单。原生广告目前似乎没有视频广告受关注度高，但这只是广告技术行业的优先级问题，而不是实现方面的任何技术障碍。
非广告效果衡量	3PCD 可能会影响与广告无关的受众群体衡量解决方案。	衡量 API 不要求应用场景与广告相关。虽然 ARA 更侧重于典型的广告历程，但不公开汇总具有通用性。这两个构建块可用于处理各种衡量活动。
内容创作者	Privacy Sandbox 的设计旨在鼓励内容创作者在 YouTube 上创作更多内容，而不是在自己的网站上创作。	Privacy Sandbox 计划旨在保护用户在开放且自由的互联网环境中的活动隐私。我们知道，发布商依靠广告制作内容并尽可能广泛地分发这些内容。广告主可帮助用户发现他们可能需要的新产品或优惠。借助 Privacy Sandbox 功能，各种类型的网站（包括与内容创作者合作的网站）都可以根据用户与不同方的互动活动向用户展示实用的广告，而不会向这些方透露用户的身份。
时间轴更清晰	更清晰、更详细的 Privacy Sandbox 技术发布时间表。	Privacy Sandbox API 文档包含 API 状态和可用性页面。这些页面列出了即将推出的功能及其时间表（例如 PA API、 ARA）。您可以点击此处集中查看这些状态。
机器学习	只有在 3PCD 超过 1% 后，广告技术平台才能正确训练机器学习模型。	将 3PCD 扩展到更多浏览器进行测试并不能保证这些 API 的使用量会增加，而这正是广告技术平台为了进一步训练机器学习模型而寻求的目标。如果广告技术平台不希望通过扩大生态系统使用范围来进一步训练机器学习模型，那么就没有理由扩大 3PCD 的使用范围，因为希望利用更多流量训练模型的广告技术平台目前无需增加 3PCD 即可实现这一目标。这样一来，Chrome 在 3PCD 上就不会在 Standstill 结束前显示向前移动。
不受支持的使用情形	目前不考虑自助 DSP 用例。	有多个自助式 DSP 会定期就这些 API 提供公开反馈。其中一些提供定期公开反馈的 DSP 还将自己列为了测试人员。此外，Chrome 还积极参与视频和第三方广告服务器等典型的自助式 DSP 主题讨论。近期每周 PA API 调用已涵盖这些主题。
源试用	针对希望更积极地逐步扩大 3PCD 测试覆盖面的网站，申请 OT。	Chrome 目前正在开发第一方 OT，以便来源选择启用 3PC 逐步淘汰行为。注册此试用计划并部署令牌的顶级源将被阻止使用 3PC，就像用户设备启用了跟踪保护一样。在与 CMA 协商后，我们计划最终逐步淘汰第三方来源，在此之前，此 OT 将为网站提供一个宝贵的机会，让其对第三方来源的长期替代方案进行更广泛的测试。我们仍在努力确定 OT 的最终发布时间表。
IAB 技术实验室报告	从 IAB Tech Lab 报告中收到的有关 Privacy Sandbox 的反馈。	您可以点击此处详细了解我们对 IAB Tech Lab 报告的回复。我们还在其中承认，“该报告提出了有关分散文档、商业要求、第三方审核、行业认证、可扩展性、透明度和未来治理的问题，我们将与生态系统合作，并相应地更新我们的公开常见问题解答。” 我们之前曾解决文档碎片化问题。我们在此处介绍了“数据保证”下的商业要求，部分 Google Ads 产品已分享了其方法。如需了解第三方审核，请参阅此处的“算法完整性保证”部分。关于认证，我们希望这些机构继续认证产品（包括其使用的技术），而不是认证技术本身。关于可伸缩性，我们仍会接受开发者提供的数据来证明存在问题。在透明度和治理方面，我们将继续在 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 Enterprise 用户，因此周末带有实验标签的流量所占的比例预计会更高。在不同的数据片段（例如地理位置、日期和平台）中看到不同的流量百分比是正常现象，这与我们在 Chrome 数据中看到的情况一致。
手动重新启用 3PC	在强制执行 3PCD 后，网站能否知道有多少用户（%）手动重新启用了 Cookie？	如果用户遇到中断问题，则可以通过“用户绕过”功能在网站一级重新启用 3PC 访问权限。您还可以通过其他措施（例如 Storage Access API）重新启用 3PC。网站可以通过一些技术措施（例如 hasStorageAccess()）检测 3PC 是处于启用状态还是停用状态。不过，Chrome 不会提供任何方式供网站了解重新启用的原因。
跟踪保护	Chrome 的跟踪保护界面功能将可供使用多久？	在弃用 3PC 后，地址栏中的跟踪保护界面预计仍会保留。
（也已在上一季度报告）跨浏览器支持	采用 Privacy Sandbox API 的其他浏览器供应商。	其他浏览器供应商（例如 Apple、Mozilla 和 Microsoft）也积极参与公开论坛，在其中讨论隐私权原则和基于浏览器的方法。我们很高兴看到，在最近的 W3C 年度 TPAC 会议和正在进行的 W3C PATCG 论坛等论坛上，大家进行了协作讨论，并看到了融合迹象。例如，Microsoft Edge 最近宣布了一项计划，旨在“最大限度地提高与 PA API 的语法兼容性”和 ARA，同时还为开发者提供其他功能。
针对 3PCD 后不兼容的嵌入的回退选项	提供 API 钩子，用于检测第三方 iframe / 嵌入内容是否符合 3PCD 要求。	我们正在此处讨论该请求，欢迎生态系统提供更多反馈。
测试	在受管理的 Chrome 实例中请求其他标志，以暂时关闭自定义行为。	我们正在考虑为托管的 Chrome 实例提供此标志，如果此标志有用，我们欢迎生态系统提供更多反馈。

注册和认证

反馈主题	摘要	Chrome 回复
认证验证	Google 如何确保认证的真实性？	所有注册者在使用 API 时都必须保留该认证文件。Google 会验证该文件是否已就位且语法是否正确，但不会验证广告技术平台在保证语言方面的行为。
Private Aggregation API 注册流程	是否有方法可以检查 Private Aggregation API 注册状态？	注册成功验证后，注册支持团队会通过电子邮件通知所有已获批准的注册者。如果注册者在此过程中有任何疑问，可以与支持团队联系（在提交注册表单后，系统会将他们转接到该团队）。支持团队会回复并解答您的问题，并提供所需的任何其他指导。

展示相关内容和广告

主题

反馈主题	摘要	Chrome 回复
（也已在上一季度报告）分类器时间表和文档	应提供某种机制来审核分类，或者至少在分类模式如何确定类别方面提供更多透明度。	我们的回复与上个季度保持不变： “网站分类错误可能会使主题信号的整体实用性略有降低，但与任何其他网站相比，被错误分类的特定网站受到的影响并不会更大或更小。这是因为，网站的情境信息始终可用于其网站上的竞价，即使出现错误分类，也能提供与正确主题类似的信息。欢迎您点击此处就此主题提供反馈。”
Google Ad Manager	Google Ad Manager 已嵌入到大多数网站中，与在较少网站上植入代码的竞争对手相比，它将拥有更多有关用户兴趣的信息。	观察要求旨在确保 Topics API 不会导致用户数据被分享给 Topics API 所取代的技术（包括第三方 Cookie）涉及的实体之外的更多实体。其他行业解决方案（例如预出价）可与数以万计的网站搭配使用，并让市场参与者能够通过其技术调用 Topics API。此外，值得注意的是，每周最多 5 个热门主题的限制可能会产生均衡效应，因为在许多网站上展示产品/服务的市场参与者可能能够使用 3PC 了解超过 5 个主题，但只能了解 5 个。
（也已在上一季度报告中报告）对不同类型利益相关方的实用性	担心网站创造的价值和价值分配会因其流量水平或内容专业程度而异。	我们知道，与一般兴趣领域相比，专业网站更有可能提供更精细的主题。不过，并非所有专门网站都提供具有商业价值的主题。此外，这种动态反映的是现状，与 Chrome 中 3PC 的支持终止完全无关。此外，在当前环境中，某些网站在基于 3PC 的广告相关性系统中提供的价值高于其他网站。此外，专门网站中的主题之间可以互惠互利，因为各种各样的广告客户可以在各种各样的主题中投放广告系列，而出价逻辑可以观察各种各样的主题中的价值。
主机名与完整网址	与完整网址相比，根据网站的主机名进行分类是否足够有效，并且能否降低隐私风险？	除了主机名之外，我们还考虑过使用信息网址或网页标题，但最终确定，潜在的好处不如用户隐私和安全风险大。用户隐私风险示例包括将网址或网页标题中包含的敏感信息归类为用户的主题。
主题作为信号	请求有关如何将主题与其他信号结合使用以及哪些其他信号可能很有用的指南。	广告技术解决方案可以将所有可用工具（例如机器学习和可保护隐私的 API 提供的可保护隐私的信号）与情境数据、广告素材数据和第一方数据相结合，从而取得理想的成效。如需有关此方面的进一步指导，请点击此处。

Protected Audience API（以前称为 FLEDGE）

反馈主题	摘要	Chrome 回复
测试流量	测试人员报告 PA API 竞价的出价响应量较低。	1. 出价密度与 PA API 生态系统参与度相关，我们预计在整个 2024 年及之后，PA API 生态系统参与度将继续增加。广告系列预算的分配方式最终由广告客户、其代理机构和技术提供商决定。我们预计，一些生态系统参与者可能会推迟投资于各种“无 Cookie”解决方案（包括 PA API），直到 3PCD 之后。届时，我们预计他们可能会增加对此类解决方案的广告系列预算分配。 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 Community Group (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 竞价，卖方都必须在 AuctionConfig 的 interestGroupBuyers 字段中明确列出买方。之所以做出此决定，是因为生态系统反馈了以下信息：卖方与某些买方签订了合同，但与其他买方并未签订，因此需要明确控制要将哪些买方纳入竞价。欢迎在 GitHub 上进一步讨论。
广告尺寸	无法根据 adsize 和 adSlotSize 进行预过滤。	我们正在努力添加此功能，如需了解详情，请点击此处。
支持 Instagram 排除性定位	支持否定 Instagram 定位条件的 API：仅在用户不属于某个 Instagram 时展示广告。	此 GitHub 问题提出了一种实现排除式定位的替代方法，其中浏览器会直接告知广告服务器应针对特定广告请求应用哪些排除式定位规则。虽然这似乎是一个不错的方法，但我们调查发现，我们研究过的所有此类方法版本都能够让服务器唯一地识别用户。
数字服务法案	发布商如何使用围栏框架，同时阻止包含受《数字服务法案》约束的信息的响应呈现？	与任何新技术一样，每家公司都有责任确保其使用 Privacy Sandbox 符合法律规定；Google 无法向他人提供法律建议。我们已针对每个 API 发布了详尽的技术文档，这些文档应可作为进行必要法律评估的基础。在 2026 年之前，PA API 中不需要使用围栏框架，这让利益相关方有更多时间确保其使用此技术符合所有相关法律法规。
文档	updateAdInterestGroups() 是否暂时性？	我们尚未宣布弃用 updateAdInterestGroup 的任何计划。未来，我们可能会针对其他 IG 更新机制采用类似的隐私保护措施，例如使用 IP 地址作为代理，并在更新发生之前添加一些延迟时间。
为非 DSP 提供买方元数据和逻辑所有权支持	请求一种可充当 DSP 代理的方法。	我们已收到来自非 DSP 细分的反馈，并正在考虑此请求。我们欢迎生态系统提供更多反馈。
报告	请求在“不公开汇总”报告中为信号分桶 / 值添加自定义处理脚本功能。	我们已知晓此问题，并将这项功能请求列入待进一步研究的队列。欢迎生态系统中的各方在此处提供更多反馈。
文档	有没有链接可以查看广告客户和（委托的）所有者网域需要设置的所有响应标头？	我们计划更新相关文档以阐明这一点，并欢迎生态系统提供更多反馈。
多塔出价	请求通过架构 / 框图说明在 PA API 上下文中如何构想多塔方法的工作流程（训练和推理）。	感谢您的反馈。我们有一些关于此主题的演示文稿，预计会据此编写更多文档。
排除性定位	Privacy Sandbox 能够保护敏感受众群体和未成年人免受不当广告（例如赌博广告）的侵害。	PA API 不会考虑所展示广告的内容。这由使用 PA 的广告技术平台开发者控制。通常，发布商及其广告技术提供商可以使用网页的情境信息以及发布商规则集来屏蔽 Protected Audience 竞价中的广告素材。这反映了我们对生态系统目前应对这些挑战的方式的理解。对于买方而言，排除 Instagram 账号定位功能对于某些合规性用例也可能很有用。
API 设计	Google 反对这种做法，希望广告技术平台使用 Universal 出价函数（这会增加延迟时间），而不是在不同的 IG 中使用不同的 biddingLogic网址（这在允许范围内）。	在讨论竞价延迟时间的过程中，我们强调过，在买方的所有 IG 中重复使用同一脚本会加快该买方的出价速度。如需详细了解，请参阅此处，以及我们关于缩短 PA API 竞价延迟时间的其他建议。
基于账号的营销	PA API 不适用于基于账号的营销用例。	如果生态系统认为某些特定用例无法实现，欢迎向我们提供反馈。我们还鼓励生态系统参与者通过我们的公共 GitHub 代码库或每周通话继续讨论。
A/B 测试	在 GAM 中为发布商配置 PA API 后，目前必须为所有广告资源启用该 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，以便他们通过 Google 发布商代码 (GPT) API 指定其组件竞价配置。如需了解详情，请点击此处。如果 SSP 通过此 API 提供组件竞价配置，则这些配置将包含在相应广告机会的组件竞价列表中。GAM 不会对所包含的组件竞价施加任何限制。只要发布商允许 SSP 在其网页上执行必要的代码，任何希望运行组件竞价的 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 月份，我们发布了演示视频，介绍了插播式视频广告在 PA 竞价中的运作方式，并详细介绍了其他方法。我们还发现，生态系统参与者开始就与其集成的合作伙伴的视频呈现方式提出建议，例如 GAM 就视频兼容的 render网址构建提出的建议或完整的端到端流程。此外，我们会聆听生态系统就我们可以做出哪些更改来提高采用率的反馈，其中一个此类更改详见 GitHub。我们会继续积极与生态系统互动，以找出我们可能遇到的任何其他采用障碍，并及时加以解决。
（也已在上一季度报告）数据处理政策	IGs / 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 用户和其他利益相关方的负面影响。我们正在审核此请求，欢迎您在此提供更多反馈。
（也报告在前几个季度） modelingSignals	除了只能编码展示和点击信息的 modelingSignals 之外，还可以请求新字段。	我们已在此处针对此反馈做出回复，并提出了抗辩方案。我们正在积极与业界人士互动，了解他们对我们提案的看法，并目前正在权衡该提案对业界带来的好处与对 Chrome 用户和其他利益相关方的影响。
reportWin() 中的其他位	在 3PCD 之前，reportWin() 中的位数上限为 12，现在增加了一些位数。	我们目前正在探索支持此用例的方法。由于我们还在寻找有助于确保我们制定长期隐私保护计划的方法，因此需要一些时间。
竞价设计	针对单次竞价的请求，会返回呈现网址及其对应的得分。	我们曾考虑过共享来自单次 PA 竞价的多个 render网址及其各自的得分，但出于隐私保护方面的考虑，我们并未实施此做法。我们理解您希望避免在单个网页上向用户多次展示同一广告，欢迎您在 GitHub 上进一步讨论。
reportWin	在 reportWin() 函数中记录任意字段。	目前，在整个测试期间，我们已经在这样做了。在 Chrome 停止支持 3PC 后，API 的 forDebuggingOnly 版本将进行迁移，以启用此处指定的缩减采样调试功能。
组件卖家	具有独立的机制来统计自己的展示次数和其他事件，而不必完全依赖于广告技术平台的报告。	我们会将此功能请求加入待进一步研究的队列。我们预计无法在 Chrome 协助进行的测试期间解决此问题。
每次点击费用结算	在 PA API 中实现每次点击费用结算。	我们正在此处考虑此请求，目前将其视为请求提供有关如何使用当前 API Surface 实现此功能的建议。
browserSignals	将 incomingBidInSellerCurrency 添加到报告卖方 browserSignals 规范中。	我们正在审核此请求，欢迎您在此提供更多反馈。
为非 DSP 提供买方元数据和逻辑所有权支持	该 API 的当前设计可能会导致产品级再定位广告系列发生重大变化，广告系列可能需要迁移到同时充当 DSP 和 DCO 提供商的平台。	我们正在讨论此问题，欢迎您在此提供更多反馈。
为非 DSP 提供买方元数据和逻辑所有权支持	分享 DSP 不是 IG 所有者的示例。	我们理解，非出价方希望使用 IG 的某些功能，但不希望使用其他功能。我们正在积极评估用于解决这些用例的方案，欢迎您点击此处提供更多反馈。
超时控件	发布商应能够指定能够参与的 IG 数量以及顶级超时 / 全局超时。	我们理解，您希望增强顶级卖家和组件卖家之间的超时控制和可见性，我们正在考虑此请求。
多广告尺寸	针对多广告尺寸用例的 PA API 支持。	我们正在考虑此请求，欢迎生态系统提供更多反馈。
文档	是否有受 k-anon 影响的 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 或 Fenced Frame 中时，广告呈现流程可能会开始。在 reportWin() 执行完毕且广告开始呈现后，系统会提取向 sendReportTo() 提供的网址。
（也已在上一季度报告中提及） A/B 测试支持	请求 PA API A/B 测试支持。	我们正在此处讨论此请求，欢迎您提供更多反馈。
流量整形	Google 提出的方案是通过 KV 服务器管理所需的决策制定，但由于卖方无法与其后端进行交互，因此很难调整流量。	如GitHub 问题中所述，公开各个 DSP 是否存在 IG 可能会导致用户身份识别问题。我们在问题中建议了其他替代方案，并愿意接受进一步的建议。
流量整形	缓存机制会增加一层复杂性，并会阻止 DSP 了解其要出价的流量的真实形态。	缓存机制只是作为一种建议提供的。广告技术平台可以选择使用适合其用例的建议，欢迎您点击此处进行进一步讨论。
标签	Chrome 应在向买方和卖方可信服务器发出请求时，将标签作为参数共享。	此请求似乎合理，因为它似乎与负责任地利用 Instagram 数据的目标大致一致。不过，我们正在考虑该要求，并会在内部审核后做出决定。随着讨论的进展，我们会就此事宜向公众提供最新动态。
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 函数专用于在 Privacy Auction (PA) 系统中生成事件级胜出报告。如果在 PA 竞价期间所有出价都被拒绝，则由于未确定胜出方，因此这些函数不应被调用。 Chrome 的近期更新可能可以解释传递给 forDebuggingOnly.reportAdAuctionLoss() 的网址未显示在开发者工具“网络”面板中的情况。我们建议您使用 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 的替代方法。这种方法会在标头中传输 perBuyerSignal，整个标头响应的大小上限为 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 值为零或任何负数，则表示相应广告不符合竞价胜出的条件。例如，此机制可用于滤除未超越内容相关定位候选广告的基于兴趣群体的定位广告。虽然值为零的 topLevelWinningBid 可能表示内容相关竞价胜出，但 PA API 规范承认，其他因素也可能导致此结果。
模式 A/B 测试	阐明了模式 B 和模式 A 流量选择以及停用提示。	模式 A 和模式 B 的包含条件相同。我们的目标是，只要组支持 Privacy Sandbox API 和标记方法，就能够代表正常的 Chrome 流量，因此某些客户端配置不兼容。出于实验目的，请务必仅将标记的流量与其他标记的流量进行比较。处于模式 B 的用户已启用跟踪保护功能，因此会收到有关该功能的通知。
API 改进	“lifetimeMs”可以作为 joinAdInterestGroup 调用中的直接属性包含，还是作为单独的参数进行管理？	我们正在仔细考虑 Web 开发社区针对 PA API 提案中的“joinAdInterestGroup”功能提供的反馈。一个关键讨论点是重点关注管理 IG 生命周期的最佳方法。我们正在评估为“lifetimeMs”参数提供单独实参的好处，因为这有助于提高灵活性和适应性，以便未来对规范进行增强。我们正在讨论此问题，欢迎您提供更多反馈。
API 应用	由于与低熵浏览器 ID 发生冲突，PA API 框架中的假负例率可能会增加。	Chrome 团队正在积极参与 PA API 框架的持续优化。感谢您就浏览器 ID 冲突可能导致的假负例率进行讨论。我们正在仔细评估这些反馈，并会努力确保更新后的分析全面反映所有相关因素。我们致力于提供能够在实现预期隐私保护效果的同时保持准确性和可靠性的解决方案。我们正在此处讨论此问题，欢迎您提供更多反馈。
API 应用	在 k-匿名性系统中，是否必须使用低熵浏览器标识符来防止客户端重复提交同一对象的“Join”请求？	我们感谢大家就如何在实现 k-匿名性系统时使用浏览器标识符进行持续讨论。我们理解，您对此类标识符的潜在隐私影响存有疑虑。虽然我们在最初的实现中采用了低熵标识符作为防滥用机制，但我们正在积极探索其他技术（例如匿名计数令牌），以便在保护系统完整性的同时优先保护用户隐私。我们致力于寻找可平衡负责任的数据使用与强大隐私保护措施的解决方案，并欢迎与研究界继续对话。我们在此处讨论了这个问题，欢迎您提供更多反馈。
API 应用	AMP (Accelerated Mobile Pages) 是否支持 PA API。	AMP 目前不支持原生 PA API。如果 AMP 支持是高优先级事项，我们欢迎生态系统提供更多反馈。
API 改进	考虑从 k-匿名性检查中移除该类型。	我们正在仔细考虑有关可能优化 k-匿名性请求结构的反馈。我们理解您建议整合参数并可能统一类型以简化流程。我们的目标是确保效率和可维护性，我们会在不断开发隐私保护解决方案的过程中评估所有方案。我们正在讨论此问题，欢迎您提供更多反馈。
Chrome 界面	请求提供一种机制，让技术水平较低的用户能够轻松查看和管理他们所属的 IG，包括可能的网站级停用控件。	我们深知提供易于理解和管理 IG 的工具非常重要。我们仔细考虑了各种方法，发现按加入的网站来识别 IG 能最妥善地平衡清晰度和隐私保护。目前，您可以在 Chrome 的设置中全局管理 IG。我们一直在探索如何进一步提升这方面的用户体验。我们正在此处讨论此问题，欢迎您提供更多反馈。
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 中的 Instagram 相关的潜在内存问题和界面清晰度问题。	我们理解您对在开发者工具中显示 IG 存有疑虑。虽然当前视图会反映历史跟踪的所有 IG 事件，但我们也认识到，更清楚地了解存储的 IG 的当前状态具有重要价值。我们将探索优化和潜在的界面改进，以增强开发者洞见。关于内存管理，IG 实现旨在防止内存泄露，但我们会持续监控和优化资源使用情况。我们正在此处讨论此问题，欢迎您提供更多反馈。
文档	原始发帖者在尝试直接在“joinAdInterestGroup”函数的“sizeGroup”字段中使用命名广告尺寸时遇到错误。他们想知道这是预期行为吗？	我们认识到简化“joinAdInterestGroup”函数中的广告配置非常重要。我们正在积极解决此限制，并计划在未来的更新中启用此功能。这项增强功能符合我们致力于为开发者提供灵活高效的广告管理工具的承诺。我们正在此处讨论此问题，欢迎您提供更多反馈。
Chrome 协助测试标签	请求在 sendReportTo 中提供有关模式 A 与模式 B 的直接数据和确切标签，以便我们能够持续跟踪实验。	我们正在此处讨论此请求，欢迎您提供更多反馈
文档	向卖方的可信服务器发出的请求中是否包含卖方的域名（用于验证目的）？	我们承认，最初在 Protected Audience KV Server API 文档中漏掉了主机名参数。我们希望向开发者保证，卖方的域名会自动包含在向卖方的受信任服务器发出的请求中。此功能对于完善的广告验证流程至关重要。我们已更新相关文档以解决此疏忽问题，并将继续优先为开发者社区提供清晰透明的信息。我们正在此处讨论此问题，欢迎您提供更多反馈。
API 应用	为了生成报告，在广告展示跟踪调用中添加 IG 名称的可能方法。	我们致力于平衡强大报告机制的需求与用户隐私保护的基本原则。在广告展示次数跟踪中包含 Instagram 名称时，我们会采用 k-匿名性保护措施来防止识别个人身份。我们将继续在这些隐私限制范围内探索创新的报告解决方案。我们正在此处讨论此问题，欢迎您提供更多反馈。
API 功能	请求买方可信服务器接收客户端提示 HTTP 标头。	我们会在此处跟踪此功能请求。
API 应用	鉴于委托文件决定了浏览器的 IG 会员行为，该文件是否应要求加载“Access-Control-Allow-Origin”标头？	我们致力于遵循 Web 安全最佳实践。针对委托文件使用“Access-Control-Allow-Origin”标头的要求可确保与 CORS 原则保持一致，并防止敏感信息无意中泄露。我们正在探索如何在保持强大的安全状况的同时优化此流程。我们正在此处讨论此问题，欢迎您提供更多反馈。
API 应用	让广告服务器能够在 PA API 框架中对广告素材进行个性化设置。	我们认识到广告服务器在广告素材个性化方面发挥着重要作用。我们正在积极探索各种解决方案，以便在 PA API 中赋予广告服务器强大功能，例如可将出价和广告素材选择逻辑相结合的“联合 IG”模型。我们的目标是在实现强大的广告素材功能和保护用户隐私之间取得平衡。欢迎您点击此处，就如何改进 API 以满足所有利益相关方的需求，与我们进一步合作并提供反馈。
隐私问题	是否提供备用标识符（例如在内容相关出价请求中使用 RampID、ID5 等 ID 可能会促进跨网站数据收集，从而破坏 PA API 的隐私保护目标。	我们知道跨网站标识符与 PA API 的隐私保护目标之间存在潜在的矛盾。虽然发布商可以选择共享此类标识符，但 PA API 的设计根本目的是将广告选择与跨网站跟踪的需求分离。我们致力于打造以隐私保护为中心的广告生态系统，并鼓励开发者优先采用 PA API 方法。我们正在此处讨论此问题，欢迎您提供更多反馈。
缓存	有没有方法可以防止在多个竞价中重复使用出价脚本？	我们确认在 PA API 框架中观察到出价脚本的缓存行为。虽然支持标准 HTTP 缓存机制，但由于设备暂停行为和出价执行器的设计，脚本可能会在竞价中重复使用。该团队正在研究相关解决方案，以便买方更好地控制脚本缓存，从而有效管理其出价策略。我们正在此处讨论此问题，欢迎您提供更多反馈。
API 应用	集中报告 DSP 在所有 IG 中的出价活动，同时保护用户隐私。	在设计 PA API 时，我们会优先考虑用户隐私。虽然由于跨网站跟踪风险，无法直接报告各个出价事件，但我们提供了共享存储空间和私有汇总等机制。借助这些信息，DSP 能够以保护用户隐私的方式，获得有关出价活动的汇总数据洞见。
API 应用	与通过 forDebuggingOnly.reportAdAuctionWin() 注册提取相比，reportResult() 中的 sendReportTo() 提取仅在 94% 的时间内发生。	虽然它们可能没有相同的时间安排，但可以同时提取这两个网址。在某些情况下，组件卖方的 Worklet 会被处置，需要重新加载，然后才能运行 reportResult() 函数。不过，提取评分逻辑所需的时间和重新加载 worklet 所需的时间都不会影响 reportResult() 的 50 毫秒超时。请注意，在需要重新加载 worklet 的情况下，Chrome 将使用缓存标头来定义其提取行为。您可以点击此处详细了解 PA 竞价的各个阶段。
k-匿名性	请求确认 interestGroup 的名称不会影响广告投放的 k-匿名性。	要将广告素材视为 k-匿名广告素材，IG 所有者网址、出价脚本网址、广告素材网址和广告尺寸的元组在过去一段时间 (w) 内必须达到指定阈值 (k)。k-匿名性状态会定期更新 (p)。
Chrome 界面	提案：提供许多 MVC、ORM 等框架提供的“内部可见性”类型。例如，先在“开发者工具”->“应用”->“应用”部分中将所选内部事件简单地记录到新面板	我们正在此处讨论该提案，欢迎您提供更多反馈。
Chrome 界面	通过开发者工具加入 IG 后，系统不会显示与优先级相关的元素。	我们已在此处解决此问题。
API 改进	最好允许广告素材广告服务器跟踪自己的事件。是否可以配置允许的跟踪网域列表？	我们已在此处分享了一项提案，欢迎生态系统提供更多反馈。
API 功能请求	PA API 能否扩展以支持非 RTB 媒体交易并保留广告投放和 DCO 等关键用例？	我们正在此处讨论此问题，欢迎您提供更多反馈。
发布商竞价超时	发布商需要控制竞价时长，以防止错失展示机会，尤其是在以顺序方式选择广告的标头出价设置中。	我们深知，让发布商能够精细控制广告竞价超时时间非常重要。我们正在积极探索如何在“auctionConfig”对象中实现全局竞价超时机制，同时仔细考虑极端情况。此功能旨在优化发布商的展示次数填充率，我们将继续与社区合作，寻找最佳解决方案。我们正在此处讨论此问题，欢迎您提供更多反馈。
API 改进	PA API 中 IG 的当前设计会导致元数据大小过大，因为 render网址很长。测试人员希望找到一种压缩这些网址的方法，以提高效率。	我们深知优化 Instagram 元数据大小的重要性，尤其是对于对效率敏感的广告竞价。我们认为，基于模板的 render网址压缩解决方案具有巨大潜力。我们会仔细评估所提交的模板设计，并确保任何已实现的解决方案都包含强大的防滥用机制，以维护浏览器稳定性。我们仍会优先考虑与 Web 标准社区合作，以制定出最优方案。我们正在此处讨论此问题，欢迎您提供更多反馈。
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 安全模型受益于公共云实现实践。具体而言，目前基于硬件的 TEE 无法防范所有物理攻击。我们现有的受支持的公有云提供商 AWS 和 Google Cloud 设计并实施了一些措施来缓解物理访问风险，包括来自员工的风险。请参阅以下有关本地支持的详细信息。广告技术平台曾向我们提及，运行云服务的费用高于在本地广告技术平台数据中心运行的费用。虽然我们无法评估这些声明，但欢迎您就费用提供更多反馈，我们会继续评估扩大 TEE 支持的方案。
TEEs	支持非公共云环境中的 TEE	我们的回复与上几个季度类似：虽然我们会继续探索支持基于公有云的解决方案以外的选项，但目前没有计划支持本地 TEE。鉴于 Privacy Sandbox 安全要求以及本地部署所带来的重大挑战，我们认为，继续扩大和改进基于云的部署（例如，除了 AWS 之外还支持 Google Cloud）对整个生态系统最为有利。不过，我们欢迎您就以下问题提供更多反馈：鉴于隐私和安全限制，为什么这种要求是必要且可行的。
其他云服务商	针对其他云服务提供商的支持服务	我们一如既往地欢迎您就其他云服务提供商提出建议，但在强制执行 3PCD 时，我们计划至少支持 Google Cloud 和 AWS。如需了解详情，请参阅此说明文档。
B&A 服务 API	Google 对 B&A Services API 的方向是什么？在设备竞价中，它在优先级上会高于还是低于 Chrome 浏览器 Protected Audience？	我们的回复与上几个季度类似：我们仍致力于当前的 Protected Audience 设备端出价设计。我们提出了 B&A 服务，目的是探索可能的解决方案，以支持设备计算能力或网络速度可能受限的一小部分用例。
标准化	B&A 服务尚未完成标准化流程。	B&A 服务提案目前正处于标准化流程的一个阶段，我们欢迎更多人参与，以实现这一目标。该提案（基于之前的提案）从 W3C 的广泛公开讨论开始公开孵化，感兴趣的开发者可以开始对其进行实验并提供反馈。这是 Web 功能开发的常见模式，例如此处的博文中所述。
KV 服务器	向买方的 KV 服务器公开完整网址，以进行内容 / 内容相关 / 网站定位。	我们正在此处讨论此请求，欢迎生态系统提供更多反馈。
文档	GitHub 上关于“可信/强制性组件与可选组件”的文档会让一些拥有自己的部署映像和基础架构的广告技术平台感到困惑。	我们希望改进“可信/强制性组件与可选组件”的文档，并希望了解生态系统是否需要优先完成此类工作。
API 改进	KV 服务器调用的 HTTP 状态代码也应作为参数提供给 scoreAd() 函数。	我们正在评估此请求，欢迎生态系统提供更多反馈。
文档	详细说明了如何通过 UDF 执行来精确处理 JS 和 WASM 工作负载。	我们正在考虑提供此类信息，欢迎您在此处提供更多反馈。
文档	请求更新代码库名称。	我们已将该代码库重命名为“protected-auction-key-value-service”。这与其所属服务集合中的术语保持一致，该集合中还有其他代码库，例如 Protected Audience 服务讨论和 Protected Auction 服务文档代码库。
文档	移除了 bidding_auction_services_gcp_guide.md 中对 Cloud 调试程序 API 的引用。	我们已更新文档并移除了相应引用。
API 应用	KV 查找引入的延迟时间超过 50 毫秒。需要将近 100 毫秒的时间。您能否就其他卖家取得良好成效的做法提供一些指导？您对如何衡量超时和时间有何建议？	KV 服务器调用会在脚本运行程序上下文（即 Chrome 浏览器内的特殊受保护环境）中进行。其目的是保护这些脚本运行程序中的信息，使其免受任何非 API 访问。如需了解详情，请点击此处。
API 应用	KV 服务器是否有在特定时间内响应的超时限制？	卖方可以在竞价配置中指定“perBuyerCumulativeTimeouts”字段。此超时时间包括提取可信出价信号所需的时间。
延迟时间	Privacy Sandbox 团队如何解决延迟问题？	如需了解我们正在探索的用于将延迟时间控制在可接受范围内的策略，请点击此处。

衡量数字广告的效果

Attribution Reporting API（及其他 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 为广告技术平台提供了 Simulation Library，以验证归因行为，广告技术平台可以在模拟环境中测试 ARA 如何进行归因。 3. ARA 支持多种调试信号，可帮助验证预期处理是否可能未发生以及原因。
（也报告在上一季度）噪声	反馈：噪声水平过高，影响了报告的实用性。	我们与一些广告技术平台沟通时也收到了同样的反馈，并确定了一些方法，可让 ARA 更好地适应其用例，即使存在噪声也是如此。我们的开发者文档包含我们与广告技术平台讨论的大多数设计决策和自定义设置。 ARA 的设计旨在让广告技术平台能够自定义自己的 ARA 配置，以涵盖各种归因场景。不过，广告技术平台需要考虑哪些维度对其而言最关键，以及噪声对其数据的影响。我们乐于听取有关噪声影响的更多生态系统反馈，并可以就可用于改变噪声影响的 ARA 杠杆提供更多指导。
跨网域归因	如何跟踪跨网域归因？	广告技术平台可以重定向到不同的报告网址来解决此用例。我们欢迎针对 ARA 的这一设计方面提供更多生态系统反馈。
API 改进	定期更改为 ARA 摘要报告注册归因时使用的放大系数。	根据 GitHub 上的讨论，与当前功能相比，在汇总服务中处理多个放大因子似乎会导致摘要报告中添加的噪声量增加。我们乐意就是否需要在可汇总报告中使用放大因子提供更多反馈，但想提醒您，增加噪声量是可能的代价。我们还在评估未来的其他 ARA 功能是否也能帮助解决此用例。
API 应用	有机会统一与所有参与者共享归因事件的方式，这对 SSP、DSP 等都有益。	我们计划与广告技术平台同步，以便更好地了解他们的反馈和遇到的任何限制。
测试流量	所有 Chrome 的模式 B 测试流量是否稳定？	是否加入实验组不受 Chrome 设置的影响（与 Chrome 设置无关）。
文档	为 Pixel 支持 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	Aggregate API 的 epsilon 值何时确定？	广告技术平台可以配置当前的 epsilon 值，但不得超过 Privacy Sandbox 定义的预设阈值（目前为 64）。我们建议您测试不同的 epsilon 值，并针对您自己的用例确定拐点，然后提供反馈。在更改 epsilon 值范围之前，我们会务必提前与广告技术平台沟通。
API 改进	支持以下用例：广告客户可以将标识符插入 trigger_data 字段，以与外部 CRM 数据进行匹配，从而让广告客户能够验证转化质量。	我们正在讨论该请求，欢迎您点击此处提供更多反馈。
API 应用	如何将重定向网址作为目标网址进行处理。	广告技术平台可以执行以下任一操作： 1. 在“目标网址”字段中输入最终目标网址； 2. “目标网址”字段最多可容纳 3 个网址，因此您可以将多个网址放入该字段。这两种方式都需要知道最终目标网址。我们在此处对此进行了进一步讨论。

汇总服务

反馈主题	摘要	Chrome 回复
密钥发现机制	请求密钥发现机制	我们提出了一项键发现方案，欢迎生态系统对该方案提供反馈。
API 应用	汇总服务可观察性路线图	我们正在审核各种选项，以支持更好的可观测性，欢迎生态系统中的各方人士点击此处提供反馈。
API 改进	请求能够重新查询报告。	汇总服务正在研究一项请求提案，以便广告技术平台可以按报告拆分其 epsilon。这可能会导致每个查询产生更多噪声，但会允许广告技术平台重新查询并保护隐私。
API 改进	希望能够将多个来源与同一 AWS ID 相关联。	现在，汇总服务支持在同一云账号（Google Cloud 或 AWS）中添加多个网站。这样一来，广告技术平台就可以使用相同的汇总服务 Enclave 来处理来自多个网站的报告，以及来自同一网站的多个来源的报告。
API 应用	可汇总批次失败时，不确定预算是否已用尽，以及是否可以重新处理批次。当汇总服务遇到重复报告的预算错误时，其余报告将丢失。如何最大限度地减少这种损失？	在典型情况下，如果整个作业失败，则不会消耗预算。如果极少数情况下作业失败并消耗了预算，广告技术平台可以请求恢复预算。如果广告技术平台经常遇到作业失败并出现预算耗尽错误，则应确认其批处理策略。如需了解如何正确批量处理并避免报告重复和出错，请点击此处。欢迎您点击此处提供有关预算恢复的反馈。
API 应用	将 Private Aggregation API 与此处所述的触发器搭配使用，可为每次竞价生成可汇总的报告。汇总服务的扩缩功能有哪些？	汇总服务本身对批处理中的键或报告数量没有上限，但由于需要的内存量，目前不支持 10^14 个报告和 10^12 个键的规模。我们的容量调整指南列出了我们经过测试的范围，并根据预期负载和受支持的云虚拟机实例类型提供了最佳性能建议。
数据处理	如果加密数据包含个人信息，向汇总服务提供加密数据的法律规定是什么？您能否说明协调者是否一定不会访问加密数据？	汇总服务不会与协调者共享加密数据 / 用户数据。汇总服务使用协调者进行密钥管理和记账。如需详细了解协调程序，请点击此处。对于会计核算，汇总服务仅与 PBS 共享共享 ID 和报告来源，以便用于预算消耗。推出多网站功能后，我们会将“origin”替换为“site”。请注意，汇总服务在 TEE 中运行，这是唯一可以解密来自客户端的报告的位置。在 TEE 中运行的代码是开源的，并由外部人员进行审核（如此处所述）。

Private Aggregation API

反馈主题	摘要	Chrome 回复
API 应用	组件卖方能够向 TEE 内的多个汇总服务器发送报告。	当前的 Private Aggregation API 状态不支持此功能。我们在此处进一步讨论了此问题。
文档	Google 的实验中使用的 epsilon 值是多少？	对于 Private Aggregation API，汇总服务查询中指定的 ε 值对应于每 10 分钟滚动强制执行的 2^16 的 L1 贡献预算。此外，还有一个 2^20 的“后备”L1 贡献预算，系统会按 24 小时滚动方式强制执行此预算。因此，从本质上讲，隐私权参数为 10 分钟滚动期的 ε，为 24 小时滚动期的 16ε（而非 144ε）。汇总服务目前支持一系列 ε 用于测试（最多 64），以便尝试不同的汇总策略，并针对具有不同隐私权参数的系统（适用于 Private Aggregation 和其他 API）提供实用性反馈。随着时间的推移，我们计划根据测试人员的反馈来重新审视允许的最大 epsilon 值，并添加可更高效使用隐私预算的功能。

限制隐蔽跟踪

用户代理缩减/用户代理客户端提示

本季度未收到任何反馈。

IP 保护（以前称为 Gnatcatcher）

反馈主题	摘要	Chrome 回复
解决方案 ID	Privacy Sandbox 需要更大声地指出，通常基于 IP 地址构建的解决方案 ID 对广告客户而言不可持续。	Privacy Sandbox 已明确指出，我们的目标是减少跨网站跟踪。我们的公共计划不仅限于 Cookie，并会在 privacysandbox.com 和 GitHub 上公布。我们会努力减少跨网站跟踪，包括基于 IP 地址的跟踪。不过，最终还是由各个网站决定是否主动启用跨网站跟踪。在监管合规性受到越来越严格审查的时代，各个公司都应谨慎地了解其服务提供商采用的做法。
Chromecast	IP 保护功能会影响 Chromecast 或其他 Chrome 设备吗？	目前，我们没有将 IP 保护功能应用于 Chromecast 设备的计划。
IP 地址保护名单	是否会公布被认定为可能使用 IP 地址进行网站范围内的跨网站跟踪的第三方名单？	该名单将在确定后发布，详情请参阅此处。

跳出跟踪缓解措施

反馈主题	摘要	Chrome 回复
单点登录 (SSO) 豁免	如何使用弹跳率跟踪缓解措施 (BTM) 验证 SSO 用例是否符合豁免条件？	Chrome 启发词语搜索功能会停用 BTM。如需了解详情，请参阅说明。
弃用试用	是否已为 3PC 弃用试用中的网站启用 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 是一项持续性项目，我们会不断收到新的提交内容，因此流程的各个方面和我们的评选标准仍在不断完善中。我们确实同意，提交指南应全面阐明提交要求，这一点非常重要。今后，我们会在提交指南中添加更多详细信息，以避免进一步的模糊和混淆。我们的目标是让提交流程尽可能技术化，以便逐步减少人工参与，完全依赖自动化检查。像这样的 PR 需要更多人为互动，因为其中包含我们未预料到的行为，但这让我们能够发现更多可自动化处理的方面，并改进我们的准则，以避免日后出现此类问题。
分享数据	请求添加一项功能，让网域所有者能够指明他们希望第三方在征得用户同意的情况下也分享 RWS 数据。	用户接受权限提示后，可以通过 FedCM 和 Storage Access API 等 API 访问经过身份验证的身份，从而使用请求的功能。我们欢迎生态系统就他们认为无法实现的任何特定用例提供反馈。
其他存储方法	保存在本地存储空间或会话存储空间中的信息也会被视为第三方 Cookie 吗？	从版本 115 开始，Chrome 会对在第三方环境中使用的本地存储空间、会话存储空间和其他形式的非 Cookie 存储空间进行分区。如需了解详情，请参阅这篇博文。
关联的集合数量上限	如果组织提交的网域超过 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 与 Fenced Frames 搭配使用的文档，并且缺乏灵活性。	我们希望分享更多与此用例相关的文档。此外，Fenced Frames 支持使用 getNestedConfigs() 添加广告组件，如规范中此处所述。
（也已在上一季度报告）渲染 adComponent	请求有关如何在 Fenced Frame 中呈现 adComponent 的示例代码。	我们正在努力在此处分享一些示例代码。
第三方广告验证	第三方广告验证在围栏框架中的角色需要更详细的说明，尤其是在内容相关性/品牌保障方面。	目前，围栏框广告报告确实允许 DSP 向第三方广告验证机构发送展示和竞价事件级数据，以便进行渲染后品牌保障检查和结算。
展开式广告	请求支持展开式广告。	如果广告需要在两个宽高比相同的尺寸之间切换，并且这两个尺寸没有功能差异（仅尺寸不同），则嵌入程序可以使用第二个广告尺寸调整 Fenced Frame 的大小，浏览器会相应地缩放 Fenced Frame 元素。
（也已在前几个季度报告过）支持视频广告资源和原生广告资源	围栏框是否支持视频和原生广告资源？	我们的回复与上几个季度类似： PA API 支持使用依赖于 iframe 的机制进行视频渲染。不过，我们尚未设计出与围栏框兼容的视频和原生广告呈现解决方案，这也是我们决定将围栏框强制执行时间推迟到 2026 年的原因之一。这意味着，如果合作伙伴现在决定强制执行围栏框，则该合作伙伴将无法支持视频广告和原生广告。
顾问委员会	请求创建一个由原生广告供应商组成的顾问委员会，以确保围栏框架实现符合行业标准。	在 2026 年之前，PA API 中无需使用围栏帧。我们将利用这段时间继续与业界合作，设计和实现对更多关键用例的支持。我们之前曾表示，我们将在 PA API 要求之前改进围栏帧，以便继续支持视频广告和原生广告。根据我们的承诺，我们会与 CMA 沟通并告知其任何此类变更，并且在要求使用围栏框架之前，我们会继续收集生态系统的反馈。我们在 W3C 和 IAB Tech Lab 等广告标准组织中采用的生态系统互动模式，让各种行业专家都能在需要之前指导设计。
（也已在上一季度报告中提及）不同平台的尺寸差异	报告在桌面设备和智能手机上，Fenced Frame 中显示的内容大小看起来不同。	这是 Chromium 的一个已知问题，我们正在对其进行调查。欢迎您在此处提供更多反馈。
API 改进	是否将围栏框架要求推迟到了 2025 年，以便 Privacy Sandbox 现在支持原生广告？	正如我们在公开宣布不会早于 2026 年开始强制执行围栏框政策时所指出的那样，我们了解到，许多开发者都在“不遗余力地努力适应”围栏框政策。当然，其中一个是原生广告，但这并不是唯一的因素。目的是留出更多时间，确保生态系统能够支持关键用例（包括但不限于原生用例）。

Shared Storage API

反馈主题	摘要	Chrome 回复
性能	在 worklet 之外的共享存储空间返回时间似乎取决于 worklet 中的活动。	您可以在此处了解此测试结果。
更广泛的采用	共享存储空间应是适用于所有浏览器的业界标准。	我们欢迎并感谢您提供此反馈。Chrome 将继续积极参与 W3C 论坛（包括 WICG），为该提案提供支持、征求反馈并推动其采用。
出价 Worklet	是否可以从 generateBid（已在 worklet 中运行）内的共享存储空间中读取数据，以便根据跨网站信息应用广告决策 / 业务逻辑（例如频次上限）并选择部分广告？	不可以，无法从出价工作流内共享存储空间中读取数据。

CHIPS

反馈主题	摘要	Chrome 回复
分区容量	阐明超出分区容量时的行为。	达到容量上限后，系统会从最近最少访问的 Cookie 中逐出最早的 Cookie 以释放内存，直到不再超出上限。开发者会在后续请求中看到更新后的 Cookie 标头。
第三方 iFrame 访问权限	嵌入的第三方 iFrame 内容打开指向同一第三方网站的新标签页/窗口时，应能访问与打开者相同的分区 Cookie。	我们正在讨论此用例，欢迎生态系统在此处提供更多反馈。
Cookie 重复	如果存在同名的分区 Cookie 和非分区 Cookie，浏览器会决定发送哪个键值对？	如果您有两个名称相同的 Cookie（一个已分区，一个未分区），则会同时获得这两个 Cookie，但遗憾的是，您无法区分这两个 Cookie。有关此 RFC 规范可参阅此处，其中说明不应依赖 Cookie 发送的顺序。
功能请求	选择启用来源分区 Cookie。	我们正在考虑此请求，欢迎生态系统中的其他用户在此提供更多反馈。

FedCM