为了确保 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）进行差异化出价。
如果没有 HTTP 缓存控制标头，系统不会缓存出价脚本。指定适当的标头，以确保系统不会不必要地提取脚本。如果页面上有多个竞价同时运行，系统会重复使用同一出价方的出价脚本（如果该脚本已在内存中），而忽略缓存语义。如果竞价顺序地运行，则浏览器将遵循 HTTP 缓存机制。
请注意，浏览器会在出价时间（对于 generateBid()）和报告时间（对于 reportWin()）加载出价脚本。如果未设置缓存控制标头，则浏览器会提取同一脚本两次，每个时间段一次。
因此，我们建议您为所有脚本设置缓存控制标头。
重复使用 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 的对话。