确保 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 执行环境
在浏览器可以执行 generateBid() 之前，它必须初始化一个新的 JavaScript 执行环境。这可能会耗费大量时间，与最小 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() 的速度做出任何假设（例如，出价快的兴趣组数量较多和出价慢的兴趣组数量较少都可以提前完成）。
使用竞价配置 signal 字段来实现整体竞价超时也是一个不错的做法，这样可以防止在可信评分信号提取和执行 scoreAd() 耗时过长的情况下出现竞价时间过长的问题。
后续操作
我们希望与您交流，确保我们构建适合所有人的 API。
讨论 API
与其他 Privacy Sandbox API 一样，此 API 也会记录在案并公开讨论。
使用 API 进行实验
您可以进行实验并参与有关 Protected Audience API 的对话。