与 Privacy Sandbox 相关性和衡量 API 相关的常见问题解答。
Topics 与卖方定义的受众群体 (SDA) 有何不同？
Topics 和 SDA 可提供互补的信息类型，并且均由发布商的控制。我们不认为它们会相互竞争。相反，它们可以并行使用或在不同的环境中运行，以最大限度地提高购买机会。买方在程序化地评估展示次数时会考虑和使用多种信号，我们预计 Topics 就是其中之一。过去，卖方不会在公开市场竞价中包含细分受众群，因此系统可能会使用 Topics。而是在与广告客户、代理机构或 DSP 达成的交易中，将受众群体设置为可供程序化购买。在这些情况下，卖方和买方是有意就 SDA 进行交易。如果在这些情况下使用 Topics，它可能适用于以下一种或多种情况：
- 销售人员通过 Topics 增强其受众群体定义
- 买方使用 Topics 作为信号，决定出价金额
- 买方使用 Topics 验证 SDA 是否准确
Protected Audience 是否会让 Google 控制受众群体创建？
不需要。网站可以继续在 Privacy Sandbox 内外构建自己的受众群体。当网站在 Privacy Sandbox 中构建受众群体时，网站所有者或所选代理会确定谁可以构建受众群体，这些受众群体有哪些，如何更新这些受众群体，如何对这些受众群体出价，以及是否从受众群体中移除用户。
Protected Audience 是否支持发布商创建的兴趣群体？
是的。我们知道，如今发布商担心会让受众群体参与基于 OpenRTB 的竞价，因为担心数据泄露。发布商现在可以在 Protected Audience 中构建受众群体，不向出价方提供该发布商用户的跨网站视图。我们很高兴能够继续探索发布商如何利用 Protected Audience 减少的数据泄露环境。
如何在 Protected Audience 竞价中强制执行广告质量规则？
在 Protected Audience 竞价中，您可以通过多种方式强制执行广告质量规则。其中每个规则都与当前 SSP 强制执行广告质量规则的方式类似。一种方法是让具有未知广告素材的竞价触发该广告素材进入队列等待扫描。我们收到了一项反馈，即 SSP 希望为此用例提供更好的支持，并且正在设计一种机制，以创建 renderUrls Feed，SSP 可以在带外审核该 Feed，然后将信息存储在其键值对服务器中。另一种方法是要求预注册广告。与上一种情况一样，扫描广告素材后，结果便可绑定到键值对服务器。之后，当买方使用该广告素材出价（通过广告素材 ID 指示，格式可能与 OpenRTB 相同）时，卖方的评分逻辑可以在键值对服务器中执行查询，并决定如何进行相应的评分。
Protected Audience 是否支持视频广告？
是的。VAST 网址可以传入和传出 Protected Audience。当 VAST 网址显示后，卖方技术可以协调如何对买方的 VAST 网址进行封装，然后再将其发送到播放器。在要求迁移到围栏框架并进一步加强用户隐私保护的要求之前，我们预计生态系统将参与设计讨论，其中肯定会包含视频。
Protected Audience 是否支持原生广告？
是的。可将 JSON 网址传入和传出 Protected Audience。当 JSON 网址显示时，卖方技术可以协调他们如何在最终的 JSON 传递给渲染代码之前添加任何所需事件。在要求迁移到围栏框架以进一步加强用户隐私保护的要求之前（不早于 2026 年），我们预计生态系统将参与其中可能包括原生广告的设计讨论。
Protected Audience 广告呈现是否会妨碍创新？
不能。广告呈现一直依赖于浏览器技术。这一点不会改变。或许，这个问题只是针对未来计划要求将围栏框架与 Protected Audience 结合使用的计划。这些计划“未来”的原因之一是，我们希望围栏框架技术能够在广告呈现方面支持生态系统创新和差异化优势。感兴趣的开发者和公司有时间研究一下围栏框架的方向，包括如何支持原生广告方法。
Protected Audience 是否允许使用传统竞价中现有的复杂投放节奏和出价评估方法？
Protected Audience 提供了一个实时选项，让买方能够了解广告系列的投放节奏和预算。从广告资源的角度来看，卖方可向买方提供竞价信号，包括页面内容以及任何其他方面的信息。如果卖方选择发送内容相关出价请求，买方也可以通过该机制了解广告资源，然后（通过 perBuyerSignals）为自己提供可在其 Protected Audience 出价生成操作中使用的情境信号。尝鲜者已经在将机器学习系统连接到 Protected Audience。我们知道，调整这些系统以适应 Protected Audience 环境中的出价需要花费一些时间，但请务必注意，您可以进行调优，并且已经在进行调优。
OpenRTB 标准适用于 Protected Audience 吗？
是的。IAB Tech Lab 正通过一个服务良好的代表性 DSP 和 SSP 团队，将这项工作付诸实施。未来似乎将采用 OpenRTB 协议的某些部分作为 Protected Audience 竞价中的通信标准，而且我们知道尝鲜者已经在采用这种方式。
Protected Audience 是否要求公司维护两个单独的架构来投放广告？
不需要。Protected Audience 不需要维护两个单独的架构。架构选择由您自行决定。随着在线广告多年来的发展，为在线广告提供支持的系统也变得更加复杂。为用户提供更私密的互联网环境会增加复杂性，并需要耗费大量精力。广告技术公司可以选择维护两个单独的架构，也可以将 Protected Audience 构建到与传统竞价相结合的架构中。
一旦有更多广告技术公司支持 Protected Audience，传统竞价会发生什么变化？
我们预计内容相关竞价仍将相关的原因多种多样，包括交易、非第一方受众群体定位广告系列以及许多其他情境相关情形。当不存在兴趣群体或 Protected Audience 中的出价未能达到底价或不符合广告质量规则时，这些受众群体仍然具有价值。
Protected Audience 竞价是否与生态系统供应路径优化 (SPO) 举措相悖，以减少广告主与发布商之间的中间方总数和/或给定广告机会的重复情况？
不会。如果买方与发布商建立直接集成，Protected Audience 中的胜出广告最多会传递两个卖方实体（例如供应方平台 [SSP] 和发布商广告服务器），但可以不传递，最小会传递任何实体。
使用多个中间方复制同一请求仍然是发布方的选择。Protected Audience 不应以某种方式影响这种影响。
Protected Audience 竞价不会泄露跨网站用户数据，而是发生在当今的服务器到服务器的实时系统之外。有人可能会说这重复了广告请求。若要从技术层面获得具有可证明性的隐私保护，您需要做出一些取舍。但是，从长远来看，有可能在不使用传统的服务器端竞价的情况下，生态系统决定使用 Protected Audience。这种选择可能会带来更加优化的供应路径。
Protected Audience 是否会降低现有流量调整基础架构的价值？
据我们所知，每秒查询数方面发生了一些变化：许多 SSP 使用跨网站 ID 这一功能来确定是否向 DSP 发送请求。因此，减少跨网站 ID 会影响现有的“根据流量情况调整投放速度”技术。无论发布商是否要运行 Protected Audience 竞价，情况都是如此。
我们探索了使用许多 SSP 的流量调整功能，并找到了缓存和基于上下文的过滤等解决方案。随着时间的推移，我们希望开发者能够利用不公开汇总来进一步理解 DSP 出价偏好设置并进行相应过滤。
最终，一些围绕跨网站标识符构建的旧基础架构将不再有用。
Protected Audience 竞价所产生的新请求会限制 SSP 容量吗？
一些 SSP 向我们反馈，从集成的角度来看，容量不是问题，也不是 SSP 价值主张的重要组成部分。对于关注竞价过程中新调用的 SSP，我们知道有些公司已经在帮助 SSP 解决容量问题，并且正在希望扩展这些服务来支持 Protected Audience。如果您希望我们为您与其中某个公司建立关联，请告知我们。
当浏览器中有竞争资源时，如何在 Protected Audience 中确定优先级？
Protected Audience 通常遵循构建控制机制的标准范例，让卖方可以决定出价方可以消耗多少时间和资源；构建工具让买方能够决定如何最有效地利用提供给他们的资源。这些控件和工具目前已经推出，但在买方和卖方采用后，它们将充分发挥它们的优势。此外，Chrome 会继续在基础架构方面进行各种改进，以提升竞价速度（例如 crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev7.com/139）。
Protected Audience 如何解决延迟问题？
过去，在 Protected Audience 之前，在服务器上发生的实时出价需要卖方指定严格的买方响应超时，以确保延迟时间在内。我们为 Protected Audience 添加了各种非常相似的卖方指定的超时控件（请参阅 perBuyerCumulativeTimeouts、perBuyerTimeouts 和 sellerTimeout 的文档），以实现同样的目标，即控制延迟时间。这些控制措施还可以鼓励竞价参与者优化其逻辑，以确保最高效地利用资源来支持广告技术生态系统和高质量的用户体验。
Chrome 还会继续致力于改进竞价速度（例如 crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev.com/1197323）。我们诚邀您就这项延迟工作的两个方面提供反馈：买方和卖方认为有用的其他工具，以及 Chrome 工程师应调查观察到的瓶颈问题报告。
如果存在出价和竞价服务 (B&A)，那么针对设备端 Protected Audience 构建应用是不是白费力气？
不需要。对于广告技术应用场景，设备端就足够了。当广告技术平台希望对出价计算资源投入超出浏览器允许的范围时，出价和竞价服务是可选的横向扩展解决方案。设备端开发是一项很好的投资，因为即使开发者稍后决定参与出价和竞价服务环境，大多数工作都可以重复使用。所构建的大部分管道和基础架构将继续以类似的方式运行。
Protected Audience 基于云的可信执行环境 (TEE) 要求是否会促使企业使用 Google Cloud？
Privacy Sandbox 设计的 API 能够提供可靠的隐私性和安全性，并且我们尚未做出任何设计决策来让 Google Cloud 受益。我们对云服务商的支持从 AWS 开始，因为我们承认有许多广告技术提供商选择 Amazon。除了 AWS 和 Google Cloud 之外，我们预计未来也会支持其他云提供商，并且愿意接受其他云提供商的建议。如果您担心延迟，可以借助云提供的位置选项，缩短与其他云服务提供商之间的距离。
Privacy Sandbox 是否允许可信执行环境 (TEE) 在非公有云数据中心运行？
可审核的可信执行环境 (TEE) 是我们隐私和安全模型的一部分。得益于严格的安全措施，我们从公有云提供商提供的 TEE 开始。需要明确的是，在短期内需要使用可信执行环境的 API 只有 Attribution Reporting API 和 Private Aggregation API，它们都不涉及在竞价设置中实时调用 TEE。我们将继续探索对公有云解决方案之外的其他方案的支持。
在公有云中运行可信执行环境的费用不是比采用本地广告技术数据中心的费用更高吗？
我们目前的 TEE 隐私模型受益于公有云实现的安全做法，而我们对在本地运行可信执行环境费用更低的任何假设提出质疑。以下是一些关于费用的做法：
公有云提供商必须在安全性方面设立非常高的标准。例如，AWS 是信誉良好的云提供商，在安全做法方面已建立良好信誉。特别是，AWS Nitro 具有文档记述的安全模型，用于确保 Nitro Enclaves 防止操作员访问在 Enclave 中处理的数据，并且受保护的资源（例如解密密钥）仅供在 Enclave 中运行的授权代码使用。此外，您还需要考虑物理连接。AWS 针对物理访问风险（包括 Amazon 员工带来的风险）设计和实施了缓解措施。现有的基于硬件的 TEE 可能无法防御所有物理攻击，而公有云的目的则是防范。此外，Amazon 最近聘请了独立研究公司 NCC Group 来审核其 Nitro 设计，重点关注与内部员工访问相关的安全声明。公开报告表明 AWS 设计符合其声明。
随着时间推移，这些做法的落实、支持和改进工作需要花费金钱。由于公有云分布在全球各地，而且服务范围广阔，因此这些费用将分散在大量客户身上。
Privacy Sandbox 是否会改变结算方式？
不会。广告技术公司和其他 API 调用方可以继续查看某个内容是否以什么价格呈现在网页上。
Privacy Sandbox 中是否可以设置频次上限？
Protected Audience 通过 prevWinsMs 对象支持同一兴趣组内的跨网站频次上限。Protected Audience 竞价中买方的 generateBid() 函数可以创建逻辑，以便根据同一浏览器之前的广告曝光结果为出价策略提供信息。
除 Protected Audience 之外，有几种解决方案可用于实现频次上限，但它们不能完全映射到广告技术平台与第三方 Cookie 所使用的跨网站技术。
- 第一方 Cookie：广告技术平台可以使用自己的第一方数据为自己网站设置频次上限
- 条状标签：广告技术平台可以使用分区 Cookie 管理每个网站级别的频次上限
- 共享存储空间
SelectURL()：广告技术平台在赢得竞价后到呈现广告素材之前，可以调用共享存储空间以访问跨网站数据，并通过“选择网址”输出关口根据频率选择合适的广告素材。
高度注重隐私的非 Protected Audience 频次上限解决方案可提供有意义的广告技术平台效用，具体原因如下：
- 根据广告技术平台的反馈，目前还不清楚频率信号是否可以容忍噪声。
- 我们一直收到广告技术公司的反馈：竞价期间必须要有跨网站频率信号，这需要无噪声的跨网站信号可用于任何广告竞价。这可能会泄露大量与用户在网站上的活动有关的信息，从而破坏 Privacy Sandbox 的隐私保护目标。
- 我们对引入延迟非常敏感，并且可能会提供此信号的设备端解决方案可能会导致延迟并破坏竞价环境
- 解决方案可能需要使用新 API，并且新 API 必须通过 W3C 提案流程。
因此，我们的近期路线图并未涵盖在 Protected Audience 之外构建频次上限解决方案，但我们愿意接受反馈，以便了解解决此使用场景的潜在方法。
对于 Privacy Sandbox 未涵盖的用例，该怎么办？
Privacy Sandbox API 为可保护隐私的广告提供了关键的基础组件，开发者可灵活地决定它们的组合方式。利用基础组件方法，企业可以创新和开发可为其客户带来价值的解决方案。Privacy Sandbox 并不是要成为所有用例的端到端解决方案的意图。我们相信这是个坏结果。相反，开发者和企业将继续通过各种技术（包括他们集成到其解决方案中的 Privacy Sandbox API）将他们的想法变为现实。