确保 Protected Audience API 高效运行符合所有人的利益：
- 浏览网页的用户都希望网站能够快速加载。这意味着，开发者应使用 Protected Audience API 高效构建应用，以免过度使用加载网站及其嵌入式广告所需的有限设备资源，例如计算或网络资源。
- 发布商希望自己的网站能够快速加载，为用户提供高效且响应迅速的体验。发布商还希望通过效果出色的广告来尽可能增加收入。
- 广告主和广告技术平台希望他们的广告能够快速展示，以提供最大的效用。
本文档简要介绍了实现 Protected Audience API 的一些最佳实践，以确保您的网站以最高效率运行。
买方（出价方）最佳做法
为了确保您以提高 Protected Audience API 竞价效率为目标进行优化，请遵循以下最佳实践。
减少兴趣群体所有者
为了像保护 Protected Audience API 出价方一样保护浏览器使用网站隔离中的不同来源，浏览器会使用昂贵的资源（例如操作系统进程）来保护各个兴趣群体所有者。
为了最大限度地降低这些非常昂贵的资源的支出，尽量减少兴趣群体所有者的数量至关重要。请避免将不同的兴趣群体归为不同的子网域。例如，如果 adtech.example 的兴趣群体归 cats.adtech.example 和 dogs.adtech.example 所有，浏览器可能会使用两个单独的进程来运行其出价脚本。
基于兴趣群体的出价减少
在调用买方的 generateBid() 脚本之前，浏览器必须进行重要的设置和准备，例如设置全新的干净的 JavaScript 执行环境，以及解析和加载 generateBid() 代码。
- 如果兴趣群体所代表的用户目前不是正在投放的广告系列，就应该包含空白的广告素材列表。这样可以防止 Protected Audience API 对没有相关广告的兴趣群体执行
generateBid()。 - 合并类似兴趣群体会减少
generateBid()必须运行的次数。兴趣群体的userBiddingSignals属性可用于存储有关用户的其他元数据，因此兴趣群体越少，就不一定意味着定位效果越低。 - Protected Audience API 支持卖方指定的兴趣群体数量限制，也支持买方指定其兴趣群体的相对优先级的 API。这些限制可用于大幅减少要运行的出价脚本的数量。
从键值对服务的出价中滤除兴趣群体
如果买方可以在其实时出价信号服务器中确定某些兴趣群体不应出价（例如，广告系列已停用、暂停或预算已用尽，或者不应针对该特定发布商出价），他们可以通过对可信出价信号提取的 priorityVector 响应向浏览器指明这一点。如果 priorityVector 和 prioritySignals 的稀疏点积为负数，则浏览器将跳过为此兴趣群体调用 generateBid() 的步骤。如需详细了解此机制，请参阅说明材料的“过滤兴趣组并确定其优先级”部分。
重复使用 JavaScript 执行环境
浏览器必须先初始化新的 JavaScript 执行环境，然后才能执行 generateBid()。此过程可能需要大量时间，与执行最小 generateBid() 本身所需的时间相同。可以使用按源分组或冻结上下文的执行模式来节省此时间。
如果兴趣群体位于同一来源，并且可能不需要更改出价脚本，group-by-origin 模式可以重复使用执行环境；要了解详情，请参阅铺垫消息中的 group-by-origin 说明。冻结上下文模式可能会重复使用所有执行环境，但可能需要更改出价脚本；要了解详情，请参阅解释器中的 frozen-context 说明。
重复使用出价脚本
如果可能，请为兴趣群体使用相同的出价脚本。这样可以使浏览器不必下载、解析和编译多个脚本（这会产生额外的网络请求）。使用同一脚本时，出价方仍可根据兴趣群体信息（例如name或userBiddingSignals）进行差异化出价。
重复使用“trustedBiddingSignalsUrls”
网络延迟和资源使用量可能非常严重。减少实时可信出价信号提取量有助于缩短此延迟时间。
在多个兴趣群体中重复使用 trustedBiddingSignalsUrl 时，可以合并可信出价信号提取。如有可能，对所有兴趣群体使用相同的trustedBiddingSignalsUrl。
指定适当的 HTTP 缓存控制标头，可确保可信出价信号提取在特定网页上的广告位之间缓存。避免将 trustedBiddingSignalsSlotSizeMode 设置为 slot-size，因为在广告位大小不同（因为请求的网址会不同）时，这样做会导致广告位无法进行缓存。
更小的可信出价实时信号提取
网络延迟可能非常明显，而这直接受在实时可信出价信号提取期间传输的数据量的影响。
最好将特定于广告或针对用户兴趣群体的数据存储在兴趣群体中，而不是存储在可信出价信号服务中。仅为真正的实时信号（如广告系列预算或终止开关）预留可信实时出价信号数据。
任何能够每天或更长时间更新的信号都应存储在兴趣组中，并使用每日更新进行更新。
不针对已被滤除的兴趣群体返回可信出价信号（如“通过键值对服务的出价滤除兴趣群体”部分中所述）。
确定兴趣群体的优先级
卖方会使用超时来限制浏览器资源在发布商网页上的使用方式。如果使用 perBuyerCumulativeTimeouts 来限制买方必须提取可信出价信号并执行出价脚本的时间，买方必须确保优先考虑其兴趣群体，以便最有可能在竞价中胜出的群体优先执行。例如，如果将 perBuyerCumulativeTimeouts 设置为 100 毫秒，出价方的可信出价信号提取用时 50 毫秒，每次 generateBid() 调用需要 10 毫秒，并且设备上有 10 个兴趣群体，那么只有一半的兴趣群体能够计算出价。本例中的买方应按照从最有可能获胜到最不可能获胜的顺序对兴趣群体进行优先排序。
兴趣组可以包含用其 priority 字段定义的静态优先级。兴趣组还可以使用动态优先级，这些优先级可以在其可信出价信号服务上计算，并通过对可信出价信号提取的 priorityVector 响应返回给浏览器。
请注意，当浏览器按优先级从高到低执行兴趣群体时，这可能会分散来自不同加入来源的兴趣群体，这可能会使 group-by-origin 优化失败。
销售人员最佳做法
请务必监控 Protected Audience API 竞价效率并进行优化。
并行参与竞价
现代网络连接和多核处理器可以很好地同时执行多项活动。浏览器可以与其他活动并行执行 Protected Audience 竞价。为解决此问题，最好尽早调用 runAdAuction()。由于认识到 runAdAuction() 的某些输入可能在早期可能无法使用（例如，在上下文响应中发回给浏览器的输入），浏览器允许在 runAdAution() 可用之前调用它们，并允许稍后使用 JavaScript Promise 提供这些输入。为了尽可能缩短竞价延迟时间，应在已知 interestGroupBuyers 输入时调用 runAdAuction()。这样一来，竞价的许多部分便可立即开始，包括提取出价方的实时出价信号。
监控竞价
收集关于您的竞价的指标。浏览器可以向卖方报告 per-buyer 延迟时间指标，以便他们深入了解在卖方竞价中花费的时间。卖方可以根据这些指标找到优化竞价的方法，包括了解如何最有效地设置超时。卖方可以与买方分享特定买方的延迟时间指标，以便他们进一步进行优化。
出价方可以深入了解自己的兴趣群体的出价效果，但可能无法将其与其他出价方进行比较。比较不同出价方的相对胜出率和出价拒绝率可能有助于确定因兴趣群体从未提供可行出价或使用未获批准的广告素材过多出价而导致出价计算资源浪费的情况。
防范运行缓慢的出价脚本
耗时过长的出价脚本可能会减慢所有相关方的 Protected Audience API 竞价速度。使用超时可以防止竞价缓慢，同时在竞价缓慢时仍能挽回收入。
卖方应使用 perBuyerCumulativeTimeouts 来防止竞价缓慢，并在竞价缓慢且已超时时仍然接受出价。使用 perBuyerCumulativeTimeouts 比使用 perBuyerTimeouts 和 perBuyerGroupLimits 更合适，因为 perBuyerCumulativeTimeouts 对兴趣群体的数量或 generateBid() 的速度没有主观（例如，很多出价速度很快的兴趣群体和出价较慢的兴趣群体都可在超时之前完成）。
在提取可信评分信号并执行 scoreAd() 所花时间过长的情况下，使用竞价配置 signal 字段实现整体竞价超时也是一种不错的方法，可以防止竞价过长。
后续操作
我们希望与您交流，确保我们构建适合所有人的 API。
讨论 API
与其他 Privacy Sandbox API 一样，此 API 也会记录在案并公开讨论。
使用 API 进行实验
您可以进行实验并参与有关 Protected Audience API 的对话。