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

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

此提案須遵守 Privacy Sandbox 註冊程序和認證。如要進一步瞭解認證，請參閱提供的認證連結。這份提案日後的更新內容將說明取得此系統存取權的必要條件。

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

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

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

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

1. Protected App Signals API：核心是建立與儲存廣告技術提取的特徵，這些特徵代表使用者的可能興趣。廣告技術會儲存自訂的個別應用程式事件信號，例如應用程式安裝、初次開啟、使用者動作 (遊戲內等級、成就)、購買活動或應用程式內時間。信號會寫入裝置並儲存在裝置上，以防範資料外洩，且只會提供給在安全環境中執行的 Protected Auction 期間儲存特定信號的廣告技術邏輯。
2. Ad Selection API：提供 API 來設定及執行在受信任的執行環境 (TEE) 中執行的 Protected Auction，廣告技術會擷取候選廣告、執行推論、計算出價，並進行評分，以便使用 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，並結合發布商提供的比對內容資料 (即一般在 OpenRTB 廣告要求中共用的資料)，提取用於廣告選擇 (擷取廣告、推論與產生出價) 的特徵。與 Protected Audience 類似，買方會將廣告提交至賣方，以在 Protected Auction 中進行最終評分。
  • 廣告擷取：買方使用 Protected App Signals 和發布商提供的比對內容資料，提取與使用者興趣相關的特徵。這些特徵是用於比對符合指定條件的廣告。系統會篩除不符合預算的廣告，然後選出排名前 K 個廣告進行出價。
  • 出價：買方的自訂出價邏輯會準備發布商提供的比對內容資料和 Protected App Signals 來提取特徵，做為買方機器學習模型的輸入內容，從而在可信任的隱私權保護界線內，對候選廣告進行推論與出價。買方隨後會將所選廣告傳回給賣方。
  • 賣方評分：賣方的自訂評分邏輯會對參與競價的買方提交的廣告評分，並選擇將勝出廣告送回至應用程式進行轉譯。
• 報表：競價參與者會收到相應的勝出報表和落敗報表。為了在勝出報表中納入模型訓練資料，我們正研究合適的隱私權保護機制。

時間表

管理 Protected App Signals

信號是應用程式中各種使用者互動的表示法，廣告技術會判斷這些互動是否有助於放送相關廣告。應用程式或已整合的 SDK 可能會根據使用者活動 (例如應用程式開啟、成就、購買活動或應用程式內的時間)，儲存或刪除廣告技術定義的 Protected App Signals。Protected App Signals 會安全地儲存在裝置上，並在傳送至裝置前加密，因此只有在 Trusted Execution Environment 中執行的出價和競價服務，才可透過適當的安全性和隱私權控管機制解密，以便出價和評估廣告。與 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) 中執行 Protected Auction 期間，為即時進行進一步特徵工程做好準備。

新增、更新或移除信號

廣告技術可以運用 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，這個指令就能派上用場。
• 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 註冊廣告技術的名義儲存，「site」/「origin」URI 必須與註冊廣告技術的資料相符。如果發出要求的廣告技術尚未註冊，要求就會遭到拒絕。

儲存額度與逐出機制

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

資料傳輸裝置端編碼

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

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

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

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

廣告選擇工作流程

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

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

廣告選擇工作流程如下：

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 個廣告)，並在計算出價後，將廣告傳回給賣方進行最終選擇。

在出價之前，買方要先從大量廣告開始著手。為了避免要計算每個廣告的出價而拖慢速度，買方需要先從大量廣告中選出前 K 個候選廣告，再逐一計算這些廣告的出價。之後，這些廣告和出價就會傳回給賣方，由賣方做出最終選擇。

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 就會將收到的信號轉換為特徵，以便在呼叫推論服務時，取得用於擷取的私密嵌入。
• 計算用於擷取的私密嵌入：如果需要擷取預測結果，這個 UDI 會使用上述特徵對推論服務發出呼叫，並取得用於在擷取時進行預測的私密嵌入。

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 再行銷流程的指定方式完全相同，詳情請參閱「出價和競價設定」。出價程式碼和用於再行銷的程式碼位於相同的雲端儲存位置。

報表

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

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

長期來說，我們正在研究隱私權保護解決方案，以便使用在 Protected Auctions 中使用的資料訓練模型，且不會將事件層級使用者資料傳送至在 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() 中建構傳出酬載

特定買方的所有 Protected App Signals 都會提供給其 generateBid() UDF。這些功能完成後，廣告技術人員會以 JSON 格式建立酬載。這個傳出酬載會納入買家的勝出報表，以便傳送至廣告技術伺服器。

這項設計的替代方案是將出口向量計算作業放在 reportWin() 中，而不是 generateBid()。每種方法都有其利弊，我們會根據業界意見回饋做出最終決定。

驗證輸出酬載

平台會驗證廣告技術建立的任何傳出酬載。驗證可確保功能值符合其類型、符合大小限制，以及惡意人士不會試圖將其他資訊打包至傳出酬載，以破壞隱私權控管機制。

如果外送酬載無效，系統會在傳送至 Win 報表的輸入內容中悄悄捨棄該酬載。這是因為我們不想向任何試圖破壞驗證機制的不肖人士提供偵錯資訊。

我們將提供 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 Signals 的模型架構。舉例來說，他們需要決定是否要使用模型分解。
2. 定義用於評估模型品質的指標。建議的指標是 AUC 損失和對數損失。
3. 定義模型訓練期間會使用的特徵組合。
4. 使用該模型架構、品質指標和訓練功能組合，執行消除法研究，藉此判斷每個模型在 PAS 中每位元提供的效用。建議的消融研究通訊協定如下：
   1. 使用所有功能和評估工具訓練模型，這是比較基準。
   2. 針對用於產生基準的每個特徵，使用除了該特徵以外的所有特徵訓練模型。
   3. 評估產生的效用。將差異值除以特徵的位元大小，即可得出該特徵的預期效用值/位元。
5. 決定實驗的訓練酬載大小。建議使用 [5, 10, 15, ..., size_of_all_training_features_for_baseline] 位元。每個值都代表實驗將評估的 egressPayload 可能大小。
6. 針對每個可能的大小，使用消除法研究結果，選取一組小於或等於該大小的功能，以便盡量提高每位元的效用。
7. 針對每個可能的大小訓練模型，並評估其效用，以百分比表示，與在所有特徵上訓練的基準模型效用相比較。
8. 將結果繪製成圖表，其中 X 軸是訓練酬載大小 (以位元組為單位)，Y 軸是該模型相較於基準值所產生的收益百分比。

接著，廣告技術人員可以使用透過 temporaryUnlimitedEgressPayload 傳送的特徵資料，重複實驗中的步驟 5 至 8。廣告技術公司可以選擇將離線和即時流量實驗的結果與 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，這會清除裝置上現有的 Protected App Signals 和自訂目標對象。
• 使用者可以選擇完全停用 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 的建立需要廣告技術確認。