Protected Audience：整合指南

在 Android 實作 Protected Audience (舊稱 FLEDGE) 時，通常需要在廣告客戶應用程式、發布商應用程式、賣方和買方之間執行整合作業。本指南適用於打算管理自訂目標對象及執行競價的合作夥伴，包括以買方和賣方身分營運的廣告技術聯播網。不同的廣告活動可能會有不同的目標，部分 Protected Audience 功能也不適用於某些使用情境。本指南嘗試列出必要步驟，盡可能支援更多特殊情況。

如要做好準備執行 Protected Audience 的大規模實際工作環境部署作業，合作夥伴可以透過模擬與其他方的整合點開始測試。為協助您規劃整合作業，這份指南可讓您全面瞭解如何整合 Protected Audience 與 Android 應用程式。這可能包含 Android 版 Privacy Sandbox 開發人員預覽版現階段尚未導入的功能。在這類情況下，我們會提供時間軸指引。

Protected Audience 整合工作流程包含由不同類型廣告技術合作夥伴所驅動的 4 個主要步驟：

  1. 買方建立自訂目標對象。
  2. 廣告選擇程序選出勝出的廣告。
    1. 賣方應用程式啟動廣告選擇程序。
    2. 廣告服務執行買方篩選和出價程式碼。
    3. 廣告服務執行賣方決策程式碼。
  3. 勝出的廣告顯示在賣方的應用程式中。
  4. 廣告曝光報表可供買方和賣方取用。

下圖說明這些步驟：

廣告選擇工作流程的視覺圖表。
Protected Audience 自訂目標對像管理和廣告選擇工作流程。

術語

  • 廣告客戶：透過購買廣告空間的方式與使用者互動的公司。
  • 發布商：銷售自家內容旁邊廣告空間的公司。
  • 買方：協助廣告客戶購買廣告空間的廣告技術公司。
  • 賣方：協助發布商銷售廣告空間的廣告技術公司。
  • 聯播網：同時擔任買方和賣方的廣告技術公司。
  • 自有自營：同時擔任發布商、賣方和買方的公司。
  • 整合服務合作夥伴：您為成功整合 Protected Audience 而需合作的任何公司。

事前準備、與整合服務合作夥伴互動及設定

本節概略說明一組初始活動，協助您瞭解 Protected Audience 的運作方式、如何開始進行 Protected Audience 整合，以及如何在 Protected Audience 實作上與整合服務合作夥伴互動。這些活動可能會同時進行。

這張圖表顯示 Protected Audience 功能的發布指南。
Protected Audience 功能的發布指南。

熟悉 Protected Audience

第一步是熟悉 Protected Audience API 和服務。

  1. 首先詳閱設計提案，熟悉 Protected Audience API 和相關功能。
  2. 詳閱開發人員指南，瞭解如何整合用途所需的程式碼和 API 呼叫，以及與 Protected Audience 整合所需的服務。
  3. 針對 Protected Audience API 的設計和實作、服務和說明文件提供意見回饋。
  4. 註冊以接收最新消息，隨時掌握最新的 Privacy Sandbox 功能。

設定及測試範例應用程式

按照上述指引熟悉 Protected Audience 基本知識後，即可設定及測試範例應用程式。

  1. 準備好開始整合時，請使用最新的 Privacy Sandbox 開發人員預覽版來設定開發環境。
  2. 設定必要的伺服器端點。搭配您偏好的 API 測試解決方案使用模擬範例來啟動這項程序。
  3. 為範例應用程式中的程式碼建立分支版本並加以執行，藉此熟悉自訂目標對象管理工作、廣告選擇工作流程和曝光報表。

與整合服務合作夥伴互動

安排時間與整合服務合作夥伴討論如何測試及採用 Android 版 Protected Audience，包括各方之間傳遞的信號型態。對買方而言，討論內容應涵蓋建立及加入自訂目標對象的策略，其中可包含目標對象定義的討論。與整合服務合作夥伴共同定義整合時程，包括初始測試和採用情形，以及各方在設計中負責的領域。

Beta 版設定 (於第 4 季提供)

為貴機構註冊 Android 版 Privacy Sandbox。註冊屬於必要程序，目的是確保廣告技術開發人員遵循 Privacy Sandbox 的政策規範，並允許廣告技術開發人員在多個 SDK 和網域中定義自己的身分。

架構考量

Protected Audience 針對買方和賣方，推出了在裝置上執行廣告競價的功能。在設計過程中，您和整合服務合作夥伴應將下列幾個重點列入考量：

目標對象和再行銷廣告會儲存在裝置上

相對於現今將廣告完全儲存在伺服器上，目標對象資訊和再行銷廣告會儲存在裝置上。並非仰賴裝置端資料來指定目標的內容相關廣告將繼續保留在伺服器中。廣告技術平台需要擴大範圍，將伺服器和裝置之間流通的廣告需求列入考量。

出價和競價程序會在裝置上進行

除了在伺服器上進行競價之外，廣告技術平台現在也有機會為儲存在裝置上的廣告需求指定價格和評級。

其中一種常見做法是由廣告技術平台以現行方式，為內容相關廣告執行競價。完成競價後，賣方可以選擇在裝置上執行競價，評估儲存在裝置上的再行銷需求。由於這些程序現在是在裝置上執行，請務必記住現有限制，確保競價是按照由不同整合服務合作夥伴設計的端對端方式執行，且符合各種再行銷用途。

資料策略

廣告技術平台應考量用於競價的資料類型。這項資訊現在是從各種來源收集，然後集中儲存在伺服器中。Protected Audience 競價提供多種不同的資料傳入路徑。例如：鍵/值服務會傳送剩餘預算等即時信號做為可信任的信號，而在競價執行期間，賣方則會傳送時段等比對內容訊號。如要進一步瞭解這些信號，請參閱本指南的相關章節。

建構解決方案

使用 Protected Audience 進行競價時，有幾個主要階段。買方必須建立目標對象、提供出價資料、為廣告指定目標對象，以及設定出價。賣方必須設定及觸發競價、為候選廣告評分，並選出勝出者。其中有些階段需要雙方攜手合作，才能確保競價正確執行。以下各節詳細說明各個階段，並明確指出由哪一方負責實作。

買方：建立目標對象

買方通常會管理自訂目標對象。由於自訂目標對象是在裝置端進行管理，因此必須在裝置端叫用用於管理自訂目標對象的 API。

如果您在廣告客戶應用程式中擁有自己的 SDK，可以直接透過 joinCustomAudience() 導入這個程式碼。

若您在裝置上沒有自己的 SDK 程式碼，可以考慮與身兼 SDK 供應商的既有整合服務合作夥伴攜手合作。請找出這個合作夥伴、共同簽訂合約，並決定自訂目標對象的定義和管理流程。無論採用哪種做法，本指南一律使用「買方」一詞。以下是部分做法的範例：

  • 身為買方，讓廣告客戶來定義目標對象。裝置上的整合服務合作夥伴 SDK 可將應用程式事件傳送給買方。符合預先定義的條件時，買方就會傳送訊息至 SDK，以代表買方在用戶端加入該自訂目標對象。
  • SDK 可以直接擁有目標對象。廣告客戶會與 SDK 供應商合作定義目標對象。SDK 會監控應用程式事件，並在適當時機加入該目標對象，然後通知買方已將使用者加入目標對象。

原型再行銷廣告活動：設計自訂目標對象

自訂目標對象是指具有類似興趣，且可對其放送個人化廣告的使用者群組。買方可以根據使用者活動，協助廣告客戶在自家應用程式中建立自訂目標對象。

Protected Audience 會根據廣告客戶定義的特定自訂使用者參與度，為對應的自訂目標對象建立容器。這包含一組可向該目標對象顯示的候選廣告，以及一組可在競價期間用於篩選廣告及指定廣告價格的自訂出價邏輯和資料。

設定和原型

設計須知

買方可透過設定自訂目標對象來支援各種用途。這包括針對指定該目標對象的廣告或廣告活動類型定義出價邏輯、定義候選廣告清單，以及類似的考量事項。本節提供在自訂目標對象中填入及使用部分重要欄位的設計須知。

出價邏輯網址

由於競價會在裝置端執行，因此買方必須部署能夠以 JavaScript 將出價邏輯傳回的端點。我們的開發人員指南說明了必要的方法簽章。出價邏輯可在競價期間存取使用者的特定信號 (如後續章節所述)。如要瞭解出價邏輯和使用者信號的設定方式，請參閱本文後續說明。

使用者出價信號

買方可以使用 UserBiddingSignals 傳入廣告客戶或買方本身已取得的使用者相關資訊，以供日後在裝置上進行競價。這類資訊可能包括：

  • 已將使用者加入的其他目標對象。
  • 廣告客戶對使用者的第一方深入分析。

由於這些信號可在競價期間取得，因此買方可在競價期間執行自訂出價作業，包括：

  • 根據出價信號調整出價。
  • 從競價中篩除特定廣告。

受信任的出價資料

在 Protected Audience 實作過程中，買方可透過鍵/值服務在競價期間存取即時資訊。目前買方和賣方可從任何服務 (包括自己營運的服務) 擷取這些出價信號，但這是暫時性的機制。最常見的例子就是查詢廣告的剩餘預算。在開發期間，您可以模擬這項服務，並且根據這個模擬端點進行開發。如需設定操作說明，請參閱 GitHub 上範例應用程式存放區中的 FledgeServerSpec 目錄。

TrustedBiddingData 欄位是由網址和一組鍵所組成。設計要使用的鍵結構類型時，請考量下列幾點：

  • 其中一個簡單的做法是加入一個鍵，藉此將 1:1 對應至要建立的目標對象。這樣一來，鍵/值服務就能包含與目標對象相關聯的所有相關資訊。
  • 預算和廣告狀態是需要即時考量的重要項目。
  • 可用於競價中設定廣告價格的最高出價金額或其他信號。雖然可以將這些資訊和廣告一起加到 AdData 清單中，但是將這些資訊儲存在鍵/值服務中，更能視需要輕鬆更新。

AdData 清單

建立再行銷廣告活動時，廣告客戶通常會考慮向目標對象中的使用者顯示多種不同類型的廣告，例如根據使用者先前與應用程式的互動情形來宣傳不同的折扣。自訂目標對象會提供內含候選廣告的 AdData 清單。

每則廣告包含的資訊量是由買方決定。請考量以下事項：

  • AdData 清單可透過下列 2 種方式更新：
    • 當應用程式在前景有可見活動時，可在將使用者加入自訂目標對象時啟動清單。
    • 於每日更新期間，擷取作業會在背景啟動。裝置會向 joinCustomAudience 呼叫中內含的 daily_update_url 傳送要求，並預期回應中會包含更新版 AdData 清單。
  • 系統可在競價時要求提供額外的廣告資訊。在競價之前，裝置會將要求傳送至透過 joinCustomAudience 的 trustedBiddingData 欄位提供的買方鍵/值服務。鍵/值服務是買方為 Protected Audience 實作所提供的新服務。如要進一步瞭解這項服務，請參閱下文。
  • 在廣告中加入廣告素材 ID，有助於針對特定廣告素材採取某些動作。舉例來說，廣告客戶可能會暫停特定廣告素材，而您想透過即時鍵/值服務擷取這些廣告素材 ID，然後與 AdData 清單中的廣告進行比對。

AdData 應納入 render_url。勝出再行銷廣告的顯示網址可用來顯示廣告。請考量以下事項：

  • 顯示網址設有 k-anonymity 門檻，因此請避免加入範圍狹窄的參數。我們日後會發布有關此 k-anonymity 門檻的更多資訊。
  • 這個網址應包含顯示廣告所需的所有資訊。舉例來說，如要展示特定產品，請在網址中嵌入產品 ID 做為參數。

設計原型時，renderUri 是唯一的必要欄位，指向廣告要顯示的素材資源。建立解決方案時，您可以忽略 AdData 中的中繼資料欄位。將解決方案移至實際工作環境時，您應考量在產生出價時可使用哪些中繼資料，以便調整出價價格。

啟用時間和到期時間

如果自訂目標對象應該只在預先定義的時間內參與競價，您可以透過啟用時間和到期時間欄位因應這類用途。請注意，啟用時間可延遲的時間長度，以及啟用時間和到期時間之間的差異都設有特定限制。用途範例包括：

  • 流失的使用者 (例如過去 7 天內未曾與廣告客戶應用程式互動的使用者)
    • 使用者每次開啟應用程式時，買方都能呼叫 joinCustomAudience，並將 activation_time 設定為未來 7 天的時間戳記。
    • 如果自使用者上次開啟應用程式起已過 7 天，目標對象就符合出價資格。
  • 季節性目標對象 (僅於不久後的特定時間範圍內有效的目標對象)
    • 買方可以預先定義自訂目標對象，且只能於不久後的預先決定期間參與出價。
    • 舉例來說，假設廣告客戶計劃在美國境內進行 2022 年夏末廣告活動，他們的買方可以呼叫 joinCustomAudience，並將 activation_time 設定為 2022 年 8 月 20 日星期六。如果廣告活動只放送一週，買方可以將到期日設為 2022 年 8 月 27 日，之後平台會在廣告選擇期間篩除這個自訂目標對象，最終當做垃圾收集。

買方和賣方：廣告選擇

在廣告選擇過程中，買方和賣方必須互相合作。這項程序可分為四個步驟：

  1. 賣方定義中介服務策略。
  2. 賣方設定競價並啟動廣告選擇程序。
  3. 買方會透過賣方定義的設定受邀參加競價。系統會執行買方的出價邏輯，以便選取候選廣告並出價。
  4. 系統會執行賣方的決策邏輯，為候選廣告評分，並選出勝出的廣告。

為簡化開發作業，您可以模擬買方和賣方的服務回應，包括出價和評分邏輯，以便專注於開發貼合使用情境的功能。您可以參閱 GitHub 上的 FledgeServerSpec 目錄，取得設定模擬端點的操作說明，或者參閱開發人員指南，瞭解如何覆寫遠端 JavaScript 擷取作業的需求。

賣方：定義中介服務策略

Protected Audience 旨在支援刊登序列中介服務。這個領域仍處於開發階段，如有更多資訊，將會另行提供。現階段，請參閱 Protected Audience 刊登序列中介服務的設計提案。

賣方：設定競價

賣方負責設定競價，並提供廣告選擇程序所需的資訊。賣方可以選擇向所有方或僅向所選方提供資訊。這可能包括您擁有的資訊，或您代表買方納入的資訊。

設定和原型

設計須知

本節提供在廣告選擇設定中填入及使用重要欄位的設計須知。

  • 私人執行環境只會在裝置上提供自訂目標對象廣告，因此在發出內容相關廣告請求之前，必須先考慮其他需求。

  • 啟動廣告選擇工作流程前，請先發送廣告請求，從買方收集資訊。接著再使用這些資訊設定廣告選擇。

  • 由於許多買方都可以在裝置上建立自訂目標對象，因此賣方必須使用自訂目標對象買方欄位，指明要納入程序的特定買方。這份清單有多種建立方式。以下列舉幾個例子：

    • 賣方想要一律納入程序的買家靜態清單。
    • 表明想要參與廣告回應的買方清單。如果賣方與廣告交易平台合作，且可能無法完全掌握所有買方，這個方法就非常實用。

  • 賣方可以透過多種方式將資訊傳入至該程序：

    • 所有買方以及在私人執行階段參與競價的所有賣方均可使用廣告選擇信號欄位。這個欄位可用於提供廣告放送機會的相關資訊，例如廣告大小和廣告格式。
    • 個別買方信號欄位會轉送給特定買方，以便用於出價程序。這項資訊是由買方提供，而賣方必須考慮如何在裝置端取得這項資訊，以便用於廣告選擇。
    • 賣家信號欄位是賣方將資訊傳入至程序的最後方式。賣方會在為廣告評分及篩選廣告時使用這些信號，例如啟用品牌安全檢查功能。

買方：針對廣告版位出價

設定和原型

  • 買方可以將出價邏輯加到 generateBid() JavaScript 函式中，這是由建立 CustomAudience 時設定的 biddingLogicUrl 參數所提供。您可以利用提供的規格設定模擬服務，也可以在實際伺服器上實作這個端點。
  • 如需實作方式和 API 用法詳細說明，請參閱開發人員指南。

設計須知

  • 系統會在裝置端執行出價邏輯，並且即時查詢競價中使用的部分信號。如要瞭解限制條件，請參閱限制清單。
  • 針對某些廣告用途，請務必與賣方合作，確保您在裝置端有多個候選廣告及其出價可列入考量。

設計出價邏輯

買方的出價邏輯必須透過 JavaScript 實作，並在裝置端執行。開發人員指南會提供必要簽章的相關資訊，以及競價期間傳入的各種參數詳細資料。裝置上的出價邏輯可以存取做為參數傳入至 generateBid() 函式的其他資訊。

提供出價資料

透過鍵/值服務提供的即時出價信號

買方可以在競價期間透過自有的鍵/值服務擷取即時信號。您可以在公開的 Privacy Sandbox 存放區中找到這項服務的初始實作方式，也可以自行建立服務。這項服務的網址在自訂目標對象中指定為 trustedBiddingUrl，平台會嘗試擷取這項資料，並利用 trusted_bidding_signals parameter 參數提供給 generateBid 函式。您必須建立自己的鍵結構。

內容比對訊號和使用者信號

在裝置端執行競價時，generateBid 函式可以存取其他使用者信號。這些信號會透過 contextual_signals 和 per_buyer_signals 欄位傳遞。這些欄位都是 JSON 物件，其格式必須由買方和賣方定義。

contextual_signals 欄位含有與使用者相關的資訊。保存這些信號的物件是由 Protected Audience 本身建立，並傳遞至出價邏輯。這個物件目前以空白的形式傳遞。如果您認為與使用者相關的情境脈絡訊號可能切合您的使用情境，請提交意見回饋，讓我們列入考量。

per_buyer_signals 欄位可供出價邏輯使用。賣方會在建立競價設定時設定這些值。買方和賣方需要共同確保這項資料位於裝置端，並可傳送至出價邏輯。這個欄位的部分用途範例包括：

  • 針對品牌安全進行篩選。賣方可以針對請求廣告的應用程式向買方提供相關分類資訊，買方就能利用這項資訊篩除特定廣告。
  • 針對考慮比對內容資訊的機器學習模型傳送 embedding。

賣方：評分並選出勝出的廣告

設定和原型

  • 賣方可以在 scoreAd() JavaScript 函式中加入自己的評分邏輯，這是透過建構 AdSelectionConfig 時設定的 scoringLogicUrl 參數所提供。您可以利用提供的規格設定模擬服務，也可以在實際伺服器上實作這個端點。
  • 如需實作方式和 API 用法詳細說明，請參閱開發人員指南。

設計評分邏輯

賣方以 JavaScript 形式實作評分邏輯，這項作業會在裝置端執行。開發人員指南會提供必要簽章的相關資訊，以及競價期間傳入的各種參數詳細資料。此外，裝置上的評分邏輯可以存取做為參數傳入至 scoreAd 函式的其他資訊。

提供評分資料

透過鍵/值服務提供的即時評分信號

賣方可以在競價期間透過自有的鍵/值服務擷取即時信號。您可以在公開的 Privacy Sandbox 存放區中找到這項服務的初始實作方式。這項服務的網址在競價設定中指定為 trustedScoringUri，平台會嘗試擷取這項資料，並透過 trusted_scoring_signals 參數提供給 scoreAd 函式。您應該建立自己的鍵結構。

內容比對訊號和使用者信號

在裝置端執行競價時，scoreAd 函式可以存取其他使用者信號。這些信號會透過 contextual_signal 欄位傳遞至評分函式。這個欄位保存的 JSON 物件格式是由買方和賣方定義。

contextual_signal 欄位含有與使用者相關的比對內容資訊。保存這些信號的物件是由 Protected Audience 本身建立，並傳遞至評分邏輯。這個物件是以空白的形式傳遞。如果認為與使用者相關的信號可能切合您的使用情境，請提交意見回饋，讓我們列入考量。

賣方：顯示廣告

賣方需要顯示勝出的廣告。如要進一步瞭解勝出廣告顯示方式，請參閱設計提案。這個領域仍處於設計階段。

回報曝光成果

設定和原型

  • 買方和賣方可以在 reportWin() JavaScript 函式中加入報表邏輯，這是分別透過 biddingLogicUrl 或 scoringLogicUrl 參數所提供。您可以利用提供的規格設定模擬服務，也可以在實際伺服器上實作這個端點。
  • 如需實作方式和 API 用法詳細說明，請參閱開發人員指南。

設計須知

買方和賣方必須在各自的 JavaScript 程式碼中實作 reportWin 函式，這段程式碼會從他們設定的端點傳回。這個方法可將資料傳回至伺服器。

此外，Privacy Sandbox 也提供 Attribution Reporting API，可用來管理事件層級及匯總報表。詳情請參閱整合指南。