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

此提案须遵守 Privacy Sandbox 注册流程，并且 证明。如需详细了解这些证明，请参阅 访问提供的证明链接。此提案的后续更新将 说明了获得该系统访问权限的要求。

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

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

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

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

1. Protected App Signals API：其核心是存储和创建体现用户潜在兴趣的广告技术工程化特征。广告技术平台会存储用户定义的每个应用事件信号，例如应用 安装次数、首次打开次数、用户操作（游戏内关卡、成就） 购买活动或用户在应用内停留的时间信号写入和存储于 以防止数据泄露，并且提供给 在 Protected Auction 竞价期间存储指定信号的广告技术逻辑 在安全环境中运行
2. Ad Selection API：该 API 用于配置和执行 在可信执行环境 (TEE) 中运行的受保护竞价 广告技术平台检索候选广告、进行推理、计算出价，以及 打分，然后选择“获胜”同时使用了 Protected App Signals 和 实时更新环境信息

。 <ph type="x-smartling-placeholder">

</ph>

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

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

• 信号管理：当用户使用移动应用时，广告技术平台会管理信号 存储广告技术平台定义的应用事件，以便使用 Protected App Signals API。这些事件会存储在受保护的设备端 与自定义受众群体类似，并且会先进行加密， 发送出去的设备数据，以便 和适当安全机制和 隐私控制可以解密它们，以用于出价和评分广告。
• 信号编码：信号由自定义广告技术逻辑按预定的节奏准备。Android 后台作业会执行此逻辑 执行设备端编码，以生成 Protected App Signals 的载荷 以便日后在 Protected（受保护）期间实时用于广告选择 竞价。该载荷会安全地存储在设备上，直到 竞价。
• 广告选择：为了为用户选择相关广告，卖方 SDK 发送 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， 旨在避免泄露信号的存在广告技术平台的自定义逻辑可在受保护的情况下访问其管理的信号，以提取在 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，用于处理持久化的信号，使其为 在 Protected Auction 竞价期间实时进行进一步的特征工程 在可信执行环境 (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，则避免将其覆盖 由其他应用设置
• 附加：将元素添加到与给定键关联的时序。 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。

<ph type="x-smartling-placeholder">

</ph>

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 个广告），并在将广告返回给卖方做最终选择之前计算出价。

<ph type="x-smartling-placeholder">

</ph>

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

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

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

1. BuyerFrontEnd 服务收到广告请求。
2. BuyerFrontEnd 服务向买方的出价服务发送请求。 买方的出价服务运行一个名为 prepareDataForAdRetrieval() 的 UDF， 它会构建一个请求，从 Ad Retrieval 获取前 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 再营销流程相同。有关详情，请参阅 出价和竞价配置。出价代码将 与所用存储分区的同一云端存储位置可用 用于再营销。

报告

此提案使用的报告 API 与 Protected Audience 报告 API 相同 提案（例如 reportImpression()，这会触发平台 发送卖方和买方报告）。

买方报告的一个常见用例是获取训练数据 。除了现有的 API 之外，该平台 将提供一种特定的机制，用于将事件级数据从 向广告技术平台服务器传递信息这些出站流量载荷可能包括 数据。

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

在短期内，我们将提供一种临时方式，将噪声数据从 Google Cloud 导出 generateBid()。我们最初的建议如下所示，我们会对其进行改进 （包括可能不向后兼容的更改） 反馈。

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

1. 广告技术平台为其要传输的数据定义架构。
2. 在 generateBid() 中，他们构建所需的出站流量载荷。
3. 平台会根据架构验证出站载荷， 。
4. 平台会向出站流量载荷添加噪声。
5. 出站流量有效负载以传输格式包含在胜出报告中， 广告技术平台服务器进行解码，然后用于模型训练。

定义出站流量载荷的架构

为了让平台强制执行不断变化的隐私权要求，出站流量载荷 采用平台可理解的方式进行结构化处理。广告技术平台会定义 出站流量载荷的结构。架构 将由平台处理，并由出价工具保密 采用与其他广告技术平台资源相同的机制的竞价服务 例如 UDF 和模型

我们将提供定义该 JSON 结构的 CDDL 文件。通过 CDDL 文件将包含一组受支持的功能类型（例如，功能 即布尔值、整数、分桶等）。CDDL 文件和 提供的架构将进行版本控制。

例如，由单个布尔特征组成的出站流量载荷 然后是大小为 2 的分区特征，将如下所示：

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

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

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

指定买方的所有 Protected App Signals 都可供其 generateBid() UDF。这些特征经过特征化后，广告技术平台会在 JSON 格式。此出站流量载荷将包含在 向广告技术平台服务器传输数据的速度

此设计的替代方法是在 Cloud Monitoring 中 reportWin()，而非 generateBid()。每种方式 并根据行业反馈确定最终决定。

验证出站流量载荷

平台将验证广告技术平台创建的所有出站流量载荷。验证 确保特征值对其类型有效，满足尺寸限制， 并且恶意行为者不会试图通过 将其他信息打包到其出站载荷中。

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

我们将为广告技术平台提供 JavaScript API，以确保其 create in generateBid() 将会通过平台验证：

validate(payload, schema)

此 JavaScript API 专供调用者用来确定特定有效负载， 才能通过平台验证。必须在相应平台中完成实际验证， 防范恶意 generateBid() UDF。

对出站流量载荷添加噪声

平台会先对出站流量载荷进行噪声处理，然后再将其纳入胜出报告。 初始噪声阈值为 1%，并且该值可能会随时间而变化。通过 平台不会指出 进行了噪声处理。

添加噪声的方法是：

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

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

经过验证且包含噪声的出站流量载荷将包含 reportWin()，并在不保护隐私的情况下传输给买方广告技术平台服务器 模型训练的边界。出站流量载荷将采用传输格式。

有关所有特征类型和出站流量载荷的有线格式的详细信息 GitHub 上提供。

确定出站流量载荷的大小

出站流量载荷的大小（以位数计）可平衡实用性和数据最少化。 我们将与行业合作，通过 。在运行这些实验期间， 出站流量数据，且无位数限制这些额外的出站流量数据 一旦实验完成，大小限制就会移除。

确定尺寸的方法是：

1. 最初，我们将在 generateBid() 中支持两种出站流量载荷： <ph type="x-smartling-placeholder">
   </ph>
   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 保留新大小。

我们正在调查其他技术保障，以便管理此项变更 （例如，当我们从 0 位增加 egressPayload 的大小时对其进行加密）。 这些细节，以及实验的时间安排和删除内容 temporaryUnlimitedEgressPayload - 将包含在以后的更新中。

接下来，我们将解释一种可行的实验方案，用于最终确定 egressPayload。我们的目标是与业界合作，找到一种能够均衡 实用和数据最少化原则。这些实验将生成的工件是 其中 x 轴是训练载荷的大小（以位为单位）， y 轴表示模型在该规模下带来的收入所占的百分比 设为无大小的基准

假设我们正在训练 pInstall 模型，以及我们的训练数据来源。 是我们的日志和temporaryUnlimitedegressPayload 获得多少价值广告技术平台的协议首先涉及到线下 实验：

1. 确定用于 Protected App 的模型的架构 信号。例如，他们需要确定是否 使用模型分解。
2. 定义用于衡量模型质量的指标。建议的指标为 AUC 损失 和对数损失。
3. 定义模型训练期间将使用的特征集。
4. 利用该模型架构、质量指标和训练特征集， 运行消融研究，确定每个 想要在 PAS 中使用的模型。消化研究的建议方案 ： <ph type="x-smartling-placeholder">
   </ph>
   1. 使用所有特征训练模型并衡量实用性；这是 以进行比较。
   2. 对于用于生成基准的每个特征，使用所有特征来训练模型 除该功能以外的功能。
   3. 衡量产生的效用。将增量除以地图项的大小 以位为单位这是相应功能的预期每比特实用性。
5. 确定实验中感兴趣的训练载荷大小。周三 建议 [5, 10, 15, ..., size_of_all_training_features_for_baseline] 位。每个元素都表示egressPayload 将得到评估。
6. 对于每种可能的大小，选择一组小于或等于该大小的地图项 最大程度提高每比特实用性的大小。
7. 针对每种可能的大小训练模型，并将其效用评估为 基于所有特征训练的基准模型的效用百分比。
8. 在图表上绘制结果，其中 x 轴是训练的大小 而 Y 轴表示应用带来的收益所占的百分比 该模型与基准相比的结果。

接下来，广告技术平台可以使用功能重复实时流量实验中的第 5-8 步。 通过 temporaryUnlimitedEgressPayload 发送的数据。广告技术平台可以选择 使用 Privacy Sandbox 进行线下和实时流量实验的成效 来决定 egressPayload 的大小。

这些实验的时间表，以及设置规模的时间表 针对生成的值，对 egressPayload 进行计数，这超出了本文档的范围 我们会在后续更新中提供此功能。

数据保护措施

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

1. egressPayload和temporaryUnlimitedEgressPayload都会发出噪声。
2. 为了尽可能减少数据和保护数据，temporaryUnlimitedEgressPayload 将 只能在尺寸实验期间使用 确定 egressPayload 的正确大小。

权限

用户控制

• 此提案旨在让用户能够以列表形式查看哪些已安装的应用存储了至少一个 Protected App Signal 或自定义受众群体。
• 用户可以屏蔽此列表中的应用并从中移除应用。执行这项操作的作用如下：
  • 清除与以下项目关联的所有 Protected App Signals 和自定义受众群体 应用。
  • 阻止相关应用存储新的 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。

广告技术平台控制

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

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