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

提供意見

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

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

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

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

**圖 1.** Android Privacy Sandbox 中的自訂目標對象管理和廣告選擇工作流程圖。

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

如果有人將商品加入購物車，卻未在 2 天內完成交易，SportingGoodsApp 會想提醒這些使用者購買商品。因此，SportingGoodsApp 使用 Custom Audience API 將使用者新增至「購物車中有產品」的目標對象名單。該平台會負責管理這份目標對象名單並儲存在裝置上，限制與第三方分享這項資訊的行為。接著 SportingGoodsApp 與廣告技術平台合作，向目標對象名單中的使用者放送廣告。廣告技術平台會管理目標對象名單的中繼資料，還會提供候選廣告，讓系統選擇廣告時納入考量。您可以調整設定，讓該平台在背景中定期擷取最新的目標對象導向廣告。這種方式可確保目標對象導向候選廣告清單維持在最新狀態，而且與出現廣告放送機會時傳送至第三方廣告伺服器的請求 (即內容相關廣告請求) 沒有關聯。
使用者在同一部裝置上玩 FrisbeeGame 時，可能會看到廣告提醒他們為 SportingGoodsApp 購物車中的商品完成購買程序。為此，包含整合式廣告 SDK 的 FrisbeeGame 可叫用 Ad Selection API，根據可能含有該使用者的任何目標對象名單 (在這個範例中為 SportingGoodsApp 建立的「購物車中有產品」自訂目標對象)，為使用者選擇勝出的廣告。廣告選擇工作流程可經過設定，將擷取自廣告技術平台伺服器的廣告納入考量，而不僅限於與自訂目標對象和其他裝置上信號相關聯的裝置上廣告。廣告技術平台和廣告 SDK 也可以自訂這項工作流程，使用自訂出價和評分邏輯來達成適當的廣告目標。這個做法可讓系統根據使用者的興趣或應用程式互動資料選擇廣告，同時限制與第三方分享這些資料的行為。
廣告放送應用程式或廣告技術平台的 SDK 顯示所選廣告。
平台會協助製作曝光和廣告選擇結果報表。這項報表功能與 Attribution Reporting API 相輔相成。廣告技術平台可根據自家報表需求進行自訂。

取得 Android 版 FLEDGE API 存取權

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

管理自訂目標對象

自訂目標對象

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

廣告客戶應用程式或整合式 SDK 可以根據各種因素 (例如使用者在應用程式中的互動情形)，加入或退出自訂目標對象。

自訂目標對象中繼資料

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

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

加入自訂目標對象

應用程式可以使用預期的參數將 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);

退出自訂目標對象

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

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

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

使用者控制項

本提案旨在為使用者提供瀏覽已安裝應用程式清單，且建立至少一個自訂目標對象
使用者可以將應用程式從這份清單中移除。移除後會清除與應用程式相關聯的所有自訂目標對象，且應用程式將無法加入新的自訂目標對象。

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

廣告技術平台權限與控制項

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

應用程式可以管理與自訂目標對象的關聯。
應用程式可以授權第三方廣告技術平台，允許其代表應用程式管理自訂目標對象。
本提案旨在讓使用者完全重設 FLEDGE。發生這種情況時，系統會清除裝置上產生的所有現有自訂目標對象。
本提案也包括讓使用者選擇完全退出 Android 版 Privacy Sandbox，包括 FLEDGE。在這種情況下，FLEDGE API 將失敗，且不會顯示通知。

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

擷取適用於自訂目標對象的候選廣告

買方平台可將使用者互動式候選廣告儲存在裝置上，以便在針對自訂目標對象競價時進行評估。適用於自訂目標對象的候選廣告和相關中繼資料可透過兩種相輔相成的方式擷取。

系統每日擷取：當應用程式加入自訂目標對象後可指定每日更新網址，供平台每天用於查詢。廣告技術平台可使用這項功能確保廣告清單維持在最新狀態，並移除已失效或預算用盡的廣告。
由自訂目標對象擁有者擷取：將使用者加入自訂目標對象後，擁有者可從買方平台擷取候選廣告。傳回的廣告和中繼資料可以儲存在自訂目標對象的「廣告」欄位中。如要立即開始向該使用者放送廣告，建議廣告技術平台使用這項功能。

候選廣告和中繼資料回應

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

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

廣告選擇工作流程

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

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

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

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

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

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

針對涉及自訂目標對象的廣告選擇作業，平台會根據自訂目標對象的「出價邏輯網址」中繼資料所定義的公開網址端點，擷取買方提供的 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 的圍欄框架提案)。

曝光報表

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

賣方報表
買方報表

這可讓買方和賣方平台將重要的裝置上資訊 (例如出價資訊、自訂目標對象名稱等) 傳回伺服器，藉此支援即時預算、出價模式更新和精確計費工作流程等功能。這項曝光報表支援功能與 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 相容的平台，買方和賣方可使用常見的受信任鍵/值類型伺服器。