出價和競價服務整合與最佳化

Android 出價和競價服務的設計提案詳細介紹了使用「受信任的出價和競價」伺服器在 Android 上執行競價的作業和資料流程。為確保傳輸中的資料只能透過隱私權保護 API 和受信任的伺服器處理，系統會使用雙向混合型公開金鑰加密功能，在用戶端和伺服器之間加密資料。

Protected Audience 競價流程。

如要依先前說明執行競價，裝置上的賣家廣告技術必須 請執行下列步驟：

1. 收集及加密伺服器競價資料
2. 向不受信任的賣家服務傳送要求
3. 接收不受信任賣家服務的回應
4. 解密 Protected Audience 競價回應並取得競價結果

為了支援執行伺服器競價，Protected Audience 導入了兩個全新 API：

1. getAdSelectionData API 會收集伺服器競價資料，並產生包含競價資料的加密酬載。「出價和競價」伺服器會使用這個酬載執行競價、產生競價結果，並傳回競價結果。
2. 裝置端廣告技術用戶端可以呼叫 persistAdSelectionResult API，解密伺服器競價產生的結果，並取得勝出的廣告顯示網址。

裝置上的賣家廣告技術需要整合並建構下列項目，才能執行競價：

1. 收集及加密伺服器競價賣家的資料：廣告技術應呼叫 getAdSelectionData API 來取得加密酬載。
2. 向不受信任的賣家服務傳送要求：傳送給不受信任的賣家服務的 HTTP POST 或 PUT 要求 (包含 getAdSelectionData API 產生的加密酬載)，以及該賣家服務產生內容相關結果所需用到的資料。
3. 接收不受信任賣家服務的回應：來自不受信任賣家服務的回應，其中會有加密的 Protected Audience 競價結果，以及內容相關競價結果。
4. 解密 Protected Audience 競價回應並取得競價結果： 如要解密 Protected Audience 競價結果，賣家廣告技術應呼叫 persistAdSelectionResult API。根據 persistAdSelectionResult 可協助廣告技術判斷內容是否 廣告或 Protected Audience 廣告贏得競價，以及勝出的 URI 受保護的目標對象廣告 (如果適用的話)。

支援伺服器競價的功能

我們的目標是支援目前可用於裝置端競價的所有功能，並按照以下時程在伺服器競價中支援這些功能：

	裝置端競價		伺服器競價
	開發人員預覽版	Beta 版	開發人員預覽版	Beta 版
事件層級勝出報表	2023 年第 1 季	2023 年第 3 季	不適用	2023 年第 4 季
刊登序列中介服務	2023 年第 1 季	2023 年第 4 季	不適用	2024 年第 1 季
展示頻率上限篩選功能	2023 年第 2 季	2023 年第 3 季	不適用	2023 年第 4 季
將內容相關廣告傳遞至廣告選擇工作流程，以便篩選	2023 年第 2 季	2024 年第 1 季	不適用	不適用
互動報表	2023 年第 2 季	2023 年第 3 季	不適用	2023 年第 4 季
加入自訂目標對象的委派作業	2023 年第 3 季	2023 年第 4 季	不適用	2023 年第 4 季
非千次曝光出價結帳服務	2023 年第 3 季	2023 年第 4 季
偵錯報表	2023 年第 3 季	2023 年第 4 季	2023 年第 3 季	2023 年第 4 季
公開出價中介服務	不適用	不適用	不適用	2024 年第 1 季
應用程式安裝廣告篩選功能	2023 年第 2 季	2024 年第 1 季	不適用	2024 年第 1 季
貨幣管理	不適用	不適用	不適用	2024 年第 1 季
K-anon 整合	不適用	2024 年第 1 季	不適用	2024 年第 1 季
「私密匯總」整合功能	不適用	不適用	不適用	2024 年第 3 季

使用 Protected Audience API 執行伺服器競價

在開發人員預覽版測試群組中，AdSelectionManager 公開提供了 getAdSelectionData 和 persistAdSelectionResult 這兩個全新 API。這類 API 可讓廣告技術 SDK 與「出價和競價」伺服器整合。

收集及加密伺服器競價資料

getAdSelectionData API 會針對「出價和競價」元件產生必要輸入內容 (例如 BuyerInput 和 ProtectedAudienceInput)，並在將結果提供給呼叫端前加密資料。為避免在不同應用程式間發生資料外洩情形，這類資料會涵蓋裝置上所有買家的資訊。如要進一步瞭解這項決策，請參閱「隱私權注意事項」一節，以及「大小注意事項」一節中有關此主題的最佳化策略。

如要存取 API，您必須啟用 Protected Audience API 存取權，並在呼叫端資訊清單中定義 ACCESS_ADSERVICES_CUSTOM_AUDIENCE 權限。

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. 呼叫端必須在要求中設定 seller 欄位，因為在為要求提供服務前，系統會透過該欄位執行註冊檢查。
2. coordinatorOriginUri 為選填欄位。
   1. 設定後，該位址應等於 協調器網址 部署賣方的 B&A 伺服器。
   2. 協調者必須列於核准的協調者清單中：

      提供者	URI	URI 來源	預設
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	是
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	否

   3. 如果沒有提供協調器起點，系統就會使用預設協調器。
   4. 「協調器」網址不太可能會變更的可能性極低，但我們強烈建議您採用動態管理此網址的機制。這可確保日後在網址上進行任何變更時，不需要建立新的 SDK 版本也能因應。

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

驗證要求後，裝置端買家資料會組成 BuyerInput 和 ProtectedAudienceInput。接著，系統會使用雙向混合型公開金鑰加密功能加密最終酬載物件。

GetAdSelectionDataOutcome

系統會產生 GetAdSelectionDataOutcome 做為 getAdSelectionData API 的結果，其中包含下列項目：

1. adSelectionId：不透明整數，用來標示這個 getAdSelectionData 叫用。廣告技術用戶端應保留這個 adSelectionId 值，因為該值會做為 getAdSelectionData 呼叫的指標。persistAdSelectionResult API 必須使用這組 ID，才能將「出價和競價」伺服器的競價結果解密，而 reportImpression 和 reportEvent API 也需要這組 ID。
2. adSelectionData：此為加密的競價資料，「出價和競價」伺服器需要此資料才能執行競價。這個方法包含：
   1. 經篩選的 Custom Audiences 資料，篩選依據包括 Custom Audiences 的展示頻率上限、應用程式安裝篩選條件，以及伺服器競價規定。
   2. 應用程式安裝資料 (在日後推出的版本提供)。

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

錯誤、例外狀況和失敗處理

如果因引數無效、逾時或資源消耗過多等因素，而無法順利完成廣告選擇資料的產生作業，OutcomeReceiver.onError() 回呼會提供具有以下行為的 AdServicesException：

1. 如果用於將 getAdSelectionData 初始化的引數無效，AdServicesException 會指出 IllegalArgumentException 為錯誤原因。
2. 發生其他錯誤時，收到的 AdServicesException 則會指出 IllegalStateException 是錯誤原因。

向不受信任的賣家服務傳送要求

借助 AdSelectionData，裝置端 SDK 可以在 POST 或 PUT 要求中加入資料，進而向其賣家的廣告服務傳送要求：

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

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

接收不受信任賣家服務的回應

如「出價和競價」伺服器說明所述，不受信任的賣家服務會在收到要求時，針對內容相關廣告向合作夥伴買家發出呼叫。

不受信任的賣家服務會將經過加密的 adSelectionData 和 AuctionConfig 轉送至「出價和競價」伺服器的 SellerFrontEnd 服務 (在 TEE 中執行)。

Protected Audience 競價完成後，SellerFrontEnd 服務會加密競價結果並將其傳回，做為對不受信任賣家服務的回應。

不受信任的賣家服務會將回應傳送到裝置，其中包含內容相關廣告和/或加密的 Protected Audience 競價結果。

收到回應後，裝置上的賣家廣告技術程式碼就可以選擇只在回應中使用內容相關廣告；如果認為取得 Protected Audience 結果較有價值，則可以選擇呼叫 PersistAdSelectionResult API 來解密 Protected Audience 結果。

PersistAdSelectionResult API

如要解密 Protected Audience 結果，賣家廣告技術可以呼叫第二個 Protected Audience API persistAdSelectionResult。API 會將結果解密，並傳回 AdSelectionOutcome，也就是目前從裝置端競價傳回的物件。

如要存取 API，呼叫端必須啟用 Protected Audience API 存取權，並在自身的資訊清單中定義 ACCESS_ADSERVICES_CUSTOM_AUDIENCE 權限。

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

呼叫端必須在要求中設定以下項目：

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId：getAdSelectionData 呼叫產生的不透明 ID，呼叫端需要解密該呼叫的結果。
2. seller：必須在要求中設定的賣家廣告技術 ID，用於在為要求提供服務前執行註冊檢查。
3. adSelectionResult：呼叫端要解密的「出價和競價」伺服器產生的加密競價結果。

AdSelectionOutcome 回應

如果有 Protected Audience 勝出者，那麼 AdSelectionOutcome 會傳回勝出的廣告顯示 URI。一旦 adSelectionResult 解密之後，報表資料就會保留在內部。OutcomeReceiver.onResult() 回呼會傳回包含以下內容的 AdSelectionOutcome：

• URI：如果有勝出的 Protected Audience 廣告，系統會傳回勝出廣告的廣告顯示網址。如果沒有 Protected Audience 勝出者，系統則會傳回 `Uri.EMPTY。
• adSelectionId：與此伺服器競價執行作業相關聯的 adSelectionId。

錯誤、例外狀況和失敗處理

如果因引數無效、逾時或資源消耗過多等因素，而無法順利完成廣告選擇資料的產生作業，OutcomeReceiver.onError() 回呼會提供具有以下行為的 AdServicesException：

1. 如果用於將 getAdSelectionData 初始化的引數無效，AdServicesException 會指出 IllegalArgumentException 為錯誤原因。
2. 發生其他錯誤時，收到的 AdServicesException 則會指出 IllegalStateException 是錯誤原因。

隱私權注意事項

adSelectionData 會經過加密，確保只有 PPAPI 和信任的伺服器能夠存取傳輸中的資料。

儘管已加密，資料仍可能因 adSelectionData 大小的關係而外洩。adSelectionData 大小可能各異，原因如下：

1. 裝置上的 CustomAudience 資料有所變更。
2. CustomAudience 篩選邏輯有所變更。
3. 輸入至 getAdSelectionData 呼叫的內容有所變更。

adSelectionData 大小的變更可用來產生跨應用程式 ID，如 1 位元外洩情形的討論所述。許多 1 位元外洩情形適用的緩解措施同樣也能用在這裡。

為了管理這些外洩情形，我們計劃為所有對 getAdSelectionData API 的呼叫產生相同的 adSelectionData。在初始版本中，裝置上的所有 CustomAudiences 都會用來建立 adSelectionData，已加密的酬載則會填充，藉此遮蓋大小變化版本。此外，我們也會管制 GetAdSelectionData 輸入參數，避免對產生的 adSelectionData 造成太大影響。

不過，使用所有的廣告技術adSelectionData 裝置端競價資料會建立大量酬載，現在需要進行移轉 對廣告技術伺服器的呼叫使用裝置端自訂目標對象來產生競價酬載，也會使生態系統更容易遭惡意實體濫用。我們會在下方的「大小最佳化」和有關如何緩解濫用情況的章節中說明這些問題。

大小最佳化

廣告技術用戶端 SDK 應將 adSelectionData 的加密位元組封裝到對廣告技術伺服器發出的 HTTP PUT/POST 內容相關呼叫中。為減少封包往返的延遲時間和成本，請務必在不影響實用性的前提下，盡可能縮減 adSelectionData 的大小。

有鑑於此，我們計劃研發可縮減 adSelectionData 大小的最佳化功能，並可能在後續推出的版本中導入，包括：

1. 在設有邊框間距的一組固定值區大小中產生酬載：為了盡可能減少大小變化版本造成的外洩情形，同時仍保持較低的酬載，建議您針對產生的酬載使用固定的大小值區。將值區數量控制在較少的範圍內 (例如 7 個)，可使每次呼叫 getAdSelectionData 時外洩的熵少於 3 位元。

   如果裝置端資料超過值區大小上限，系統會利用下文提到的策略 (例如優先順序值) 決定要捨棄哪些資料。

2. 買家設定：我們正在評估讓買家調整個別買家酬載設定的可行性。這項設定有助於找出買家有興趣加入哪些競價。如果可行的話，買家廣告技術就能在註冊期間註冊端點，讓 Protected Audience 每天定期擷取酬載設定。或者，隱私權保護 API 也可以公開 API，讓買家廣告技術註冊這個端點。

   系統為每個 getAdSelectionData 要求產生 adSelectionData 後，這項設定接著會用於評估買家對其之貢獻。

   買家酬載設定可允許買家指定以下內容：

   1. 賣家許可清單：只有在 getAdSelectionData 呼叫是由許可清單中的賣家發起時，系統才會將買家 CustomAudiences 新增至酬載。我們會每天定期擷取酬載設定，讓許可清單保持在最新狀態。
   2. 個別賣家大小限制：買家可以指定個別賣家的大小限制，進而決定在特定賣家發起競價時，酬載中要傳送的資料大小。如果買家想投入更多資源來處理特定賣家的競價資料，這就非常實用。SellerFrontendService 只會將買家專屬資料轉送至各個 BuyerFrontendService。因此，透過定義個別賣家的大小限制，買家就可以明確控制其「出價和競價」伺服器的 BuyerFrontendService 對賣家執行的競價所擷取及處理的資料量。

3. 賣家設定：我們正在評估個別賣家競價設定的可行性，讓賣家定義競價參數來控管酬載大小和競價參與者。如果可行的話，買家廣告技術就能在註冊期間指定端點，讓 Protected Audience 定期擷取個別買家競價設定。系統為每個 getAdSelectionData 要求產生 adSelectionData 後，這項設定接著會用於決定其組合和限制。

   與買家設定類似，個別賣家設定可讓賣家指定預計在競價中查看哪一組買家，並針對每位買家對酬載大小的貢獻指定限制。

   賣家競價設定可允許賣家指定以下內容：

   1. 買家許可清單：如果是由特定賣家發起的競價，只有許可清單中的買家才能為競價貢獻 CustomAudiences。競價設定將需每天更新，好讓該許可清單與伺服器端的買家許可清單一樣保持在最新狀態。
   2. 個別買家大小限制：賣家可以指定個別買家限制，針對傳送至 SellerFrontendService 的酬載管制每位買家上傳至其中的資料大小。如果買家超出個別買家大小限制，系統會使用買家酬載設定中指定的 CustomAudience 優先順序，在預期限制範圍內取得資料。
   3. 個別買家優先順序：允許賣家設定個別買家的優先順序。如果酬載大小超過酬載大小限制，系統會利用買家優先順序來確認酬載中應保留哪些買家資料。
   4. 酬載大小上限：不同賣家可能會有不同的資源分配方式，或許也會希望為每次要求的競價酬載設定上限。這個上限將以 Protected Audience API 設定的固定大小值區為依據。

4. 自訂目標對象變更

   1. 指定自訂目標對象優先順序：允許買家在自訂目標對象中指定優先順序值。如果買家的自訂目標對象組合超過個別賣家/買家的大小限制，priority 欄位可用來判別應納入競價中的自訂目標對象。自訂目標對象中未指定的優先順序值會預設為 0.0。

5. 酬載資料變更

   1. 減少酬載中傳送的資料：如出價和競價服務酬載最佳化所述，較高的酬載是由自訂目標對象的 ads 資料、使用者出價信號，以及 Android 信號所驅動。您可以透過下列方式調低這類酬載：
      1. 讓用戶端在酬載中傳送廣告顯示 ID (而非廣告物件)。
      2. 讓用戶端不要在酬載中傳送廣告資料。
      3. 不要在用戶端酬載中傳送使用者出價信號。

上述策略雖可讓廣告技術定義各項設定，以便管理 adSelectionData 酬載組合和限制，但這些策略也可能成為因變更設定參數而導致調節 adSelectionData 大小的因素。為了避免這種情況，Protected Audience 每天都會從已設定的端點擷取設定。

延遲時間最佳化

為了讓伺服器競價具有一定程度的實用性，我們需要確保 getAdSelectionData API 和 persistAdSelectionResult API 每次呼叫的延遲時間不得過長。雖然我們的目標是在 2023 年為 API 提供功能支援，但在後續版本中會以 API 的延遲基準和最佳化為重中之重。

我們正在研究以下策略，確保延遲時間不會超過許可上限：

1. 為個別賣家預先產生 Protected Audience 資料：由於賣家競價設定和買家酬載設定會保持穩定一段相當長的時間 (一整天)，因此平台可能會預先運算並儲存符合條件的 Protected Audience 資料。

   這會需要平台建構機制來監控自訂目標對象的更新，並依據更新修改預先產生的 Protected Audience 資料。平台也需要宣告賽跑時的服務等級目標 廣告技術從自訂目標對象更新到看見 為伺服器競價產生的 adSelectionData 變化。

   由於裝置提供的資源運算模型有限，且程序優先順序不同，因此我們深知若要提供這個預先產生的功能，必須同時提供高度穩定性和服務等級目標保證。

   這樣一來，系統便會根據以下幾點原因預先產生 Protected Audience 資料：

   1. 賣家選擇預先產生 Protected Audience 資料。
   2. 買方符合條件，可參與由特定賣家發起的競價。
   3. 根據以下條件找出每個買家要做為酬載中一部分的自訂目標對象：
      1. 賣家設定中定義的個別買家大小限制、個別買家優先順序和大小上限。
      2. 買家設定中定義的個別賣家大小限制和自訂目標對象優先順序。

2. 積極套用排除篩選功能：如果賣家偏好使用此功能，平台可能會預先產生 Protected Audience 資料，並套用排除關鍵 getAdSelectionData 呼叫的篩選功能，藉此預先運算 adSelectionData。這樣一來，賣家就可以在縮短延遲時間和接受過時的排除篩選功能間取得平衡。

   平台可以在賣家設定中提供設有過時期限的預設選項，並在 getAdSelectionData 中提供覆寫選項，藉此提供這項支援，並在需要時支援最新運算。或者，平台也可以提供要在 getAdSelectionData 之前呼叫的額外初始化 API 來準備競價。

3. 多個競價的酬載運算：在某些情況下，最好能使用具有延遲性能的 API，儘管代價是導致更多資料過時也一樣。為提供此功能，平台可能會導入初始化 API 來計算整個酬載，並向呼叫端提供已運算酬載的參照。

   至於後續對 getAdSelectionData 的呼叫，呼叫端可以提供預先運算酬載的參照，以便用於產生 adSelectionData。

上述三個策略都處於最初研究階段，旨在說明平台將延遲時間最佳化時，可能採取何種方向。隨著我們深入探討 API 和廣告技術需求的延遲時間資料，也會繼續提供其他策略。

緩解及辨識濫用情況

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

不過，如果裝置上的所有買家資料都是用來產生 adSelectionData 輸出，那麼惡意實體可能會假冒成買方， 建立詐欺性的買家資料，藉此降低 Android 效能、增加酬載， 增加廣告技術執行競價或出價等方面的成本

因應措施

我們在「大小注意事項」一節提到的某些措施 (例如含有許可賣家的買家酬載設定，以及含有許可買家的賣家競價設定)，對於排除酬載中的意外資料十分有用。

其他相關措施 (例如允許賣方平台指定買家優先順序、在產生的酬載中設定個別買家配額，以及為每個競價酬載設定大小上限) 也有助於緩解惡意酬載增加所造成的影響。這些措施的宗旨，是讓廣告技術定義要與哪些廣告技術合作，並為可能需要處理的酬載設定可接受的上限。

如前所述，為防範濫用和大小限制而採用的所有緩解措施，都必須以遵循隱私權注意事項為前提。

找出惡意實體

雖然上述緩解措施可保護伺服器競價的 adSelectionData 產生作業，但卻無法協助找出惡意實體或防止平台受到濫用行為侵害，例如透過買家建立空前數量的自訂目標對象。

為確保平台穩定性和健康度，我們需要找出一個機制來識別惡意實體、判別濫用行為媒介，以及確認特定攻擊背後的動機。在後續版本中，我們將透過說明，詳細介紹可能的濫用行為媒介和相應防護措施。