使用 FLEDGE 支援自訂指定目標對象

提供意見

近期更新

  • 新增自訂目標對象委派作業的提案。
  • 移除每日更新網址的 k-anonymity 規定。

總覽

在行動廣告方面，廣告客戶往往希望根據使用者先前與自家應用程式的互動情形，向可能感興趣的使用者放送廣告。舉例來說，當使用者的購物車中有未結帳的商品，SportingGoodsApp 的開發人員可能會想放送廣告，提醒他們完成購買交易。業界通常使用「再行銷」和「自訂指定目標對象」等字詞來描述這項概念。

目前碰到這類使用情境時，一般採取的做法是向廣告技術平台提供廣告顯示脈絡資訊 (例如顯示廣告的應用程式名稱) 和私人資訊 (例如目標對象名單)。廣告客戶可以利用這些資訊，在自家伺服器上選擇適當的廣告。

為支援常見的互動式使用情境，Android 版 FLEDGE 涵蓋下列適用於廣告技術平台和廣告客戶的 API，並限制跨應用程式分享 ID 的行為，以及控管向第三方提供的使用者與應用程式互動情形資訊：

  1. Custom Audience API：以「自訂目標對象」抽象層 (具有共同意圖的廣告客戶指定目標對象) 為中心。目標對象資訊會儲存在裝置上，並且可以針對目標對象和任意中繼資料 (例如出價信號) 與相關候選廣告建立關聯。這項資訊可用於決定廣告客戶出價、廣告篩選條件和廣告顯示方式。
  2. Ad Selection API：廣告技術平台可考慮儲存在本機的候選廣告，並針對廣告技術平台傳回裝置的候選廣告執行額外處理作業，藉此利用裝置上的信號決定「勝出」的廣告，而 Ad Selection API 提供了一個用於自動化調度管理這項工作流程的架構。
圖 1. Android Privacy Sandbox 中的自訂目標對象管理和廣告選擇工作流程圖。

這項整合服務的運作方式大致如下：

  1. 如果有人將商品加入購物車，卻未在 2 天內完成交易，SportingGoodsApp 會想提醒這些使用者購買商品。因此，SportingGoodsApp 使用 Custom Audience API 將使用者新增至「購物車中有產品」的目標對象名單。該平台會負責管理這份目標對象名單並儲存在裝置上，限制與第三方分享這項資訊的行為。接著 SportingGoodsApp 與廣告技術平台合作，向目標對象名單中的使用者放送廣告。廣告技術平台會管理目標對象名單的中繼資料，還會提供候選廣告，讓系統選擇廣告時納入考量。您可以調整設定，讓該平台在背景中定期擷取最新的目標對象導向廣告。這種方式可確保目標對象導向候選廣告清單維持在最新狀態，而且與出現廣告放送機會時傳送至第三方廣告伺服器的請求 (即內容相關廣告請求) 沒有關聯。

  2. 使用者在同一部裝置上玩 FrisbeeGame 時，可能會看到廣告提醒他們為 SportingGoodsApp 購物車中的商品完成購買程序。為此，包含整合式廣告 SDK 的 FrisbeeGame 可叫用 Ad Selection API，根據可能含有該使用者的任何目標對象名單 (在這個範例中為 SportingGoodsApp 建立的「購物車中有產品」自訂目標對象)，為使用者選擇勝出的廣告。廣告選擇工作流程可經過設定，將擷取自廣告技術平台伺服器的廣告納入考量，而不僅限於與自訂目標對象和其他裝置上信號相關聯的裝置上廣告。廣告技術平台和廣告 SDK 也可以自訂這項工作流程，使用自訂出價和評分邏輯來達成適當的廣告目標。這個做法可讓系統根據使用者的興趣或應用程式互動資料選擇廣告，同時限制與第三方分享這些資料的行為。

  3. 廣告放送應用程式或廣告技術平台的 SDK 顯示所選廣告。

  4. 平台會協助製作曝光和廣告選擇結果報表。這項報表功能與 Attribution Reporting API 相輔相成。廣告技術平台可根據自家報表需求進行自訂。

取得 Android 版 FLEDGE API 的存取權

廣告技術平台必須註冊，才能存取 Android 版 FLEDGE API。詳情請參閱「註冊 Privacy Sandbox 帳戶」。

管理自訂目標對象

自訂目標對象

自訂目標對象代表廣告客戶根據共同意圖或興趣所決定的一群使用者。應用程式或 SDK 可能會使用自訂目標對象來表示特定目標對象，例如「購物車中還有商品」或「已完成遊戲新手關卡」的使用者。平台會負責維護目標對象資訊，並將這些資訊儲存在裝置本機上，而不會公開使用者是屬於哪一群自訂目標對象。自訂目標對象與 Chrome 興趣群組中的 FLEDGE 不同，且無法在網站和應用程式上共用。這有助於限制分享使用者資訊的行為。

廣告客戶應用程式或整合式 SDK 可能根據各種因素 (例如應用程式中的使用者參與度)，加入或退出自訂目標對象。

自訂目標對象中繼資料

每個自訂目標對象都含有下列中繼資料：

  • 擁有者：擁有者應用程式的套件名稱。默示設定為呼叫端應用程式的套件名稱。
  • 買方：負責為這個自訂目標對象管理廣告的買方廣告聯播網。買方也代表可存取自訂目標對象並擷取相關廣告資訊的一方。請以 eTLD+1 格式指定買方。
  • 名稱：自訂目標對象的任意名稱或 ID，例如含有「中途放棄購物者」的使用者。這項屬性有多種用途，例如在廣告客戶的廣告活動中做為其中一項指定條件，或是做為擷取出價程式碼時在網址中使用的查詢字串。
  • 啟用時間和到期時間：這些欄位定義了這個自訂目標對象的效期。平台會使用這項資訊來撤銷自訂目標對象的成員資格。為了限制自訂目標對象的效期，到期時間不得超過特定的最大時間長度。
  • 每日更新網址：平台用於擷取候選廣告，以及「使用者出價信號」和「受信任出價信號」中定義的其他中繼資料的網址欄位。詳情請參閱下方的「擷取適用於自訂目標對象的候選廣告」一節。
  • 使用者出價信號：用於再行銷廣告出價的廣告技術平台專屬信號，例如使用者的概略位置、偏好語言等。
  • 受信任的出價資料：廣告技術平台會根據即時資料來擷取廣告和評分。比方說，廣告可能預算不足，必須立即停止放送。廣告技術可定義用於擷取這項即時資料的網址端點，以及必須對其執行即時查詢作業的一組索引鍵。這項要求會由廣告技術平台管理的受信任伺服器來處理。
  • 出價邏輯網址：平台用於從需求端平台擷取出價程式碼的網址。平台會在廣告競價程序啟動時執行這個步驟。
  • 廣告：適用於自訂目標對象的候選廣告清單。其中包括廣告技術平台專屬的廣告中繼資料，以及用於顯示廣告的網址。自訂目標對象的競價程序啟動時，系統會將這份廣告中繼資料清單納入考量。在可能的情況下，系統會使用每日更新網址端點重新整理這份廣告清單。基於行動裝置的資源限制，單一自訂目標對象中可儲存的廣告有數量限制。

自訂目標對象的委派作業

傳統的自訂目標對象定義和設定，通常會仰賴伺服器端技術，以及廣告技術人員與代理商、廣告客戶和合作夥伴攜手推動整合。FLEDGE 可透過保障隱私權的方式啟用自訂目標對象定義和相關設定。由於「買方」廣告技術人員在應用程式中沒有 SDK，因此需要與有裝置端的廣告技術人員 (例如行動評估合作夥伴 (MMP) 和供應端平台 (SSP)) 合作，這樣才可以加入自訂目標對象。FLEDGE API 旨在針對自訂目標對象管理事宜提供彈性的解決方案，以便支援這些 SDK，具體方法是在裝置端啟用呼叫端，代表買方叫用自訂目標對象建立作業。這項程序就是所謂的「自訂目標對象委派」。如果您要設定自訂目標對象委派作業，請按照以下步驟操作：

加入自訂目標對象

加入自訂目標對象的方法有兩種：

joinCustomAudience()

應用程式或 SDK 可以先使用預期的參數將 CustomAudience 物件例項化，然後呼叫 joinCustomAudience() 來要求加入自訂目標對象。請參考以下說明用的程式碼片段範例：

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchCustomAudience()

應用程式或 SDK 可以使用預期的參數呼叫 fetchCustomAudience()，以便代表沒有裝置端的廣告技術人員要求加入自訂目標對象，如以下範例所示：

CustomAudienceFetchRequest fetchRequest = new CustomAudienceFetchRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchCustomAudience(fetchRequest);

買方擁有的網址端點會在回應主體中以 CustomAudience JSON 物件做出回應，而自訂目標對象的買方和擁有者欄位將遭到忽略 (並由 API 自動填入)。這個 API 還會強制讓每日更新網址也與買家的 eTLD+1 相符。

{
 "name": "running-shoes",
 "activation_time": 1680603133,
 "expiration_time": 1680803133,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": "key1",
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": "key2",
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchCustomAudience() API 會根據 fetchUri 的 eTLD+1 判定買方的身分。CustomAudience 買家的身分用於執行 joinCustomAudience() 所做的註冊和應用程式檢查作業，這無法透過擷取回應變更。CustomAudience 擁有者是呼叫應用程式的套件名稱。請注意，除了 eTLD+1 檢查以外，這裡沒有其他 fetchUri 驗證，尤其沒有 k-anon 檢查。fetchCustomAudience() API 會向 fetchUri 發出 HTTP GET 要求，並預期代表自訂目標對象的 JSON 物件。自訂目標對象物件欄位的必要/選用限制和預設值同樣都會套用至回應。如要瞭解現行的規定和限制，請參閱《開發人員指南》。買方的任何 HTTP 錯誤回應都會導致 CustomAudience 失敗。具體來說，HTTP 狀態回應 429 (「要求數超量」) 會在定義的時段內封鎖來自目前應用程式的要求。系統會將錯誤回報給 API 呼叫端，這些呼叫端的職責是在發生暫時性錯誤 (例如伺服器未回應或逾時) 時重試，或處理永久性錯誤 (例如資料驗證錯誤，或與伺服器通訊時的任何其他非暫時性錯誤)。

有了 CustomAudienceFetchRequest 物件，API 呼叫端就能使用上述範例中的選用屬性，定義自訂目標對象的部分資訊。如果指定的話，買方收到的買方回應就無法覆寫這些值。FLEDGE 會忽略回應中的欄位。在對 fetchUri 提出 GET 要求後，由 API 呼叫端部分定義的 CustomAudience 內容會以 JSON 表示法顯示在特殊標頭 X-CUSTOM-AUDIENCE-DATA 中。自訂目標對象指定的資料大小上限為 8 KB。

由於沒有 k-anon 檢查，因此您可以使用 fetchUri 進行買家驗證，並啟用買方和 SDK 之間的資訊分享功能。為了讓自訂目標對象順利驗證，買方可以提供驗證權杖。裝置端的 SDK 應將這個權杖納入 fetchUri 中，以利買方代管的端點擷取自訂目標對象的內容，並使用驗證權杖來驗證 fetchCustomAudience() 作業確實對應於買方，且是由信任的裝置端合作夥伴發起。如要共用資訊，買家可以和裝置端的呼叫端達成共識，將用於建立自訂目標對象的部分資訊新增為 fetchUri 的查詢參數。這可讓買方稽核呼叫，並偵測惡意廣告技術人員是否已使用驗證權杖建立數個不同的自訂目標對象。

關於驗證權杖定義和儲存空間的注意事項

  • FLEDGE 不會基於任何目的使用驗證權杖，而且您可以選擇是否提供驗證權杖。

    • 買方可能會將驗證權杖用於驗證，確保系統正代表他們建立目標對象。
    • FLEDGE 提案既不用指定驗證權杖的格式，也不用指定將驗證權杖轉移給呼叫端的方式。舉例來說，驗證權杖可在擁有者的 SDK 或後端預先載入，擁有者的 SDK 也可以從買方的伺服器即時擷取該權杖。

退出自訂目標對象

自訂目標對象的擁有者可以呼叫 leaveCustomAudience()，選擇退出自訂目標對象，如下方說明用的程式碼片段所示：

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

為節省儲存空間和其他裝置資源的用量，在經過預先決定的一段時間後，自訂目標對象就會到期，並從裝置上的儲存空間中移除。相關設定的預設值尚待決定。擁有者可以覆寫這個預設值。

使用者控制項

  • 本提案旨在為使用者提供瀏覽已安裝應用程式清單，且建立至少一個自訂目標對象
  • 使用者可以將應用程式從這份清單中移除。移除後會清除與應用程式相關聯的所有自訂目標對象，且應用程式將無法加入新的自訂目標對象。
  • 使用者可以徹底重設 FLEDGE。發生這種情況時，系統會清除裝置上現有的所有自訂目標對象。
  • 使用者可以選擇完全停用 Android 版 Privacy Sandbox，包括 FLEDGE。在這種情況下，FLEDGE API 會傳回標準例外狀況訊息：SECURITY_EXCEPTION

這項功能的設計仍在開發階段，相關詳細資料將於日後更新時提供。

應用程式權限和控制項

本提案旨在讓應用程式控管自訂目標對象：

  • 應用程式可以管理與自訂目標對象的關聯。
  • 應用程式可以授權第三方廣告技術平台，允許其代表應用程式管理自訂目標對象。

這項功能的設計仍在開發階段，相關詳細資料將於日後更新時提供。

廣告技術平台控制項

本提案概述廣告技術可透過哪些方法控管自訂目標對象：

  • 廣告技術會註冊 Privacy Sandbox，並提供符合自訂目標對象所有網址的 eTLD+1 網域。
  • 廣告技術可與應用程式或 SDK 合作，提供用於驗證自訂目標對象建立作業的驗證權杖。當這項程序委派給合作夥伴時，就可以將自訂目標對象建立作業設為需要經過廣告技術確認。
  • 廣告技術可以選擇代表他們停用 joinCustomAudience 呼叫，並只允許 fetchCustomAudience API 啟用所有呼叫自訂目標對象。控制項可在 Privacy Sandbox 註冊期間更新。請注意，這個控制項可允許所有廣告技術，也可以全部不允許。由於平台限制，委派權限不得以個別廣告技術為基礎。

這項功能的設計仍在開發階段，相關詳細資料將於日後更新時提供。

候選廣告和中繼資料回應

買方平台傳回的候選廣告和中繼資料應包含下列欄位：

  • 中繼資料：買方的廣告技術專屬廣告中繼資料。例如廣告活動的相關資訊，以及位置和語言等指定條件。
  • 顯示網址：用於顯示廣告素材的端點。
  • 篩選器：讓 FLEDGE 根據裝置端資料篩選廣告的必要選用資訊。詳情請參閱「買方篩選邏輯」。

廣告選擇工作流程

本提案旨在導入 Ad Selection API，為廣告技術平台自動化調度管理競價執行作業，藉此加強隱私保護。

廣告技術平台目前通常只會在自家伺服器上執行出價和廣告選擇作業。在本提案中，自訂目標對象和其他敏感使用者信號 (例如可用的已安裝套件資訊) 將只能透過 Ad Selection API 存取。此外，就「再行銷」這個用途來說，系統會以跳脫脈絡的方式 (即不考慮廣告顯示情境) 擷取候選廣告。廣告技術平台將需準備在裝置上部署及執行部分現行的競價和廣告選擇邏輯。廣告技術平台可考慮對廣告選擇工作流程進行下列變更：

  • 如果伺服器上沒有可用的已安裝套件資訊，廣告技術平台可考慮將多個內容相關廣告傳回裝置，並叫用廣告選擇工作流程，藉此啟用以應用程式安裝為準的篩選功能，盡可能增加顯示相關廣告的機會。
  • 由於系統會以跳脫脈絡的方式擷取再行銷廣告，因此目前的出價模式可能得經過更新。建議廣告技術平台建立可分開處理廣告功能和比對內容訊號的出價子模式 (可根據雙塔模式建立)，並在裝置上結合子模式輸出內容來預測出價。這可受惠於伺服器端競價和任何廣告放送機會的競價。

這個方法可讓系統根據使用者的應用程式互動資料選擇廣告，同時限制與第三方分享這項資料。

圖 2. 廣告選擇工作流程啟動流程圖。

這個廣告選擇工作流程會依照以下順序，自動化調度管理裝置上的廣告技術所提供 JavaScript 程式碼執行作業：

  1. 執行買方出價邏輯
  2. 篩選及處理買方廣告
  3. 執行賣方決策邏輯

針對涉及自訂目標對象的廣告選擇作業，平台會根據自訂目標對象的「出價邏輯網址」中繼資料所定義的公開網址端點，擷取買方提供的 JavaScript 程式碼。系統也會將賣方決策程式碼的網址端點做為輸入傳遞，藉此啟動廣告選擇工作流程。

不涉及自訂目標對象的廣告選擇工作流程仍在設計中。

啟動廣告選擇工作流程

當應用程式必須顯示廣告時，廣告技術平台 SDK 可以透過呼叫 selectAds() 方法，使用預期的參數將 AdSelectionConfig 物件執行個體化，以啟動廣告選擇工作流程：

  • 賣方：賣方廣告平台的 ID，遵循 eTLD+1 格式
  • 決策邏輯網址：廣告競價流程啟動時，平台會使用這個網址從賣方平台擷取 JavaScript 程式碼，藉此為勝出的廣告評分。
  • 自訂目標對象買方：對競價有自訂目標對象需求的買方平台清單，並採用 eTLD+1 格式。
  • 廣告選擇信號：廣告大小、廣告格式等競價相關資訊。
  • 賣方信號：供應端平台專屬信號。
  • 受信任評分信號網址：賣方受信任信號的網址端點，用於擷取廣告素材專屬即時資訊。
  • 個別買方信號：參與的需求端可利用這項參數為競價提供輸入內容。舉例來說，這項參數可包含有助於決定出價的詳盡脈絡資訊。

在以下說明用程式碼片段中，廣告技術平台 SDK 會先使用 AdSelectionConfig，再叫用 selectAds 來取得勝出的廣告，然後啟動廣告選擇工作流程：

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

買方出價邏輯

出價邏輯通常是由買方平台提供。這個程式碼的用途是為候選廣告決定出價。實際上可能需要套用額外的商業邏輯才能決定出結果。

平台會使用自訂目標對象的「出價邏輯網址」中繼資料來擷取 JavaScript 程式碼，當中應包含以下函式簽章：

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

generateBid() 方法會回傳計算出的出價金額。平台會依序針對所有廣告 (內容相關廣告或再行銷廣告) 叫用這個函式。如果有多個出價邏輯提供者，系統不保證能依提供者的順序執行這項作業。

這個函式預期的參數如下：

  • 廣告：買方出價程式碼所考慮的廣告。這將是符合資格的自訂目標對象廣告
  • 競價信號：賣方平台專屬信號。
  • 個別買方信號：參與的需求端可利用這項參數為競價提供輸入內容。舉例來說，這項參數可包含有助於決定出價的詳盡脈絡資訊。
  • 受信任的出價信號：廣告技術平台會根據即時資料來協助擷取廣告和評分。比方說，廣告活動可能預算不足，必須立即停止放送。廣告技術可定義用於擷取這項即時資料的網址端點，以及必須對其執行即時查詢作業的一組索引鍵。這項要求會由廣告技術平台管理的受信任伺服器來處理。
  • 情境脈絡信號：這可能包含概略時間戳記或大概位置資訊。
  • 使用者信號：這可能包含可用的已安裝套件等資訊。

買方篩選邏輯

買方平台將可根據廣告選擇階段可用的其他裝置信號來篩選廣告。舉例來說，廣告技術平台可導入展示頻率上限。如果有多個篩選提供者，系統不保證能依提供者的順序執行這項作業。

傳回特定廣告的出價值 0，即可導入買方篩選邏輯做為出價邏輯的一部分。

此外，買方平台將可指出應根據 FLEDGE 可用的其他裝置端信號篩選特定廣告，並指出該廣告不會離開裝置。隨著我們強化其他篩選邏輯的設計，買方平台將遵循相同的結構，表明應套用篩選功能。

賣方評分邏輯

評分邏輯通常是由賣方平台提供。這個程式碼的用途是根據出價邏輯輸出結果決定勝出的廣告。實際上可能需要套用額外的商業邏輯才能決定出結果。如果有多個決策邏輯提供者，系統不保證能依提供者的順序執行這項作業。平台會使用 selectAds() API 的「決策邏輯網址」輸入中繼資料來擷取 JavaScript 程式碼，當中應包含以下函式簽章：

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

這個函式預期的參數如下：

  • 廣告：接受評估的廣告；generateBid() 函式的輸出結果。
  • 出價：generateBid()函式的出價金額輸出結果。
  • 競價設定：selectAds() 方法的輸入參數。
  • 受信任的評分信號：廣告技術平台會根據即時資料來篩選廣告和評分。舉例來說，應用程式發布者可能會禁止廣告活動在應用程式中顯示廣告。系統會透過競價設定的受信任評分信號網址參數擷取這項資料。這項要求應由廣告技術管理的受信任伺服器處理。
  • 情境脈絡信號：這可能包含概略時間戳記或大概位置資訊。
  • 使用者信號：這可能包含啟動應用程式安裝事件的應用程式商店等資訊。
  • 自訂目標對象信號：如果接受評分的廣告來自裝置上自訂目標對象，這會包含讀取者和自訂目標對象名稱等資訊。

廣告選擇程式碼執行階段

在本提案中，系統會從可設定的網址端點擷取廣告技術平台提供的競價程式碼，並在裝置上執行。基於行動裝置的資源限制，競價程式碼應遵循下列規範：

  • 程式碼應在預先定義的時間內執行完畢。這項限制將統一套用到所有買方廣告聯播網，相關詳細資料將於日後更新時提供。
  • 程式碼必須為獨立性質，沒有任何外部依附元件。

競價程式碼 (例如出價邏輯) 可能需要存取使用者私人資料 (例如應用程式安裝來源)，因此執行階段不會提供網路或儲存空間的存取權。

程式設計語言

廣告技術平台提供的競價程式碼應以 JavaScript 編寫。這項規定有許多目的，例如讓廣告技術平台可在支援 Privacy Sandbox 的各個平台上共用出價程式碼。

顯示勝出的廣告

得分最高的廣告即為競價勝出者。在本初始提案中，勝出的廣告會傳遞至 SDK 以利顯示。

我們打算改進這項解決方案，確保應用程式或 SDK 無法透過勝出廣告的相關資訊，判斷使用者的自訂目標對象成員資格或應用程式互動記錄 (類似 Chrome 的圍欄頁框提案)。

曝光報表

廣告向使用者顯示後，系統就能向參與的買方和賣方平台回報勝出曝光。平台將依下列順序叫用報表邏輯：

  1. 賣方報表
  2. 買方報表

這可讓買方和賣方平台將重要的裝置上資訊 (例如出價資訊、自訂目標對象名稱等) 傳回伺服器，藉此支援即時預算、出價模式更新和精確計費工作流程等功能。這項曝光報表支援功能與 Attribution Reporting API 相輔相成。

賣方報表

透過賣方的 selectAds() API 決策邏輯網址參數下載供應端提供的程式碼後，平台會在程式碼中叫用 reportResult() JavaScript 函式：

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    return reporting_url, signals_for_buyer;
}

輸出內容：

  • 報表網址：平台會叫用函式傳回的這個網址。

供應端可以將相關信號編碼至報表網址中，以便取得有關競價和勝出廣告的深入分析資訊。比方說，網址中可包含以下信號：

  • 廣告顯示網址
  • 勝出出價金額
  • 應用程式名稱
  • 查詢 ID
  • 買方信號：為了讓供應端和需求端能夠分享資料，平台會將這個回傳值做為輸入參數傳遞給需求端報表程式碼。

買方報表

透過與競價相關聯的自訂目標對象出價邏輯網址中繼資料下載需求端提供的程式碼後，平台會在程式碼中叫用 reportResult() JavaScript 函式：

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

輸入：

  • 系統會從 AuctionConfig 擷取 auction_signals 和 per_buyer_signals。買方平台必須傳遞至報表網址的所有資訊都可能來自這些資料。
  • signals_for_buyer 是賣方 reportResult 的輸出內容。這可讓賣方平台有機會與買方平台分享資料，以便製作報表。
  • contextual_signals 包含應用程式名稱等資訊，custom_audience_signals 則包含自訂目標對象資訊。日後可能會再加入其他資訊。

輸出內容：

  • 報表網址：平台會叫用函式傳回的這個網址。

廣告技術平台管理的受信任伺服器

目前，廣告選擇邏輯必須使用預算使用狀態等即時資訊，才能判斷是否應選擇特定候選廣告進行競價。買方和賣方平台都能從用於維持運作的伺服器取得這項資訊。為了盡可能避免透過這些伺服器洩漏任何機密資訊，本提案設有下列限制：

  • 這些伺服器的行為 (如本節下方內容所述) 不得洩漏使用者資訊。
  • 伺服器不得根據讀取到的資料建立匿名個人資料，即伺服器必須「受信任」。

買方：當買方啟動買方出價邏輯時，平台就會執行 HTTP 擷取作業，從受信任的伺服器擷取受信任的出價資料。這個網址的組成方式，是擷取所處理自訂目標對象的受信任出價信號中繼資料，然後附加當中包含的網址和鍵。系統只會在處理裝置上自訂目標對象的廣告時執行這項擷取作業。在這個階段，買方可以強制執行預算、檢查廣告活動暫停/取消暫停狀態、指定目標及執行其他操作。

以下是用於擷取受信任出價資料的範例網址 (以自訂目標對象的受信任出價信號中繼資料為依據)：

https://www.kv-server.example/getvalues?keys=key1,key2

伺服器的回應應為 JSON 物件，該物件的鍵為 key1、key2 等，值則會提供給買方的出價函式。

賣方：與上述的買方流程類似，賣方可能會想針對系統在競價時考慮的廣告素材擷取相關資訊。舉例來說，發布商可能會想基於品牌安全考量，禁止特定廣告素材顯示在其應用程式中。系統可以擷取這項資訊並提供給賣方競價邏輯。與買方受信任伺服器查詢作業類似，賣方受信任伺服器查詢作業也是透過 HTTP 擷取執行。這個網址的組成方式，是針對必須擷取相關資料的廣告素材取得顯示網址，並將該顯示網址附加到受信任評分信號網址。

以下提供一個範例網址，用於針對系統在競價時考慮的廣告素材擷取相關資訊 (以廣告素材顯示網址為依據)：

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

伺服器的回應應為 JSON 物件，該物件的鍵為要求中傳送的顯示網址。

這些伺服器會以受信任的方式運作，提供多項安全性和隱私方面的優點：

  • 伺服器的各鍵傳回值保證完全以該鍵為依據。
  • 伺服器不會執行事件層級記錄作業。
  • 伺服器不會根據這些要求出現其他副作用。

目前買方和賣方可從任何伺服器 (包括自己營運的伺服器) 擷取這些出價信號，但這是暫時性的機制。在發布版本中，要求只會傳送至受信任的鍵/值類型伺服器。

針對與 Android 版和網頁版 Privacy Sandbox 相容的平台，買方和賣方可使用常見的受信任鍵/值類型伺服器。