出價和競價服務

在 Protected Audience 的初始提案中，針對再行銷廣告需求的出價和競價操作會在本機裝置端執行。這項規定可能會有運算需求，但在處理能力有限的裝置上執行運算可能並不實際；若網路延遲導致運算速度過慢，系統可能也無法即時挑選及顯示廣告。

所幸，出價和競價服務 (B&A) 提案大致提到了一個方法，可讓 Protected Audience 運算作業在可信執行環境 (TEE) 內的雲端伺服器上進行，而非在使用者的裝置本機上執行。B&A 提案的宗旨是提供整合式流程，讓您將內容相關廣告和再行銷廣告的需求納入考量。而將運算作業轉移至伺服器上，則有助於釋出裝置的運算週期和網路頻寬，進而讓 Protected Audience 競價獲得最佳成效。

Google 將以開放原始碼的形式提供 B&A 元件。廣告技術人員如有興趣，可以透過支援的公有雲端服務供應商自行代管執行個體。您可以前往 GitHub 進一步瞭解 B&A 提案。請注意，該文件所載日期僅適用於 Chrome 實作項目，我們之後也會發布更多資訊來說明如何與 Android 整合。至於本文件，則將簡介何謂 B&A，並說明 Android 會提供哪些新的 API 來與 B&A 互動。之後文章若有更新，我們會張貼更多技術資訊，說明如何使用這些新的 API。

B&A 服務的適用情況

B&A 提供另一選項，可在廣告技術人員自有的可信伺服器中進行競價，這些伺服器會以 Google 提供的開放原始碼二進位檔執行，而使用者資料仍會保留在裝置上，Google 則會提供 API，以安全的方式將資料轉移至 TEE。詳情請參閱下方的「加密策略」。

也就是說，競價程序的某些環節會在裝置端進行，某些則發生於雲端。以 DSP 的角度來看，自訂目標對象 (包括再行銷廣告活動的候選廣告) 仍會由裝置端以相同的自訂目標對象管理 API 進行管理，就像在裝置上執行競價一樣。從賣方平台的角度看，要求則仍在裝置上觸發，本文件將說明會用到哪些新 API。就每一方而言，在 B&A 呼叫完成後，競價結果的回報作業仍會從裝置上展開。

這當中的主要差別，取決於是在哪個位置執行出價、評分和報表網址產生邏輯。系統會在 TEE 中執行 generateBid()、scoreAd()、reportResult() 和 reportWin() 邏輯，而不是在裝置上執行出價、競價和報表邏輯。買方的出價邏輯和賣方的評分邏輯會在 Protected Audience 競價流程中間，於各自的 B&A 環境中執行：

顯示 Protected Audience 競價流程，以及出價和競價位置的插圖。
Protected Audience 競價流程

資料加密

有了 B&A，自訂目標對象和出價金額這類 Protected Audience 資訊會從裝置傳出，途中經過賣買雙方的廣告技術伺服器，再回到裝置中。因此，平台會加密傳送至 Protected Audience 服務的資料，並且僅允許透過經過認證的服務解密。如要進一步瞭解加密策略，請前往 GitHub。

架構和競價流程

本提案需要用到 GitHub 中詳述的幾個新元件，例如在資料從裝置傳送到 B&A 時。

插圖：顯示下文所述整合式 Protected Audience/內容相關競價流程。
使用出價和競價服務的整合式 Protected Audience/內容相關競價流程。

以下大致說明資料流程：

  1. 賣方在裝置端使用 getAdSelectionData API 收集 Protected Audience 的資訊。
  2. 裝置端的 SDK 傳送要求給賣方廣告服務。這項要求內含內容相關酬載和加密的 ProtectedAudienceInput。
  3. 賣方廣告服務向在 TEE 外執行的買方即時出價 (RTB) 服務傳送要求，以取得候選的內容相關廣告，然後評分並選取勝出的內容相關廣告。
  4. 賣方廣告服務將要求傳送至在 TEE 中執行的 SellerFrontEnd 服務。
  5. SellerFrontEnd 服務將包含買方特定資料的要求傳送至 BuyerFrontEnd 服務。
  6. 買方使用自己的鍵/值服務和出價服務，後者會針對所有考慮進行再行銷的自訂目標對象，產生源自裝置的候選廣告出價。
  7. SellerFrontEnd 服務從自身的鍵/值服務讀取內容，並為候選廣告評分。結果會經過加密並傳回至賣方廣告服務。
  8. 賣方廣告服務將經加密的勝出結果 (以及選用的內容相關結果) 傳回裝置端 SDK。
  9. 在裝置上，賣方使用 processAdSelectionResult API 擷取勝出的廣告，進而解密賣方廣告服務的回應。

如需詳細瞭解各個步驟以及資料加密方式，請前往 GitHub。這些元件的程式碼將透過開放原始碼提供。提供的程式碼會處理從 SellerFrontEnd 服務傳送到 BuyerFrontEnd 服務的聯合要求。

雲端部署作業

廣告技術人員會將 B&A 服務部署至支援的公有雲平台。負責定義可用性服務等級目標的廣告技術人員會管理這些部署作業。

執行競價

如要執行 B&A 競價，第一步是從裝置端的自訂目標對象中收集資料，然後加密並傳送至伺服器端競價。請使用 getAdSelectionData API 執行上述操作：

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData 方法會產生 B&A 元件的必要輸入內容 (例如 BuyerInput 和 ProtectedAudienceInput)，接著加密資料，然後再向呼叫端提供結果。為避免在不同應用程式間發生資料外洩情形，這類資料會涵蓋裝置上所有買方的資訊。如要進一步瞭解這項決策，請參閱「隱私權注意事項」一節。

此 API 會傳回 AdSelectionData 物件：

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

借助這個 AdSelectionData，裝置端 SDK 可以在 POST 或 PUT 要求中加入資料，進而傳送要求給自身的賣方廣告服務：

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

裝置端 SDK 會負責為這項資料編碼。建議您使用可節省空間的解決方案，例如以 multipart/form-data 的形式將要求傳送至賣方廣告服務。

要求啟動後，賣方廣告服務會將要求轉送至在 TEE 中執行的 SellerFrontEnd 服務。設定 SellerFrontEnd 服務時，賣方會提供網域位址清單，這些位址則與其合作買方經營的 BuyerFrontEnd 服務相對應。要求之後會與賣方提供的各種 BuyerFrontEnd 服務建立關聯，好讓買方為所選的候選廣告產生出價。以特定買方的立場看，B&A 只會傳送與該買方旗下自訂目標對象相關的資訊，所以買方之間不會有資料交叉外洩的問題。產生出價之後，這一系列的候選廣告會回到獲選廣告所屬的 SellerFrontEnd 服務。最後，SellerFrontEnd 服務則會將經加密的勝出廣告傳回至裝置。

對賣方廣告服務的要求獲得回應，並傳回裝置之後，平台會提供第二個新的 API 來解密結果，同時提供 AdSelectionOutcome，也就是從當前裝置端競價傳回的同一個物件。

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

報告

報表網址會在 B&A 服務中產生。不過，這些網址的連線偵測 (ping) 還是需要在裝置端觸發，才能回報競價的曝光和互動次數。裝置端 SDK 仍需使用在 B&A 流程期間產生的 AdSelectionId，以便叫用 reportImpression() 和 reportInteraction() API。為回報互動次數而產生的信標和相應網址會涵蓋在加密回應中，因此在解密回應期間，系統會將該事件和網址對應儲存在裝置上。

隱私權注意事項

GitHub 上的瀏覽器出價和競價 API 提案說明了如何將隱私權注意事項納入考量。本提案雖採用 Chrome 的規範，但相同的原則也適用於 Android。

adSelectionData 會經過加密，確保只有 PPAPI 和信任的伺服器能夠存取傳輸中的資料。為降低因 adSelectionData 大小變更而發生資料外洩的風險，我們計劃為所有對 getAdSelectionData API 的呼叫產生相同的 adSelectionData。這表示裝置上的所有 CustomAudience 都會用來建立 adSelectionData。此外，我們也打算管制 GetAdSelectionData 輸入參數，避免對產生的 adSelectionData 造成太大影響。

使用所有裝置端競價資料為全體廣告技術人員產生相同的 adSelectionData，會導致每次呼叫廣告技術伺服器時需傳輸的酬載增加，也可能讓生態系統門戶洞開而遭惡意實體濫用。不過請放心，這些問題已解決，詳見下文「大小注意事項」和「反濫用注意事項」兩節。

大小注意事項

廣告技術用戶端 SDK 應將 adSelectionData 的加密位元組封裝到對賣方伺服器的內容相關廣告呼叫中。為獲取最佳效能，請務必採用最合適的 adSelectionData 大小，確保功能不受任何影響。我們預計引進酬載最佳化最佳化說明中介紹的最佳化做法來縮減 adSelectionData 大小。這些措施包括：

  1. 在 CustomAudience 中新增 ad_render_id，使其以 adSelectionData 傳送，而不使用廣告顯示 URI 和中繼資料。廣告技術人員可以避免在 adSelectionData 中傳送廣告資料，讓此做法發揮最佳效果。在日後推出的版本中，CustomAudience API 也會支援這個做法。
  2. 確保不在 adSelectionData 中傳送 user_bidding_signals。廣告技術人員可以改從自家的鍵/值伺服器中擷取 user_bidding_signals。
  3. 允許買方優先處理傳送CustomAudience。
  4. 允許買方指定賣方的優先順序。
  5. 在幾個固定值區中產生 adSelectionData，藉此管制位元外洩情形，同時減少酬載大小。

我們採取大小最佳化措施時，會遵循上文提及的隱私權注意事項。

反濫用注意事項

如隱私權注意事項中所述，系統會使用裝置上的所有買方資料產生 adSelectionData。

這會讓生態系統門戶大開，潛在的惡意實體或許會新增可能降低效能的詐欺性買方資料、增加酬載以提高成本，或發動其他攻擊。

為防範 adSelectionData 遭到濫用，我們將引進下列措施

  • 允許 CustomAudience 明確指定已核准的賣方和相關優先順序
  • 允許賣方平台在產生的酬載中明確指定買方、買方優先順序和個別買方配額
  • 為賣方平台提供一種機制，定義每次呼叫的買方人數上限，或每個買方的大小上限。

這些措施的設計宗旨，是要讓廣告技術人員定義要與其他哪些廣告技術人員合作，並為可能需要處理的 adSelectionData 酬載設定可接受的上限。我們建議允許賣方在另一次呼叫中指定這份買方名單和優先順序。這個規範將保持不變一段時間，以免有心人士透過重複呼叫公開使用者的其他資料。

上述因應措施仍在討論階段，會隨時間而有所更動。如前所述，為防範濫用和大小限制而採用的所有緩解措施，都必須以遵循隱私權注意事項為前提。