支援相關應用程式安裝廣告的受保護應用程式信號

本提案須符合 Privacy Sandbox 註冊程序， 認證。如要進一步瞭解認證，請參閱 提供的認證連結。日後對此提案的更新將 說明取得這個系統存取權的需求條件。

「行動應用程式安裝廣告」(又稱為「獲客廣告」) 是一種鼓勵使用者下載行動應用程式的行動廣告。這類廣告通常是根據使用者的興趣和受眾特徵放送，而且經常出現在其他行動應用程式 (例如遊戲、社群媒體和新聞應用程式) 中。使用者點選應用程式安裝廣告後，就會直接導向應用程式商店，可以從中下載應用程式。

舉例來說，如果廣告主想提高一款新的餐點外送行動應用程式在美國的安裝次數，可以指定廣告放送對象是位於美國，而且曾經與其他餐點外送應用程式互動的使用者。

一般實作方式是在廣告技術平台之間納入比對內容、第一方和第三方信號，以便根據廣告 ID 建立使用者個人資料。廣告技術機器學習模型會使用這項資訊做為輸入內容，選擇與使用者相關且最可能促成轉換的廣告。

建議使用下列 API 支援有效的使用者安裝廣告。這些 API 不仰賴跨服務的使用者 ID，能進一步保護使用者隱私：

1. Protected App Signals API：核心是建立與儲存廣告技術提取的特徵，這些特徵代表使用者的可能興趣。廣告技術會儲存自行定義的個別應用程式事件信號，例如應用程式 安裝、初次開啟、使用者動作 (遊戲內等級、成就)、 購買活動或應用程式停留時間信號會寫入並儲存在 裝置，防範資料外洩，而且目前僅適用於 在 Protected Auction 期間儲存指定信號的廣告技術邏輯 啟動的容器
2. Ad Selection API：這項 API 提供用於設定和執行 在受信任的執行環境 (TEE) 中執行的 Protected Auction 廣告技術會擷取候選廣告、執行推論、計算出價，以及執行以下動作： 選出「勝出」廣告同時使用 Protected App Signals 和 發布商提供的即時背景資訊。

，瞭解如何調查及移除這項存取權。

Android 版 Privacy Sandbox 中 Protected App Signals 和廣告選擇工作流程的流程圖。

接下來將簡要介紹 Protected App Signals 如何支援相關的應用程式安裝廣告。本文件的後續章節將詳細說明每個步驟。

• 信號管理：使用者使用行動應用程式時，廣告技術會收錄信號 使用 Protected App Signals API。這些事件會儲存在裝置上受到保護 和自訂目標對象類似，且在受到加密前就已加密 從裝置傳出，只讓出價和競價服務執行 安全可靠的執行環境中 隱私權控制項就能解密這些廣告單元，以便出價及評分廣告。
• 信號編碼：信號是由自訂廣告技術邏輯依預定頻率準備。Android 背景工作會執行這個邏輯 執行裝置端編碼，以產生 Protected App Signals 的酬載 以便稍後在 Protecteded Audience API 期間，即時用於廣告選擇 競價。該酬載在為 競價。
• 廣告選擇：為使用者選取相關廣告，賣方 SDK 傳送 Protected App Signals 的加密酬載並設定 Protected Auction。在競價中，買方自訂邏輯會準備 應用程式信號，以及發布商提供的比對內容資料 (資料) 通常會透過 Open RTB 廣告請求共用)， 用於選擇廣告的功能 (廣告擷取、推論及出價) 內容生成)。與 Protected Audience 類似，買方會將廣告提交至 以便獲得在 Protected Auction 中進行最終評分的賣方。
  • 廣告擷取：買方使用 Protected App Signals， 以發布商提供的比對內容資料來設計特徵 符合使用者興趣的廣告這些功能是用來比對廣告 符合指定條件系統會篩除不符合預算的廣告， 然後選出排名前 K 個廣告進行出價。
  • 出價：買方的自訂出價邏輯會準備發布商提供的比對內容資料和 Protected App Signals 來提取特徵，做為買方機器學習模型的輸入內容，從而在可信任的隱私權保護界線內，對候選廣告進行推論與出價。買方隨後會將所選廣告傳回給賣方。
  • 賣家評分：賣家自訂評分邏輯為廣告評分 並選出勝出的廣告 返回應用程式進行算繪
• 報表：競價參與者會收到相應的勝出報表和落敗報表。為了在勝出報表中納入模型訓練資料，我們正研究合適的隱私權保護機制。

時間表

	開發人員預覽版			Beta 版
功能	2023 年第 4 季	2024 年第 1 季	2024 年第 2 季	2024 年第 3 季
信號管理 API	裝置端儲存 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 支援使用與自訂目標對象委派機制類似的機制來管理信號。使用 Protected App Signals API 時，可以用單一純量值或時間序列的形式儲存信號。時間序列信號可用於儲存使用者工作階段持續時間等資訊。時間序列信號將依循先進先出的逐出規則，確保不超過指定長度。純量信號的資料類型是位元組陣列，時間序列信號個別元素的資料類型亦是如此。每個值都會附上信號儲存應用程式的套件名稱，以及儲存信號用 API 呼叫的建立時間戳記，有關詳情可見信號編碼 JavaScript。這個範例展示了特定廣告技術所擁有信號的結構：

下例呈現的是與 adtech1.com 相關聯的純量信號和時間序列信號：

• 具有 base64 值鍵「A1c」和「c12Z」值的純量信號。此信號儲存庫已由 com.google.android.game_app 在 2023 年 6 月 1 日觸發。
• 兩個應用程式建立的一系列含有「dDE」鍵的信號。

廣告技術會在裝置上獲得分配一定額度的信號儲存空間。信號將有確切的存留時間上限。

如果產生信號的應用程式被解除安裝、禁止使用 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 Signal 建立程序。這項程序稱為委派，並採用 fetchSignalUpdates() API。fetchSignalUpdates() 會接受 URI，然後擷取信號更新清單。具體來說 fetchSignalUpdates() 向指定 URI 發出 GET 要求以擷取 要套用至本機訊號儲存空間的更新清單。擁有的網址端點 買方傳回 JSON 指令清單做為回應

支援的 JSON 指令如下：

• put：插入或覆寫指定鍵的純量值。
• put_if_not_present：如果指定鍵未儲存任何值，則插入該鍵的純量值。比方說 特定使用者的實驗 ID，並避免覆寫已有 ID 的使用者 不同的應用程式設定
• 附加：將元素新增至與指定鍵相關聯的時間序列。 maxSignals 參數指定的是這裡的信號數量上限 這是 Gemini 版 Google Workspace 系列課程之一超過上限時，系統會移除較早的元素。如果索引鍵 包含純量值，會自動轉換為時間序列。
• remove：移除與指定鍵相關聯的內容。

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

所有鍵和值皆為 Base64 編碼。

上述指令可用於插入、覆寫與刪除純量信號，以及插入、附加與完全覆寫時間序列信號。如要刪除與覆寫時間序列信號的特定元素，必須在編碼和壓縮程序中進行；例如，可以在編碼時忽略時間序列中已被較新的值取代或修正的值，並在壓縮程序中刪除這些值。

儲存的信號會自動與執行 擷取要求及該要求回應者 (即 註冊廣告技術) 和請求建立時間。所有信號都是以 Privacy Sandbox 註冊廣告技術的名義儲存，「site」/「origin」URI 必須與註冊廣告技術的資料相符。如果發出要求的廣告技術尚未註冊，要求就會遭到拒絕。

儲存額度與逐出機制

每個廣告技術在使用者裝置上存放信號的空間有限。這個額度是由廣告技術各自定義，因此從不同應用程式整理而來的信號會共用額度。超過額度時，系統會按照先進先出的原則移除較早的信號值來騰出空間。為避免過於頻繁地執行逐出作業，系統會實作批次邏輯來允許透支有限額度，並在逐出邏輯觸發後釋出一些額外空間。

資料傳輸裝置端編碼

為了準備廣告選擇程序需要的信號，每個買方自訂邏輯都能安全存取儲存的個別應用程式信號和事件。Android 系統背景工作每小時會執行一次，執行裝置已下載的個別買家自訂編碼邏輯。個別買家自訂編碼邏輯會加密個別應用程式信號，然後將信號壓縮為符合個別買方額度的酬載。接下來，酬載就會在受保護的裝置儲存空間內受到加密，再傳輸至出價和競價服務。

廣告技術會定義由本身的自訂邏輯處理的信號處理級別。例如，您可以檢測自己的解決方案，捨棄先前的信號，並將來自不同應用程式的類似或增強信號彙整為使用較少空間的新信號。

如果買方尚未註冊信號編碼器，就不會有相應信號準備就緒，也不會有在裝置端管理的信號傳送至出價和競價服務。

我們將在後續更新中提供有關儲存空間、酬載和要求額度的詳細資訊，並進一步說明如何提供自訂函式。

廣告選擇工作流程

在本提案中，廣告技術自訂程式碼只能在 TEE 中執行的 Protected Auction (Ad Selection API) 內存取 Protected App Signals。為了進一步支援促進安裝應用程式的需求，在 Protected Auction 期間，系統會即時擷取候選廣告。這與再行銷情境不同，在再行銷情境中，候選廣告在競價前就已經知曉。

本提案採用與 Protected Audience 提案類似的廣告選擇工作流程，並為支援促進安裝應用程式而做出更新。為了滿足特徵工程和即時廣告選擇的運算要求，應用程式安裝廣告必須在在 TEE 中執行的出價和競價服務上放送。裝置端競價不支援在 Protected Auction 期間存取 Protected App Signals。

Android 版 Privacy Sandbox 的廣告選擇工作流程。

廣告選擇工作流程如下：

1. 賣方的 SDK 傳送 Protected App Signals 在裝置端經過加密的酬載。
2. 賣方的伺服器建立競價設定，並將設定與加密酬載一併傳送至賣方的受信任出價和競價服務，啟動廣告選擇工作流程。
3. 賣方的出價和競價服務將酬載傳遞給參與競價的受信任買方前端伺服器。
4. 買方的出價服務執行買方廣告選擇邏輯。
   1. 執行買方廣告擷取邏輯。
   2. 執行買方出價邏輯。
5. 執行賣方評分邏輯。
6. 顯示廣告並啟動報表。

啟動廣告選擇工作流程

應用程式準備好顯示廣告時，廣告技術 SDK (通常是賣方平台) 啟動廣告選擇工作流程，方法是傳送 要加入請求中的發布商和個別買方加密酬載 使用 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 個廣告)，並在計算出價後，將廣告傳回給賣方進行最終選擇。

Android 版 Privacy Sandbox 中的買方廣告選擇執行邏輯。

在出價之前，買方要先從大量廣告開始著手。為了避免要計算每個廣告的出價而拖慢速度，買方需要先從大量廣告中選出前 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 中，根據這些模型進行預測或產生嵌入。與廣告擷取服務不同，買方的出價服務「不具備」鍵/值服務，不能儲存廣告中繼資料。

廣告擷取服務內含鍵/值服務。廣告技術可以在隱私邊界外，將自身伺服器中的鍵/值組合具現化至此服務。我們將提供 JavaScript API，讓廣告技術可以從廣告擷取服務上執行的 UDF 中讀取鍵/值服務的資料。與買方的出價服務不同，廣告擷取服務「不含」推論服務。

這項設計處理的核心問題，就是如何在廣告擷取與競價過程中進行預測。為了進行這些預測，我們可以利用一種稱為「模式分解」的解決方案。

模型分解

模型分解是一種技巧，具體做法是將單一模型拆成幾部分，然後將這些部分合併來產生預測結果。在促進安裝應用程式的情境中，模型通常會用到三種資料：使用者資料、比對內容資料和廣告資料。

以模型未分解的情況來說，三種資料都會用於訓練單一模型。運用模型分解技巧時，我們則會將模型拆成幾部分。由於只有包含使用者資料的部分具有私密性，所以在買方出價服務的推論服務中，只有這部分模型需要在信任界線中執行。

也就是說，您可以採用以下設計：

1. 從模型中分拆出用來處理使用者資料的「私密部分」，以及一或多個用來處理比對內容和廣告資料的「非私密部分」。
2. 視需要將部分或所有非私密部分做為引數，傳遞至需要進行預測的 UDF。舉例來說，比對內容嵌入是 傳遞至 per_buyer_signals 中的 UDF。
3. 廣告技術也能視需要建立非私密部分的模型，然後將這些模型中生成的嵌入具現化至廣告擷取服務中的鍵/值儲存庫。廣告擷取服務上的 UDF 可以在執行階段擷取這些嵌入。
4. 在 UDF 執行過程中進行預測時，可以透過類似內積的運算，將來自推論服務的私密嵌入，與來自 UDF 函式引數或鍵/值儲存庫的非私密嵌入加以結合，得到最終預測結果。

解釋完這一點後，接下來我們就能更詳細解說每個 UDF，包括用途、整合方式，以及這些 UDF 會如何做出預測來協助選出前 K 個廣告與計算出價。

prepareDataForAdRetrieval() UDF

買方出價服務上執行的 prepareDataForAdRetrieval() 負責建立將傳送至廣告擷取服務的要求酬載，以擷取前 K 個候選廣告。

prepareDataForAdRetrieval() 會取得以下資訊：

• 從 getAdSelectionData 收到的個別買方酬載，其中包含 Protected App Signals。
• 比對內容信號auction_signals (競價資訊) 和 buyer_signals ( 買方信號欄位)。

prepareDataForAdRetrieval() 會執行以下兩項作業：

• 特徵化：如果需要在擷取廣告時進行推論，這個 UDF 就會將收到的信號轉換為特徵，以便在呼叫推論服務時，取得用於擷取的私密嵌入。
• 計算用於擷取的私密嵌入：如果擷取預測 就會使用上述指令對推論服務發出呼叫 功能，並取得私密嵌入，用於在擷取時進行預測。

prepareDataForAdRetrieval() 會傳回：

• Protected App Signals：廣告技術管理的信號酬載。
• 特定競價信號：平台專屬的賣方信號，以及來自 SelectAdRequest 的比對內容資訊，比如 auction_signals 和 per_buyer_signals (包括比對內容嵌入)。這與 Protected Audiences 類似。
• 其他信號：額外資訊，例如從推論服務擷取的私密嵌入。

這項要求會傳送至廣告擷取服務，後者會比對候選廣告，然後執行 getCandidateAds() UDF。

getCandidateAds() UDF

getCandidateAds() 於廣告擷取服務上執行，會接收 prepareDataForAdRetrieval() 在買方出價服務中建立的要求。該服務會執行 getCandidateAds()，透過將要求轉換為一系列查詢、資料擷取操作，並執行自訂商業邏輯和其他自訂擷取邏輯，擷取前 K 個候選廣告以進行出價。

getCandidateAds() 會取得以下資訊：

• Protected App Signals：廣告技術管理的信號酬載。
• 特定競價信號：平台專屬的賣方信號，以及來自 SelectAdRequest 的比對內容資訊，比如 auction_signals 和 per_buyer_signals (包括比對內容嵌入)。這與 Protected Audiences 類似。
• 其他信號：額外資訊，例如從推論服務擷取的私密嵌入。

getCandidateAds() 會執行以下動作：

1. 擷取一組初始候選廣告：使用語言、地理區域、廣告類型、廣告大小或預算等指定條件來篩選候選廣告，擷取一組初始候選廣告。
2. 擷取用於擷取廣告的嵌入：如果需要從鍵/值服務中取得嵌入，才能在擷取時進行預測以選出前 K 個廣告，就必須從鍵/值服務中擷取這些嵌入。
3. 選出前 K 個候選廣告：根據從鍵/值儲存庫擷取的廣告中繼資料，以及買方出價服務發送的資訊，針對篩選出的一組候選廣告計算出輕量級分數，然後根據該分數選出 K 個候選廣告。舉例來說，分數可能是使用者看到廣告後安裝應用程式的機率。
4. 擷取出價嵌入：如果來自鍵/值服務的嵌入 出價程式碼進行預測所需的出價 從鍵/值服務擷取而來

請注意，廣告分數可能是預測模型的輸出內容，例如預測使用者安裝應用程式的可能性。這種產生分數的方式涉及模型分解：由於 getCandidateAds() 是在廣告擷取服務上執行，而且廣告擷取服務不含推論服務，所以預測結果可能是經由結合下列項目產生：

• 使用特定競價信號傳遞的比對內容嵌入 。
• 使用其他信號輸入內容傳遞的私密嵌入。
• 廣告技術已從自家伺服器具現化的任何非私密嵌入 傳入廣告擷取服務的鍵/值服務中

請注意，買方出價服務上執行的 generateBid() UDF 也可能運用自身的模型分解方法預測出價。如果需要從鍵/值服務取得任何嵌入來執行此操作，就必須立即擷取這些嵌入。

getCandidateAds() 會傳回：

• 候選廣告：要傳遞至 generateBid() 的前 K 個廣告。每個廣告包含以下項目：
  • 顯示網址：用於顯示廣告素材的端點。
  • 中繼資料：買方廣告技術專屬的廣告中繼資料。舉例來說 可能包括廣告活動和指定條件 例如地區和語言中繼資料可以包含 需要執行模型分解作業時使用的嵌入 所參照的推論函式
• 其他信號：廣告擷取服務可視需要納入 其他嵌入或垃圾內容信號等額外資訊 位置：generateBid()。

我們正在研究提供廣告評分的其他方法，包括將其做為 SelectAdRequest 呼叫的一部分提供。這些廣告可以透過 RTB 出價要求加以擷取，但須留意在這種情況下，不得使用 Protected App Signals 擷取廣告。我們預期廣告技術會權衡利弊才選出最佳方案，考慮因素包括回應酬載大小、延遲時間、成本和信號可用性。

generateBid() UDF

在擷取期間擷取到一組候選廣告和嵌入後，即可開始在買方的出價服務中進行出價。該服務會執行買方提供的 generateBid() UDF，從前 K 個廣告中選出要出價的廣告，然後傳回廣告與相關出價。

generateBid() 會取得以下資訊：

• 候選廣告：擷取廣告擷取服務傳回的前 K 個廣告。
• 特定競價信號：平台專屬的賣方信號，以及來自 SelectAdRequest 的比對內容資訊，比如 auction_signals 和 per_buyer_signals (包括比對內容嵌入)。
• 其他信號：可在出價時使用的額外資訊。

買方實作的 generateBid() 會執行以下三項作業：

• 特徵化：將信號轉換為可在測試期間使用的功能 推論
• 推論：使用機器學習模型計算預測點閱率、轉換率等值，產生預測結果。
• 出價：結合推論值與其他輸入內容來計算 候選廣告的出價。

generateBid() 會傳回：

• 候選廣告。
• 計算的出價金額。

請注意，用於應用程式安裝廣告的 generateBid()，和用於再行銷廣告的這個函數並不相同。

以下各節將詳細說明特徵化、推論和出價。

特徵化

generateBid() 可以將競價信號轉換為特徵，這些功能 可用於推論來預測點閱率和 轉換率我們也在研究該如何以保護隱私為前提，在勝出報表中納入供模型訓練使用的資料。

推論

計算出價時，一般會使用一或多個機器學習模型進行推論，舉例來說，在計算有效千次曝光出價時，通常會使用模型來預測點閱率和轉換率。

客戶可以提供多個機器學習模型來搭配實作的 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 再行銷流程的一樣。詳情請參閱 出價和競價設定：出價程式碼會是 存放在相同的 Cloud Storage 位置 進行再行銷

報表

本提案使用與 Protected Audience 報表相同的 Reporting API (例如 reportImpression()：會觸發平台 傳送賣方和買方報表)。

常見的買方報表用途是取得訓練資料 對於廣告選擇期間使用的模式除了現有的 API 外，平台 將會提供特定機制 將平台連結至廣告技術伺服器這些輸出酬載可能含有特定使用者 資料。

長期以來，我們一直在研究可解決的隱私權保護解決方案 使用 Protected Auctions 中的資料進行模型訓練，而不傳送事件層級 在 TEEs 上運作的外部服務使用者資料。我們會提供更多詳細資料 請稍後更新

短期內，我們會提供暫時性做法， generateBid()。我們提議的初步提案如下，之後會調整。 因應產業需求 (包括可能與舊版不相容的變更) 提供意見回饋。

嚴格說來，這項程序的運作方式如下：

1. 廣告技術會為想要傳送的資料定義結構定義，
2. 在 generateBid() 中，他們會建構所需的輸出酬載。
3. 平台會根據結構定義驗證輸出酬載，並強制執行 大小限制
4. 平台會在輸出酬載加入雜訊。
5. 輸出酬載會以傳輸格式包含在勝出報表中， 已解碼並用於模型訓練的廣告技術伺服器

定義輸出酬載的結構定義

對平台來說，輸出酬載必須 讓平台能理解的架構廣告技術會定義 輸出結構定義的 JSON 檔案該結構定義 與「出價」相關的所有資訊將由平台處理 和競價服務使用與其他廣告技術資源相同的機制 例如 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。完成這些工作後，廣告技術就會在 YAML 或 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 的新大小。

我們正在調查管理這項異動的其他技術防護機制 (例如當我們從 0 位元增加時，為 egressPayload 加密)。 這些細節，以及實驗時間以及 temporaryUnlimitedEgressPayload -- 將包含在之後的更新中。

接下來，我們將說明如何決定可使用哪些實驗通訊協定 egressPayload。我們的目標是與業界合作，找出在市場上取得平衡的尺寸 公用程式和資料最小化這些實驗的成果是 圖表中的 X 軸是訓練酬載大小 (以位元為單位)， Y 軸代表採用該大小的模型所產生的收益百分比 達成無限大小的基準

我們假設我們要訓練 pInstall 模型，以及我們的訓練資料來源 是我們的記錄，以及我們使用的 temporaryUnlimitedegressPayload 的內容 才會收到快訊廣告技術的通訊協定首先包括離線 實驗：

1. 決定將與 Protected App 搭配使用的模型架構 信號。舉例來說，他們必須判斷 使用模型分解。
2. 定義用於評估模型品質的指標。建議指標為 AUC 損失 和對數損失
3. 定義模型訓練期間要使用的特徵組合。
4. 只要使用該模型架構、品質指標和一組訓練特徵 執行模糊處理研究，判斷 指定要在 PASS 中使用的模型模糊處理研究的建議通訊協定 為：
   1. 使用所有特徵訓練模型並測量實用性；這是 基準。
   2. 針對每個用來產生基準的特徵，使用全部 功能除外。
   3. 測量產生的公用程式。將差異值除以特徵大小 以位元表示；這是該功能預期每位元的公用程式。
5. 決定實驗所需的訓練酬載大小。三 建議 [5、10、15、...、size_of_all_training_features_for_baseline] 位元。每一個都代表 egressPayload 的可能大小 實驗會評估
6. 針對每個可能的尺寸，選取一組小於或等於該大小的特徵 並且根據模糊處理研究的結果，盡可能提高每位元的實用性。
7. 針對每個可能的規模訓練模型，並評估其實用性 以所有特徵訓練的基準模型公用程式百分比。
8. 將結果繪製成圖表，X 軸代表訓練大小 以位元為單位，Y 軸則是 比較該模型與基準的差異

接著，廣告技術可以在即時流量實驗中，使用 透過 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，發生這種情況時 裝置上的信號和自訂目標對象會遭到清除。
• 使用者可以選擇完全停用 Android 版 Privacy Sandbox，包括 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 網址相符的「site」或「origin」網域。
• 廣告技術可以與應用程式或 SDK 合作，提供能 用於驗證 Protected App Signals 的建立狀態。當這項程序委派給合作夥伴時，可以設定 Protected App Signals 的建立需要廣告技術確認。