用于在 Android 设备上为相关应用安装广告提供支持的 Protected App Signals

移动应用安装广告（也称为“用户获取广告”）是一种旨在鼓励用户下载移动应用的移动广告。这些广告通常根据用户的兴趣和受众特征投放，而且经常出现在其他移动应用中（例如游戏、社交媒体和新闻应用）。用户点击应用安装广告后，即会直接跳转到应用商店去下载相关应用。

例如，如果广告客户正尝试提升一款新的移动美食外卖应用在美国的新安装量，可能会面向位于美国且以前使用过其他美食外卖应用的用户投放广告。

这通常是通过在广告技术平台之间添加情境信号、第一方信号和第三方信号来实现的，以便根据广告 ID 创建用户个人资料。广告技术机器学习模型会将这些信息用作输入，选择与用户相关且最有可能带来转化的广告。

建议使用以下 API 来支持有效的应用安装广告，通过消除对跨多方用户标识符的依赖来加强用户隐私保护：

1. Protected App Signals API：其核心是存储和创建体现用户潜在兴趣的广告技术工程化特征。广告技术平台会存储按应用事件划分的自定义信号，例如应用安装、首次打开、用户操作（游戏内升级、成就）、购买活动或在应用内所花的时间。信号会被写入并存储在设备上，以防止数据泄露；并且只有在安全环境中运行 Protected Auction 竞价期间，存储给定信号的广告技术逻辑才能使用这些信号。
2. Ad Selection API：可用来配置和执行在可信执行环境 (TEE) 中运行的 Protected Auction 竞价。在该环境中，广告技术平台会检索候选广告、运行推理、计算出价并进行评分，从而同时利用 Protected App Signals 和发布商提供的实时情境信息来选择“胜出”的广告。

图 1. 展示 Privacy Sandbox on Android 中 Protected App Signals 和广告选择工作流程的流程图。

下面简要介绍了 Protected App Signals 如何支持相关的应用安装广告。本文档后面的部分将详细介绍其中的每一个步骤。

• 信号管理：当用户使用移动应用时，广告技术平台通过存储广告技术平台定义的应用事件来管理信号，以便使用 Protected App Signals API 投放相关广告。这些事件会存储在受保护的设备端存储空间（类似于自定义受众群体）中，并会在发送到设备以外的位置之前进行加密；这样一来，只有在具有适当安全和隐私控制的可信执行环境中运行的出价和竞价服务才能解密这些事件，从而对广告进行出价和评分。
• 信号编码：信号由自定义广告技术逻辑按预定的节奏准备。Android 后台作业会执行该逻辑来进行设备端编码，以生成 Protected App Signals 的载荷，以便之后能在进行 Protected Auction 竞价期间实时用于广告选择。在送去竞价之前，该载荷会安全地存储在设备上。
• 广告选择：为了为用户选择相关广告，卖方 SDK 会发送 Protected App Signals 经过加密的载荷，并配置 Protected Auction 竞价。在该竞价中，买方的自定义逻辑会准备 Protected App Signals 以及发布商提供的情境数据（即通常在 Open-RTB 广告请求中共享的数据），来提取用于广告选择（广告检索、推理和出价生成）的特征。与 Protected Audience 类似，买方向卖方提交广告，以在 Protected Auction 竞价中进行最终评分。
  • 广告检索：买方使用 Protected App Signals 和发布商提供的情境数据来提取与用户兴趣相关的特征。这些特征会用于匹配符合定位条件的广告。不符合预算的广告会被过滤掉。然后，前 k 个广告将被选来用于出价。
  • 出价：买方的自定义出价逻辑会准备发布商提供的情境数据和 Protected App Signals，以提取可用作买方机器学习模型输入的特征，从而在可保护隐私的可信边界内对候选广告进行推理和出价。然后，买方将其选择的广告返回给卖方。
  • 卖方评分：卖方的自定义评分逻辑对参与竞价的买方提交的广告进行评分，并选择胜出的广告发送回应用进行呈现。
• 报告：竞价参与者会收到相应的胜出报告和落败报告。我们正在探索可保护隐私的机制，以便在胜出报告中包含用于模型训练的数据。

时间轴

	开发者预览版			Beta 版
功能	2023 年第 4 季度	2024 年第 1 季度	2024 年第 2 季度	2024 年第 3 季度
Signal Curation API	On-device storage API	设备端存储空间配额逻辑 设备端自定义逻辑每日更新	不适用	适用于 1% T+ 设备
TEE 中的广告检索服务器	MVP	适用于 GCP 支持 Top-K UDF 生产化	适用于 AWS 经用户同意的调试、指标和监控
TEE 中的推断服务 支持运行机器学习模型并在 TEE 中将其用于出价	开发中	适用于 GCP 能够使用 Tensorflow 和 PyTorch 部署静态机器学习模型并对其进行原型设计	适用于 AWS 对 Tensorflow 和 PyTorch 模型进行生产环境化部署 遥测、经用户同意的调试和监控
TEE 中的出价和竞价支持	适用于 GCP	PAS-B&A 和 TEE 广告检索集成（使用 gRPC 和 TEE<>TEE 加密） 通过上下文路径支持广告检索（包括 TEE 上的 B&A<>K/V 支持）	适用于 AWS 调试报告 经用户同意的调试、指标和监控

管理 Protected App Signals

信号是应用中各种用户互动的表示形式，广告技术平台会判断这些互动是否对投放相关广告有用。应用或集成的 SDK 可以存储或删除广告技术平台根据用户活动（例如打开应用、成就、购买活动或在应用内所花的时间）定义的 Protected App Signals。Protected App Signals 会安全地存储在设备上，并会在发送到设备以外的位置之前进行加密；这样一来，只有在具有适当安全和隐私控制的可信执行环境中运行的出价和竞价服务才能解密这类信号，从而对广告进行出价和评分。与 Custom Audience API 类似，应用或 SDK 无法读取或检查存储在设备上的信号；没有用于读取信号值的 API，并且 API 的设计是为了避免泄露是否存在相应信号。广告技术平台的自定义逻辑可在受保护的情况下访问其管理的信号，以提取在 Protected Auction 竞价中用作广告选择依据的特征。

Protected App Signals API

Protected App Signals API 支持使用与自定义受众群体所用委托机制类似的机制来管理信号。该 API 允许以单个标量值或时间序列的形式存储信号。时间序列信号可用于存储用户会话时长等信息。这类信号提供了一种实用程序，可通过先进先出的驱逐规则来强制实施给定长度。标量信号的数据类型或时间序列信号的每个元素都是字节数组。每个值都包含存储信号的应用的软件包名称和存储信号 API 调用的创建时间戳。这些额外信息可在信号编码 JavaScript 中找到。下面的示例展示了给定广告技术平台所拥有信号的结构：

此示例演示了与 adtech1.com 关联的标量信号和时间序列信号：

• 具有 base64 值键为“A1c”且值为“c12Z”的标量信号。该信号存储已由 com.google.android.game_app 于 2023 年 6 月 1 日触发。
• 由两个不同应用创建且具有键为“dDE”的信号的列表。

广告技术平台会被分配到一定量的空间，以在设备上存储信号。信号将有一个待确定的最大 TTL。

如果生成信号的应用被卸载、被禁止使用 Protected App Signals API，或者用户清除了应用数据，Protected App Signals 就会从存储空间中移除。

Protected App Signals API 由以下部分组成：

• Java and JavaScript API，用于添加、更新或移除信号。
• JavaScript API，用于处理持久性信号，以便在可信执行环境 (TEE) 中运行 Protected Auction 竞价期间，为实时进行进一步特征工程做好准备。

添加、更新或移除信号

广告技术平台可以使用 updateSignals() API 添加、更新或移除信号。此 API 支持与 Protected Audience 自定义受众群体委托类似的委托机制。

若要添加信号，应用中没有 SDK 的买方广告技术平台需要与设备端拥有 SDK 的广告技术平台合作，例如移动设备衡量合作伙伴 (MMP) 需与供应方平台 (SSP) 携手合作。Protected App Signals API 旨在支持这类广告技术平台，通过为 Protected App Signal 管理提供灵活的解决方案，让设备端调用方能够代表买方调用 Protected App Signals 的创建操作。此过程称为委托，并利用了 updateSignals() API。updateSignals() 会接受 URI，然后检索信号更新列表。举例来说，updateSignals() 会向给定 URI 发出 GET 请求，以检索要应用于本地信号存储空间的更新列表。买方拥有的网址端点会返回一个 JSON 格式的命令列表作为响应。

支持的 JSON 命令包括：

• put：为给定键插入或覆盖标量值。
• put_if_not_present：如果尚未存储任何值，则为给定键插入标量值。例如，若要为给定用户设置实验 ID，并要避免在其他应用已设置该 ID 的情况下覆盖它，该选项会很有用。
• append：向与给定键关联的时间序列添加元素。maxSignals 参数可用来指定时间序列中的信号数量上限。如果超过了这个数量，系统会移除较早的元素。如果键包含标量值，它会自动转换为时间序列。
• remove：移除与给定键关联的内容。

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

所有键和值均以 Base64 表示。

上述命令可用于插入、覆盖和删除标量信号，以及用于插入、附加和以全序列形式覆盖时间序列信号。若要删除和覆盖时间序列信号中的特定元素，必须在编码和压缩过程中进行；例如，在编码过程中忽略时间序列中被较新值取代或更正的值，并在压缩过程中删除这些值。

存储的信号会自动与执行提取请求的应用、请求的响应者（已注册的广告技术平台的“网站”或“源”）以及请求的创建时间相关联。所有信号都必须以已在 Privacy Sandbox 中注册的广告技术平台的名义存储，URI 中的“网站”/“源”必须与已注册广告技术平台的数据相匹配。如果请求的广告技术平台未注册，请求就会被拒绝。

存储空间配额和驱逐

每个广告技术平台在用户设备上存储信号的空间有限。此配额是按广告技术平台定义的，因此从不同应用中管理的信号会共享配额。如果超出配额，系统会按照先进先出的原则移除较早的信号值，从而腾出空间。为了防止过于频繁地执行驱逐操作，系统实现了批处理逻辑，允许在一定程度上透支配额，并会在触发驱逐逻辑后腾出一些额外的空间。

用于传输数据的设备端编码

为了准备广告选择所需的信号，每个买方的自定义逻辑都可在受保护的情况下访问存储的每个应用信号和事件。Android 系统后台作业每小时运行一次，以执行下载到设备上的每个买方的自定义编码逻辑。该逻辑会对每个应用的信号进行编码，然后将每个应用的信号压缩为符合每个买方配额的载荷。接下来，该载荷将在受保护的设备存储空间范围内加密，然后传输给出价和竞价服务。

广告技术平台定义由自己的自定义逻辑处理的信号处理级别。例如，您可以对解决方案进行插桩，以舍弃较早的信号，并将来自不同应用的类似或增强信号聚合为使用更少空间的新信号。

如果买方未注册信号编码器，便不会准备信号，在设备上管理的信号也不会发送到出价和竞价服务中。

我们将在日后的更新中详细介绍存储空间、载荷和请求配额。此外，我们还将进一步说明如何提供自定义函数。

广告选择工作流程

在此提案中，广告技术平台自定义代码只能在 TEE 中运行的 Protected Auction 竞价 (Ad Selection API) 内访问 Protected App Signals。为了进一步支持对应用安装用例的需求，在 Protected Auction 竞价期间会实时提取候选广告。这与再营销用例完全不同，在再营销用例中，候选广告在竞价之前就已知晓。

此提案使用与 Protected Audience 提案类似的广告选择工作流程，并进行了更新，以支持应用安装用例。为了满足特征工程和实时广告选择的计算要求，应用安装广告竞价必须在 TEE 中运行的出价和竞价服务上运行。设备端竞价不支持在 Protected Auction 竞价期间访问 Protected App Signals。

图 2. Privacy Sandbox on Android 中的广告选择工作流程。

广告选择工作流程如下：

1. 卖方的 SDK 发送 Protected App Signals 在设备上经过加密的载荷。
2. 卖方的服务器创建竞价配置，并将其与加密的载荷一起发送到卖方的可信出价和竞价服务，以启动广告选择工作流程。
3. 卖方的出价和竞价服务将载荷传递给参与竞价的可信买方前端服务器。
4. 买方的出价服务执行买方广告选择逻辑
   1. 执行买方广告检索逻辑。
   2. 执行买方出价逻辑。
5. 执行卖方评分逻辑。
6. 呈现广告并启动报告。

启动广告选择工作流程

当应用准备好展示广告时，广告技术 SDK（通常是 SSP）会启动广告选择工作流程，方法是使用 getAdSelectionData 调用发送来自发布商的所有相关情境数据以及每个买方的已加密载荷，这些数据将包含在发送给 Protected Auction 竞价的请求中。这也是用于再营销工作流程的 API，Android 出价和竞价集成提案对此进行了介绍。

为了启动广告选择，卖方需要传入参与竞价的买方的列表，以及设备端 Protected App Signals 的已加密载荷。有了这些信息，卖方广告服务器就会为其可信 SellerFrontEnd 服务准备 SelectAdRequest。

卖方会设置以下内容：

• 从 getAdSelectionData 收到的载荷，其中包含 Protected App Signals。
• 采用以下各项的情境信号：
  • auction_config.auction_signals（竞价相关信息）
  • auction_config.seller_signals（卖方的信号）
  • auction_config.per_buyer_config["buyer"].buyer_signals（买方的信号）
• 使用 buyer_list 字段指定参与竞价的买方列表。

执行买方广告选择逻辑

概括来讲，买方的自定义逻辑会使用发布商提供的情境数据以及 Protected App Signals，为广告请求选择相关广告并对其出价。买方可通过该平台对大量可用广告进行缩减，以找出最相关的广告（即前 k 个广告），并在将广告返回给卖方做最终选择之前计算出价。

图 3. Privacy Sandbox on Android 中的买方广告选择执行逻辑。

在出价之前，买方会先看到一大批广告。如果为每个广告都计算出价的话，速度会很慢，因此买方首先需要从那一大批广告中选择前 k 个候选广告。接下来，买方需要为这前 k 个候选广告分别计算出价；然后，将这些广告和出价返回给卖方做最终选择。

注意：此流程混合了框架代码和包含买方业务逻辑的用户定义的函数 (UDF)。这些 UDF 使用 JavaScript 或 WASM 来实现。概括来讲，该流程如下：

1. BuyerFrontEnd 服务收到广告请求。
2. BuyerFrontEnd 服务向买方的出价服务发送请求。买方的出价服务运行一个名为 prepareDataForAdRetrieval() 的 UDF。该函数会构建相应请求，以便从 Ad Retrieval Service（广告检索服务）中获取前 k 个候选广告。出价服务将此请求发送到配置的检索服务器端点。
3. Ad Retrieval Service 运行 getCandidateAds() UDF，以过滤出前 k 个候选广告，然后将这组广告发送给买方的出价服务。
4. 买方的出价服务运行 generateBid() UDF，选出最佳候选广告并计算其出价，然后将其返回给 BuyerFrontEnd 服务。
5. BuyerFrontEnd 服务将广告和出价返回给卖方。

这个流程有几个重要的细节，尤其是关于各个组件之间的通信方式以及平台提供的功能，比如使用机器学习预测来检索前 k 个广告并计算其出价。

在我们详细介绍其中的各个组件之前，先来看看上图中关于 TEE 的一些重要架构说明。

买方的出价服务内部包含推理服务。广告技术平台可以将机器学习模型上传到买方的出价服务中。我们将为广告技术平台提供 JavaScript API，以便从买方出价服务上运行的 UDF 中通过这些模型进行预测或生成嵌入。与 Ad Retrieval Service 不同，买方的出价服务不提供用于存储任何广告元数据的键值对服务。

Ad Retrieval Service 内部包含键值对服务。广告技术平台可以在隐私边界之外从自己的服务器将键值对具体化到此服务中。我们将提供 JavaScript API，供广告技术平台从 Ad Retrieval Service 上运行的 UDF 中通过该键值对服务读取数据。与买方的出价服务不同，Ad Retrieval Service 不包含推理服务。

此设计解决的一个核心问题是，如何在检索期间和出价期间进行预测。这两个问题的答案都可能涉及一种称为“模型分解”的解决方案。

模型分解

模型分解是一种技术，可将单个模型拆分为多个部分，然后将这些部分组合成预测结果。在应用安装用例中，模型通常会使用以下三种数据：用户数据、情境数据和广告数据。

在非分解的情况下，单个模型会使用所有三种数据进行训练。在分解的情况下，我们会将模型分成多个部分。只有包含用户数据的部分是敏感的。这意味着，只有包含用户部分的模型需要在信任边界内买方出价服务的推理服务上运行。

这使得以下设计成为可能：

1. 将模型拆分为一个“私密部分”（用户数据）和一个或多个“非私密部分”（情境数据和广告数据）。
2. （可选）将部分或全部非私密部分作为参数传递给需要进行预测的 UDF。例如，情境嵌入会传递给 per_buyer_signals 中的 UDF。
3. （可选）广告技术平台可以为非私密部分创建模型，然后将这些模型中的嵌入具体化到 Ad Retrieval Service 的键值对存储区中。Ad Retrieval Service 上的 UDF 可在运行时提取这些嵌入。
4. 如需在 UDF 期间进行预测，可通过点积等操作，将来自推理服务的私密嵌入与来自 UDF 函数参数/键值对存储区的非私密嵌入进行组合。这就是最终的预测结果。

理解了该设计后，我们接下来可以更详细地了解每个 UDF，包括它们的用途、集成方式，以及如何进行必要的预测以选择前 k 个广告并计算其出价。

prepareDataForAdRetrieval() UDF

在买方的出价服务上运行的 prepareDataForAdRetrieval() 负责创建将发送到 Ad Retrieval Service 的请求载荷，以提取前 k 个候选广告。

prepareDataForAdRetrieval() 接受以下信息：

• 从 getAdSelectionData 收到的每个买方载荷。此载荷包含 Protected App Signals。
• 情境信号的 auction_signals（竞价相关信息）和 buyer_signals（买方信号字段）。

prepareDataForAdRetrieval() 会执行以下两项操作：

• 特征化：如果需要在检索期间进行推理，它会将传入信号转换为特征，以便在调用推理服务来获取用于检索的私密嵌入时使用。
• 计算用于检索的私密嵌入：如果需要检索预测，它会使用上述特征调用推理服务，并获取用于在检索期间进行预测的私密嵌入。

prepareDataForAdRetrieval() 会返回：

• Protected App Signals：广告技术平台管理的信号载荷。
• 每次竞价的特定信号：平台专有的卖方信号，以及来自 SelectAdRequest 的 auction_signals 和 per_buyer_signals 等情境信息（包括情境嵌入）。这与 Protected Audiences 类似。
• 额外信号：从推理服务中检索到的私密嵌入等额外信息。

该请求会被发送到 Ad Retrieval Service，后者会匹配候选广告，然后运行 getCandidateAds() UDF。

getCandidateAds() UDF

getCandidateAds() 在 Ad Retrieval Service 上运行，并接收 prepareDataForAdRetrieval() 在买方的出价服务中创建的请求。该服务会执行 getCandidateAds()，通过将请求转换为一系列集合查询、数据提取，并执行自定义业务逻辑和其他自定义检索逻辑，提取前 k 个候选广告进行出价。

getCandidateAds() 接受以下信息：

• Protected App Signals：广告技术平台管理的信号载荷。
• 每次竞价的特定信号：平台专有的卖方信号，以及来自 SelectAdRequest 的 auction_signals 和 per_buyer_signals 等情境信息（包括情境嵌入）。这与 Protected Audiences 类似。
• 额外信号：从推理服务中检索到的私密嵌入等额外信息。

getCandidateAds() 会执行以下操作：

1. 提取初始的候选广告集：使用定位条件（如语言、地理位置、广告类型、广告尺寸或预算）来过滤候选广告，从而提取初始的候选广告集。
2. 提取检索嵌入：如果需要从键值对服务中获取嵌入，以便在检索期间进行预测，从而选出前 k 个候选广告，就必须从键值对服务中检索这些嵌入。
3. 选择前 k 个候选广告：根据从键值对存储区提取的广告元数据以及买方的出价服务发送的信息，为过滤后的候选广告集计算一个轻量级得分，然后根据该得分挑选前 k 个候选广告。例如，得分可能是用户在看到广告后安装应用的几率。
4. 提取出价嵌入：如果出价代码需要从键值对服务中获取嵌入，以便在出价期间进行预测，可以从键值对服务中检索这些嵌入。

请注意，广告的得分可能是预测模型的输出结果，例如预测用户安装应用的概率。这种得分生成涉及到一种模型分解：由于 getCandidateAds() 在 Ad Retrieval Service 上运行，并且 Ad Retrieval Service 不包含推理服务，因此可通过组合以下各项生成预测结果：

• 使用每次竞价的特定信号输入传入的情境嵌入。
• 使用额外信号输入传入的私密嵌入。
• 广告技术平台已从其服务器具体化到 Ad Retrieval Service 的键值对服务中的任何非私密嵌入。

请注意，在买方的出价服务上运行的 generateBid() UDF 也可能会应用自己的模型分解来进行出价预测。如果需要从键值对服务中提取任何嵌入来执行此操作，必须立即提取这些嵌入。

getCandidateAds() 会返回：

• 候选广告：要传递给 generateBid() 的前 k 个广告。每个广告均由以下部分组成：
  • 呈现网址：用于呈现广告素材的端点。
  • 元数据：买方广告技术平台专有的广告元数据。例如，这可能包含广告系列的相关信息以及定位条件（例如地理位置和语言）。元数据可以包含在出价期间需要进行模型分解以运行推理时使用的可选嵌入。
• 额外信号：Ad Retrieval Service 可视需要包含额外信息（例如额外嵌入或垃圾内容信号），以便在 generateBid() 中使用。

我们正在研究提供广告评分的其他方法，包括将其作为 SelectAdRequest 调用的一部分提供。您可以使用实时出价请求检索这些广告。请注意，在这种情况下，必须在没有 Protected App Signals 的情况下检索广告。我们预计，广告技术平台会在选择最佳方案之前权衡利弊，包括响应载荷大小、延迟时间、费用和信号可用性。

generateBid() UDF

在检索期间检索到候选广告集和嵌入后，您就可以开始在买方的出价服务中进行出价。该服务会运行买方提供的 generateBid() UDF，从前 k 个广告中选择要出价的广告，然后返回该广告及其出价。

generateBid() 接受以下信息：

• 候选广告：检索 Ad Retrieval Service 返回的前 k 个广告。
• 每次竞价的特定信号：平台专有的卖方信号，以及来自 SelectAdRequest 的 auction_signals 和 per_buyer_signals 等情境信息（包括情境嵌入）。
• 额外信号：出价时要使用的额外信息。

买方的 generateBid() 实现会执行以下三项操作：

• 特征化：将信号转换为特征，以便在推理过程中使用。
• 推理：使用机器学习模型生成预测，以计算预测的点击率和转化率等值。
• 出价：将推断的值与其他输入相结合，以计算候选广告的出价。

generateBid() 会返回：

• 候选广告。
• 计算得出的出价金额。

请注意，用于应用安装广告的 generateBid() 和用于再营销广告的这个函数并不相同。

下面几个部分将更详细地介绍特征化、推理和出价。

特征化

竞价信号可由 generateBid() 转换为特征。这些特征可在推理过程中用于预测点击率和转化率等指标。我们还在探索可保护隐私的机制，以便在胜出报告中传输其中一些特征，供模型训练使用。

推理

在计算出价时，通常根据一个或多个机器学习模型进行推理。例如，在计算有效 eCPM 时，通常使用模型来预测点击率和转化率。

客户可以在实现 generateBid() 时，提供多个机器学习模型。我们还会在 generateBid() 内提供 JavaScript API，以便客户在运行时进行推理。

推理是在买方的出价服务上执行。这可能会影响推理的延迟时间和费用，尤其是因为 TEE 中还没有提供加速器。一些客户会发现，买方的出价服务上运行的各个模型已经满足了其需求；一些客户（例如拥有超大型模型的客户）则可能需要考虑模型分解之类的方案，以在出价时尽量减少推理费用和延迟时间。

我们将在日后的更新中提供有关推理功能的更多信息（例如支持的模型格式和大小上限）。

实现模型分解

前面我们介绍了模型分解。在出价时，具体方法如下：

1. 将单个模型拆分为一个“私密部分”（用户数据）和一个或多个“非私密部分”（情境数据和广告数据）。
2. 将非私密部分传递给 generateBid()。这些数据可以来自 per_buyer_signals；也可以来自广告技术平台在外部计算的嵌入，这些嵌入会具体化到检索服务的键值对存储区，并在检索时提取，然后作为信号的一部分返回。这并不包括私密嵌入，因为它们无法从隐私边界之外获取。
3. 在 generateBid() 中：
   1. 根据模型进行推理，以获取私密用户嵌入。
   2. 使用点积之类的操作，将私密用户嵌入与来自 per_buyer_signals 的情境嵌入或来自检索服务的非私密广告与情境嵌入相结合。这就是可用于计算出价的最终预测结果。

利用这种方法，可以在出价时根据模型进行推理，而这些模型在买方的出价服务上执行起来可能太大或太慢。

卖方评分逻辑

在这一阶段，会对从所有参与竞价的买方那里收到出价的广告进行评分。generateBid() 的输出将传递给卖方的竞价服务来运行 scoreAd()，而 scoreAd() 每次只考虑一个广告。卖方根据评分选择胜出的广告，以返回给设备进行呈现。

该评分逻辑与用于 Protected Audience 再营销流程的逻辑相同，能够从再营销和应用安装候选广告中选择胜出广告。在 Protected Auction 竞价中，针对每个提交的候选广告，系统都会调用一次该函数。如需了解详情，请参阅出价和竞价说明文档。

广告选择代码运行时

在此提案中，用于应用安装的广告选择代码的指定方式与 Protected Audience 再营销流程的指定方式相同。如需了解详情，请参阅出价和竞价配置。出价代码与用于再营销的代码将位于同一云端存储位置。

报告

此提案使用与 Protected Audience 报告提案相同的 Reporting API。

为了支持出价优化和模型训练，我们还在探索可保护隐私的方式，以便将 generateBid() 中的数据导出到胜出报告，供训练使用。我们将在后续更新中提供更多详细信息。

权限

用户控制

• 此提案旨在让用户能够以列表形式查看哪些已安装的应用存储了至少一个 Protected App Signal 或自定义受众群体。
• 用户可以屏蔽此列表中的应用并从中移除应用。执行这项操作的作用如下：
  • 清除与相关应用关联的所有 Protected App Signals 和自定义受众群体。
  • 阻止相关应用存储新的 Protected App Signals 和自定义受众群体。
• 用户能够彻底重置 Protected App Signals 和 Protected Audience API。当这种情况发生时，设备上所有现有的 Protected App Signals 和自定义受众群体都会被清除。
• 用户还可以选择彻底停用 Privacy Sandbox on Android，其中包括 Protected App Signals API 和 Protected Audience API。当这种情况发生时，Protected Audience API 和 Protected App Signals API 会返回标准的异常消息：SECURITY_EXCEPTION。

应用权限和控制

此提案旨在为应用提供控制其 Protected App Signals 的权限：

• 应用可管理其与 Protected App Signals 的关联。
• 应用可授权第三方广告技术平台代表其管理 Protected App Signals。

广告技术平台控制

此提案概述了广告技术平台控制其 Protected App Signals 的方法：

• 所有广告技术平台都必须注册 Privacy Sandbox，并提供与 Protected App Signals 的所有网址匹配的“网站”或“源”域名。
• 广告技术平台可与应用或 SDK 合作，提供用于验证 Protected App Signals 创建信息的验证令牌。当此过程委托给合作伙伴时，可以将 Protected App Signal 创建配置为需要广告技术平台确认。