出价和竞价服务

在最初的 Protected Audience 提案中，针对再营销广告需求的出价和竞价会在设备本地执行。这要求设备要有很高的计算能力，而这对处理能力有限的设备来说可能是不切实际的；这也可能会因网络延迟导致速度过慢，而无法选择和渲染广告。

出价和竞价服务 (B&A) 提案概述了一种方法，它允许 Protected Audience 计算在可信执行环境 (TEE) 中的云服务器中进行，而不是在用户设备本地运行。B&A 提案旨在采用统一的流程来考虑内容相关广告和再营销广告需求。将计算转移到服务器后，就不需要在设备端执行计算周期，而且可以释放设备端的网络带宽，从而帮助优化 Protected Audience 竞价。

Google 将提供 B&A 的组件，并将以开源形式提供。感兴趣的广告技术平台可以将自己的实例交由支持的公有云提供商托管。如需详细了解 B&A 提案，请访问 GitHub。请注意，该文档中出现的日期反映的是针对 Chrome 的实现日期，我们日后会发布有关与 Android 集成的详细信息。本文档介绍了 B&A，并说明了 Android 将提供哪些新的 API 来与 B&A 交互。我们将在以后的更新中发布有关如何使用这些新 API 的更多技术信息。

B&A 服务的适用情形

B&A 还提供了另一个选项，用于在广告技术平台拥有的可信服务器（需要运行由 Google 提供的开源二进制文件）中运行竞价。用户数据仍会保留在设备端，并且 Google 会提供用于将这些数据安全地移动到 TEE 的 API。下面进一步介绍了我们的加密策略。

这意味着竞价过程的某些部分在设备端进行，而其他部分在云端进行。从 DSP 的角度来看，自定义受众群体（包括用于再营销广告系列的候选广告）仍使用相同的自定义受众群体管理 API 在设备端进行管理，与在设备端进行竞价时相同。从 SSP 的角度来看，请求仍在设备端触发，并且此文档介绍了要使用的新 API。对于所有相关方，在完成 B&A 调用后，仍会从设备开始报告竞价结果。

主要区别在于出价、评分和报告网址生成逻辑的执行位置。系统会在 TEE 中执行 generateBid()、scoreAd()、reportResult() 和 reportWin() 逻辑，而不是在设备端运行出价、竞价和报告逻辑。买方的出价逻辑和卖方的评分逻辑都在其自己的 B&A 环境中执行，并且都在 Protected Audience 竞价流程中执行：

插图：Protected Audience 竞价流程以及出价和竞价的适用情形。
图 1. Protected Audience 竞价流程

数据加密

使用 B&A，Protected Audience 信息（例如自定义受众群体和出价金额）会从设备流经卖方广告技术平台服务器，再流向买方广告技术平台服务器，然后流回设备。因此，平台会对要发送到 Protected Audience 服务的数据进行加密，并且只能由经过认证的服务解密。如需详细了解加密策略，请访问 GitHub。

架构和竞价流程

此提案需要用到 GitHub 中详细介绍的几个新组件，包括从设备传输到 B&A 的数据流。

插图：统一的内容相关广告和 Protected Audience 竞价流程，如下文所述。
图 2. 统一的内容相关广告和 Protected Audience 竞价流程，包含出价和竞价服务。

概括来讲，数据流如下所述：

  1. 在设备端，卖方使用 getAdSelectionData API 从 Protected Audience 收集信息。
  2. 设备端 SDK 会向其卖方广告服务发送请求。此请求包含内容相关广告载荷和经过加密的 ProtectedAudienceInput。
  3. 卖方广告服务向在 TEE 之外运行的买方实时出价 (RTB) 服务发送请求，以获取候选的内容相关广告，然后进行评分并选择胜出的内容相关广告。
  4. 卖方广告服务向其在 TEE 中运行的 SellerFrontEnd 服务发送请求。
  5. SellerFrontEnd 服务向 BuyerFrontEnd 服务发送包含买方专属数据的请求。
  6. 买方使用自己的键值对服务和出价服务，后者会针对考虑对其进行再营销的所有自定义受众群体，为来自设备的候选广告生成出价。
  7. SellerFrontEnd 服务从其键值对服务中读取数据，并为候选广告评分。结果会被加密并返回给卖方广告服务。
  8. 卖方广告服务将经过加密的胜出结果（有时可能包含内容相关广告结果）返回给设备端 SDK。
  9. 在设备端，卖方使用 processAdSelectionResult API 检索胜出的广告，该 API 用于解密卖方广告服务的响应。

如需详细了解每个步骤以及数据加密方式，请访问 GitHub。这些组件的代码将以开源方式提供。提供的代码将处理从 FrontFrontEnd 服务发送到 BuyerFrontEnd 服务的联合请求。

云部署

广告技术平台会将 B&A 服务部署到受支持的公有云平台。这些部署由负责定义可用性服务等级目标的广告技术平台管理。

开展竞价

进行 B&A 竞价的第一步是从设备端自定义受众群体收集数据，然后进行加密以便发送到服务器端竞价。为此，请使用 getAdSelectionData API：

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData 方法会为 B&A 组件（例如 BuyerInput 和 ProtectedAudienceInput）生成所需的输入，并对数据进行加密，然后再将结果提供给调用方。为防止在各应用间发生数据泄露，这些数据包含设备端存在的所有买家的信息。如需详细了解此决定，请参阅隐私保护注意事项部分。

此 API 会返回一个 AdSelectionData 对象：

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

借助此 AdSelectionData，设备端 SDK 可以在 POST 或 PUT 请求中包含相关数据来向其卖方广告服务发送请求：

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

设备端 SDK 负责对此类数据进行编码。建议使用一种能高效利用空间的解决方案，例如以 multipart/form-data 的形式向卖方广告服务发送请求。

请求启动后，卖方广告服务会将请求转发给在 TEE 中运行的 SellerFrontEnd 服务。配置 SellerFrontEnd 服务时，卖方将提供一个网域地址列表，该列表对应的是与相应卖方合作的买方运营的 BuyerFrontEnd 服务。请求将联合发送到卖方已提供的各种 BuyerFrontEnd 服务，以便买方能够为其选择的候选广告生成出价。对于特定买方，B&A 将仅发送买方拥有的自定义受众群体的相关信息，以便买方之间不会发生数据交叉泄露。生成出价后，系统会将候选广告列表传回到选择胜出者的 SellerFrontEnd 服务。最后，SellerFrontEnd 服务会将经过加密的胜出广告返回给设备。

在从发送给卖方广告服务的请求收到的响应返回设备后，平台会提供另一个新 API 来解密结果并提供 AdSelectionOutcome（即从当前设备端竞价返回的同一对象）。

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

报告

报告网址将在 B&A 服务中生成。对用于报告竞价相关展示次数和互动次数的网址执行的 ping 操作仍然需要在设备上触发。设备端 SDK 仍需要使用在 B&A 流程中生成的 AdSelectionId 调用 reportImpression() 和 reportInteraction() API。为互动情况报告生成的信标和相应的网址包含在经过加密的响应中，因此在响应解密期间，事件和网址映射会存储在设备端。

隐私保护注意事项

GitHub 上的 Browser Bidding & Auction API 提案介绍我们从哪些方面考虑了隐私保护注意事项。此提案使用了 Chrome 的命名法，但同样的准则也适用于 Android。

adSelectionData 已经过加密，旨在确保只有 PPAPI 和可信服务器可以访问传输中的数据。为了降低因 adSelectionData 大小变化而导致数据泄露的风险，我们计划为所有对 getAdSelectionData API 的调用生成相同的 adSelectionData。这意味着，设备端的所有 CustomAudience 都将用于创建 adSelectionData。我们还计划限制 GetAdSelectionData 输入参数对生成的 adSelectionData 的影响。

如果使用所有设备端竞价数据为所有广告技术平台生成相同的 adSelectionData，则会导致每次调用广告技术平台服务器时都需要传输的载荷增大，同时可能会使生态系统开放而遭恶意实体滥用上述问题在下面的大小注意事项和防滥用注意事项部分中得到了解决。

大小注意事项

广告技术平台客户端 SDK 应将 adSelectionData 的加密字节打包到内容相关广告对卖方服务器的调用中。为了获得最佳效果，请务必在不影响功能的情况下优化 adSelectionData 的大小。我们计划推出载荷优化说明中提到的优化措施来减小 adSelectionData 大小。这些优化措施将包括：

  1. 在 CustomAudience 中添加 ad_render_id，以便使用 adSelectionData 而非广告呈现 URI 和元数据发送。广告技术平台可以在 adSelectionData 中不发送广告数据，进一步进行优化。在未来的版本中，CustomAudience API 将支持此选项。
  2. 确保 user_bidding_signals 不在 adSelectionData 中发送。广告技术平台可以改为从其键值对服务器中提取 user_bidding_signals。
  3. 允许买方优先处理 CustomAudience。
  4. 允许买方指定卖方优先级。
  5. 在几个固定分桶中生成 adSelectionData，以限制位泄露，同时减小载荷大小。

我们将在遵守“隐私保护注意事项”中提出的问题的前提下进行大小优化。

防滥用注意事项

如隐“私保护注意事项”所述，adSelectionData 是使用设备端的所有买方数据生成的。

这向潜在的恶意实体开放了生态系统，这些实体可能会添加可能会降低效果的欺诈性买方数据，导致载荷膨胀而增加费用，等等。

为打击 adSelectionData 滥用行为，我们将采取以下措施：

  • 允许 CustomAudience 显式指定已获批准的卖方和卖方优先级
  • 允许 SSP 在生成的载荷中显式指定买方、买方优先级和每个买方的配额
  • 提供一种机制，供 SSP 指定每次调用的买方数量上限或每个买方的大小上限。

这些措施旨在使广告技术平台能够指定与哪些其他广告技术平台进行协作，并为他们需要处理的 adSelectionData 载荷设置可接受的上限。我们提议允许卖方在单独的调用中指定此买方列表和优先级。此规范会在某些时间段内保持不变，以避免因重复调用而公开有关用户的其他数据。

上述缓解措施正在讨论中，我们会逐步对其进行改进。如前所述，所有针对防滥用和大小限制推出的缓解措施都必须遵循隐私保护注意事项。