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

本提案必須接受 Privacy Sandbox 註冊程序和認證。如要進一步瞭解認證，請參閱我們提供的認證連結。本提案日後的更新將說明取得此系統存取權的相關規定。

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

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

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

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

1. Protected App Signals API：核心是建立與儲存廣告技術提取的特徵，這些特徵代表使用者的可能興趣。廣告技術會儲存自行定義的個別應用程式事件信號，例如應用程式安裝、初次開啟、使用者動作 (遊戲等級、成就)、購買活動或應用程式時間。系統會在裝置上寫入信號並儲存，避免資料外洩，而且只有在 Protected 競價期間儲存特定信號的廣告技術邏輯可用時，這些信號才會提供給儲存該信號的廣告技術邏輯。
2. Ad Selection API：這個 API 提供一個 API，用於設定及執行在受信任的執行環境 (TEE) 中執行的受保護的競價。在受保護應用程式信號和發布商提供的即時情境資訊中，廣告技術會擷取候選廣告、執行推論、計算出價，並執行評分以選擇「勝出」廣告。

顯示 Android 版 Privacy Sandbox 的保護應用程式信號和廣告選擇工作流程圖。

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

• 信號收錄：當使用者使用行動應用程式時，廣告技術人員會儲存廣告技術定義的應用程式事件，並使用 Protected App Signals API 儲存相關信號，以便放送相關廣告。這些事件會儲存在受保護的裝置端儲存空間 (與自訂目標對象類似)，且會在傳送至裝置前經過加密處理，確保只有在受信任執行環境中執行且具備適當安全性與隱私權控制項的出價和競價服務，才能將事件解密，用於出價和評分廣告。
• 信號編碼：信號是由自訂廣告技術邏輯依預定頻率準備。Android 背景工作會執行這個邏輯，在裝置端執行編碼，產生受保護的應用程式信號酬載，在防護競價期間可即時用於廣告選擇。酬載會先安全地儲存在裝置上，直到傳送競價為止。
• 廣告選擇：如要為使用者選取相關廣告，賣家 SDK 會傳送 Protected App 信號的加密酬載，並設定受保護的競價。在競價中，買方自訂邏輯會準備受保護的應用程式信號以及發布商提供的情境資料 (通常在 Open-RTB 廣告請求中共用資料)，以便設計用於廣告選擇的功能 (廣告擷取、推論和產生出價)。與 Protected Audience 類似，買方會向賣方提交廣告，在 Protected 競價中進行最終評分。
  • 廣告擷取：買方會使用受保護的應用程式信號和發布商提供的比對內容資料，工程與使用者興趣相關的功能。這些功能會用來比對符合指定條件的廣告系統會篩除超出預算的廣告。 系統會選取前 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 可能會儲存或刪除廣告技術定義的受保護應用程式信號，這類信號會根據使用者活動 (例如應用程式開啟、成就、購買活動或應用程式時間等)。受保護的應用程式信號會安全地儲存在裝置上，並在傳送至裝置前加密，因此只有出價和競價服務在受信任執行環境內執行，且由妥善進行出價和隱私權控管作業才能解密。與 Custom Audience API 類似，應用程式或 SDK 無法讀取或檢查儲存在裝置上的信號；沒有任何 API 用於讀取信號值，而且 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，以便在受信任的執行環境 (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，就可以避免覆寫 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 註冊廣告技術的名義儲存，「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 競價的要求。這與再行銷工作流程使用的 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 再行銷流程相同。詳情請參閱出價和競價設定。出價程式碼將位於再行銷所使用的相同雲端儲存空間。

報告

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

買方報表的常見用途之一，就是取得廣告選擇期間所用模型的訓練資料。除了現有的 API 外，平台還會提供特定機制，將事件層級資料從平台輸出至廣告技術伺服器。這些輸出酬載可能包含特定使用者的資料。

長期來看，我們正著手研究隱私權保護解決方案，以便使用 Protected 競價所用資料進行模型訓練，而不會在 TEE 上執行的服務傳送事件層級的使用者資料。我們會在日後的更新中提供其他詳細資料。

短期內，我們將提供暫時的方式，從 generateBid() 輸出雜訊資料。我們針對這項政策的初始提案如下，日後將根據業界的意見回饋改善這項提案 (包括可能不具回溯相容性的變更)。

從技術層面來說，這項做法的運作方式如下：

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

定義輸出酬載的結構定義

為了讓平台強制執行不斷演變的隱私權規定，輸出酬載的結構必須是平台能理解的方式。廣告技術會提供結構定義 JSON 檔案，藉此定義輸出酬載的結構。該結構定義會由平台處理，並會由「出價和競價」服務採用與 UDF 和模型等其他廣告技術資源相同的機制來保密。

我們會提供 CDDL 檔案，以定義該 JSON 結構。CDDL 檔案會包含一組支援的地圖項目類型，例如布林值、整數、值區等。CDDL 檔案和提供的結構定義都會產生版本。

例如，輸出酬載包含單一布林值特徵，後面接著大小二的值區特徵，如下所示：

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，發生這種情況時，系統會清除裝置上現有的所有受保護的應用程式信號和自訂目標對象。
• 使用者可以選擇完全停用 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 的方式。

• 所有廣告技術須註冊 Privacy Sandbox，並提供與所有 Protected App Signals 網址相符的「site」或「origin」網域。
• 廣告技術可與應用程式或 SDK 合作，提供用於驗證保護應用程式信號建立作業的驗證權杖。當這項程序委派給合作夥伴時，可以設定 Protected App Signals 的建立需要廣告技術確認。