受保护的应用信号，以支持相关的应用安装广告

此方案需要遵循 Privacy Sandbox 注册流程和证明。如需详细了解相关证明，请参阅提供的证明链接。此方案的未来更新内容将说明获取此系统访问权限的要求。

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

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

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

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

1. Protected App Signals API：其核心是存储和创建体现用户潜在兴趣的广告技术工程化特征。广告技术平台会存储自定义的各应用事件信号，例如应用安装、首次打开、用户操作（游戏内关卡、成就）、购买活动或应用内时间。这些信号会写入并存储在设备上，以防止数据泄露；这些信号仅供在安全环境中运行的受保护竞价期间存储指定信号的广告技术逻辑使用。
2. Ad Selection API：此 API 提供了一个 API 来配置和执行在可信执行环境 (TEE) 中运行的受保护竞价。在 TEE 中，广告技术平台会检索候选广告、运行推断、计算出价，并评分以结合使用受保护的应用信号和发布商提供的实时上下文信息来选择“胜出”的广告。

展示 Privacy Sandbox on Android 中受保护应用信号和广告选择工作流程的流程图。

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

• 信号挑选：当用户使用移动应用时，广告技术平台会通过存储广告技术平台定义的应用事件来挑选信号，以便使用 Protected App Signals API 投放相关广告。与自定义受众群体类似，这些事件会存储在受保护的设备端存储空间中，并在发送到设备外之前进行加密，以便只有在具有适当安全性和隐私控制功能的可信执行环境中运行的出价和竞价服务才能解密它们，以便对广告进行出价和评分。
• 信号编码：信号由自定义广告技术逻辑按预定的节奏准备。Android 后台作业会执行此逻辑以执行设备端编码，以生成受保护的应用信号的载荷，此载荷稍后可在受保护的竞价期间实时用于广告选择。载荷会安全地存储在设备上，直到发送出去进行竞价。
• 广告选择：如需为用户选择相关广告，卖方 SDK 会发送受保护的应用信号的加密载荷，并配置受保护的竞价。在竞价中，买方自定义逻辑会准备受保护的应用信号以及发布商提供的情境数据（通常在公开出价广告请求中共享的数据），以设计用于广告选择的功能（广告检索、推断和出价生成）。与 Protected Audience 类似，买方在受保护的竞价中向卖方提交广告以获得最终评分。
  • 广告检索：买方会使用受保护的应用信号和发布商提供的情境数据来与用户兴趣相关的工程功能。这些功能用于匹配符合定位条件的广告。超出预算的广告会被滤除。 然后，选择前 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 可以存储或删除广告技术平台根据用户活动（例如应用打开次数、成就、购买活动或应用内时间）定义的受保护应用信号。受保护的应用信号会安全地存储在设备上，并在发送出设备之前进行加密，以便仅在可信执行环境中运行出价和竞价服务，并且具有适当的安全性和隐私控制机制，可以进行解密。与 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) 中运行的受保护竞价期间实时为进一步的特征工程做好准备。

添加、更新或移除信号

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

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

支持的 JSON 命令包括：

• put：为给定键插入或覆盖标量值。
• put_if_not_present：如果尚未存储任何值，则为给定键插入标量值。例如，如果要为给定用户设置实验 ID，并且已有其他应用设置了该 ID，则此选项会很有用。
• extra：向与给定键关联的时序添加元素。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。

Privacy Sandbox on Android 中的广告选择工作流。

广告选择工作流程如下：

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

启动广告选择工作流程

当应用准备好展示广告时，广告技术 SDK（通常是 SSP）会启动广告选择工作流程，方法是使用 getAdSelectionData 调用发送来自发布商的所有相关情境数据和每个买方的加密载荷以包含在要发送到受保护竞价的请求中。它与再营销工作流程使用的 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 个广告），并在将广告返回给卖方做最终选择之前计算出价。

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

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

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

1. BuyerFrontEnd 服务收到广告请求。
2. BuyerFrontEnd 服务向买方的出价服务发送请求。 买方的出价服务运行一个名为 prepareDataForAdRetrieval() 的 UDF，它会构建一个请求，以便从广告检索服务中获取前 k 个候选广告。出价服务会将此请求发送到配置的检索服务器端点。
3. 广告检索服务运行 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 不包含推理服务，因此可通过组合以下各项生成预测结果：

• 使用竞价专用信号输入传入的上下文嵌入。
• 使用额外信号输入传入的私密嵌入。
• 任何非私有嵌入广告技术平台均已从其服务器具体化到广告检索服务的键值对服务中。

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

getCandidateAds() 会返回：

• 候选广告：要传递给 generateBid() 的前 k 个广告。每个广告均由以下部分组成：
  • 呈现网址：用于呈现广告素材的端点。
  • 元数据：买方广告技术平台专有的广告元数据。例如，这可能包含广告系列的相关信息以及定位条件（例如位置和语言）。元数据可以包括在出价期间需要模型分解来运行推断时使用的可选嵌入。
• 其他信号：（可选）广告检索服务可以包含额外信息，例如要在 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 报告提案相同的报告 API（例如 reportImpression()，它会触发平台发送卖方和买方报告）。

买方报告的一个常见用例是获取广告选择期间所用模型的训练数据。除了现有 API 之外，平台还将提供一种特定的机制，用于将事件级数据从平台导出到广告技术服务器。这些出站流量载荷可能包含某些用户数据。

从长远来看，我们正在研究隐私保护解决方案，以解决使用受保护竞价中使用的数据的模型训练，而无需在 TEE 上运行的服务之外发送事件级用户数据。我们将在后续更新中提供更多详细信息。

短期内，我们将提供一种临时方法，从 generateBid() 中导出含噪声的数据。我们为此制定的初始方案如下所示，我们将根据行业反馈改进该方案（包括可能的向后不兼容性更改）。

从技术上讲，其运作方式是：

1. 广告技术平台为要传输的数据定义架构。
2. 在 generateBid() 中，他们构建了所需的出站流量载荷。
3. 平台会根据架构验证出站流量载荷，并强制执行大小限制。
4. 平台会向出站流量载荷增加噪声。
5. 出站流量载荷以传输格式包含在胜出报告中，在广告技术服务器上接收、解码，并用于模型训练。

定义出站流量载荷的架构

为了让平台强制执行不断演变的隐私权要求，出站流量载荷的结构必须平台可以理解。广告技术平台将通过提供架构 JSON 文件来定义其出站流量载荷的结构。该架构将由平台处理，并由出价和竞价服务使用与其他广告技术资源（如 UDF 和模型）相同的机制保密。

我们将提供一个 CDDL 文件来定义该 JSON 的结构。CDDL 文件将包含一组受支持的特征类型（例如布尔值、整数、分桶等的特征）。CDDL 文件和提供的架构都将带有版本编号。

例如，如果出站流量载荷由一个布尔值特征后跟一个大小为 2 的存储分区特征组成，则如下所示：

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

如需详细了解受支持的功能类型集，请参阅 GitHub。

在 generateBid() 中构建出站流量载荷

指定买方的所有受保护的应用信号都可用于其 generateBid() UDF。完成相应操作后，广告技术平台便会创建 JSON 格式的载荷。此出站流量载荷将包含在买方的胜出报告中，以传输到广告技术平台服务器。

此设计的替代方案是在 reportWin()（而不是 generateBid()）中进行出站流量矢量计算。每种方法都需要进行权衡取舍，我们将根据行业反馈最终确定这一决定。

验证出站流量载荷

平台将验证广告技术平台创建的所有出站流量载荷。验证可确保特征值对其类型有效、符合大小约束条件，并且恶意操作者不会试图通过将额外信息封装到其出站流量载荷中，从而破坏隐私控制。

如果出站流量载荷无效，系统会静默地从发送到胜出报告的输入中舍弃该载荷。这是因为我们不希望向任何试图使验证失败的不良行为者提供调试信息。

我们将为广告技术平台提供一个 JavaScript API，以确保其在 generateBid() 中创建的出站流量载荷将通过平台验证：

validate(payload, schema)

此 JavaScript API 完全供调用方用来确定特定载荷是否会通过平台验证。必须在平台中执行实际验证，以防止出现恶意的 generateBid() UDF。

为出站流量载荷添加噪声

在将出站载荷包含在胜出报告中之前，平台会对出站流量载荷进行噪声测试。初始噪声阈值为 1%，并且此值可能会随着时间的推移而变化。平台不会提供特定出站流量载荷是否已添加噪声的指示。

噪声方法是：

1. 平台会加载出站流量载荷的架构定义。
2. 系统将选择 1% 的出站流量载荷用于噪声。
3. 如果未选择出站流量载荷，将保留整个原始值。
4. 如果选择了出站载荷，则每个特征的值都将被替换为该特征类型的随机有效值（例如，对于布尔特征，值为 0 或 1）。

传输、接收和解码用于模型训练的出站流量载荷

经过验证且经过噪声处理的出站流量载荷将包含在 reportWin() 的参数中，并传输到隐私边界之外的买方广告技术平台服务器，以进行模型训练。出站流量载荷将采用传输格式。

如需详细了解所有特征类型和出站流量载荷本身的传输格式，请访问 GitHub。

确定出站流量载荷的大小

出站流量载荷的大小（以位为单位）平衡了效用和数据最少化原则。我们将与业界合作，通过实验确定合适的尺寸。在运行这些实验时，我们会暂时出站数据，且没有位大小限制。实验完成后，系统将移除无位大小限制的额外出站流量数据。

确定大小的方法如下：

1. 最初，我们将在 generateBid() 中支持两种出站载荷：
   1. egressPayload：到目前为止，我们在本文档中介绍过的有大小限制的出站流量载荷。最初，此出站流量载荷的大小为 0 位（意味着验证期间始终会将其移除）。
   2. temporaryUnlimitedEgressPayload：用于大小实验的临时且没有大小限制的出站流量载荷。此出站流量载荷的格式、创建和处理使用与 egressPayload 相同的机制。
2. 其中每个出站流量载荷都有自己的架构 JSON 文件：egress_payload_schema.json 和 temporary_egress_payload_schema.json。
3. 我们提供了实验协议和一组指标，以确定各种出站载荷大小（例如 5、10...位）下的模型利用率。
4. 我们根据实验结果，在实用性和隐私性方面做出正确的权衡取舍，然后确定出站流量载荷大小。
5. 我们将 egressPayload 的大小从 0 位设置为新大小。
6. 在设定的迁移期过后，我们会移除 temporaryUnlimitedEgressPayload，仅留下 egressPayload 的新大小。

我们正在研究用于管理此变更的其他技术保护措施（例如，在 egressPayload 大小从 0 位增加时对其加密）。这些详细信息以及实验协议、实验时间和移除 temporaryUnlimitedEgressPayload 等额外信息将包含在后续更新中。

数据保护措施

我们将对出站流量应用多种保护措施，包括：

1. egressPayload 和 temporaryUnlimitedEgressPayload 都会添加噪声。
2. 为实现数据最小化和保护，temporaryUnlimitedEgressPayload 仅在大小实验期间可用，在实验期间，我们将确定 egressPayload 的正确大小。

权限

用户控制

• 此提案旨在让用户能够以列表形式查看哪些已安装的应用存储了至少一个 Protected App Signal 或自定义受众群体。
• 用户可以屏蔽此列表中的应用并从中移除应用。执行这项操作的作用如下：
  • 清除与应用关联的所有受保护的应用信号和自定义受众群体。
  • 阻止相关应用存储新的 Protected App Signals 和自定义受众群体。
• 用户能够彻底重置 Protected App Signals 和 Protected Audience API。在这种情况下，系统会清除设备上所有现有的受保护应用信号和自定义受众群体。
• 用户还可以选择彻底停用 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 的方法：

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