在 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 環境中執行:
資料加密
有了 B&A,自訂目標對象和出價金額這類 Protected Audience 資訊會從裝置傳出,途中經過賣買雙方的廣告技術伺服器,再回到裝置中。因此,平台會加密傳送至 Protected Audience 服務的資料,並且僅允許透過經過認證的服務解密。如要進一步瞭解加密策略,請前往 GitHub。
架構和競價流程
本提案需要用到 GitHub 中詳述的幾個新元件,例如在資料從裝置傳送到 B&A 時。
以下大致說明資料流程:
- 賣方在裝置端使用
getAdSelectionData
API 收集 Protected Audience 的資訊。 - 裝置端的 SDK 傳送要求給賣方廣告服務。這項要求內含內容相關酬載和加密的
ProtectedAudienceInput
。 - 賣方廣告服務向在 TEE 外執行的買方即時出價 (RTB) 服務傳送要求,以取得候選的內容相關廣告,然後評分並選取勝出的內容相關廣告。
- 賣方廣告服務將要求傳送至在 TEE 中執行的 SellerFrontEnd 服務。
- SellerFrontEnd 服務將包含買方特定資料的要求傳送至 BuyerFrontEnd 服務。
- 買方使用自己的鍵/值服務和出價服務,後者會針對所有考慮進行再行銷的自訂目標對象,產生源自裝置的候選廣告出價。
- SellerFrontEnd 服務從自身的鍵/值服務讀取內容,並為候選廣告評分。結果會經過加密並傳回至賣方廣告服務。
- 賣方廣告服務將經加密的勝出結果 (以及選用的內容相關結果) 傳回裝置端 SDK。
- 在裝置上,賣方使用
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
大小。這些措施包括:
- 在
CustomAudience
中新增ad_render_id
,使其以adSelectionData
傳送,而不使用廣告顯示 URI 和中繼資料。廣告技術人員可以避免在adSelectionData
中傳送廣告資料,讓此做法發揮最佳效果。在日後推出的版本中,CustomAudience API
也會支援這個做法。 - 確保不在
adSelectionData
中傳送user_bidding_signals
。廣告技術人員可以改從自家的鍵/值伺服器中擷取user_bidding_signals
。 - 允許買方優先處理傳送
CustomAudience
。 - 允許買方指定賣方的優先順序。
- 在幾個固定值區中產生
adSelectionData
,藉此管制位元外洩情形,同時減少酬載大小。
我們採取大小最佳化措施時,會遵循上文提及的隱私權注意事項。
反濫用注意事項
如隱私權注意事項中所述,系統會使用裝置上的所有買方資料產生 adSelectionData
。
這會讓生態系統門戶大開,潛在的惡意實體或許會新增可能降低效能的詐欺性買方資料、增加酬載以提高成本,或發動其他攻擊。
為防範 adSelectionData
遭到濫用,我們將引進下列措施
- 允許
CustomAudience
明確指定已核准的賣方和相關優先順序 - 允許賣方平台在產生的酬載中明確指定買方、買方優先順序和個別買方配額
- 為賣方平台提供一種機制,定義每次呼叫的買方人數上限,或每個買方的大小上限。
這些措施的設計宗旨,是要讓廣告技術人員定義要與其他哪些廣告技術人員合作,並為可能需要處理的 adSelectionData
酬載設定可接受的上限。我們建議允許賣方在另一次呼叫中指定這份買方名單和優先順序。這個規範將保持不變一段時間,以免有心人士透過重複呼叫公開使用者的其他資料。
上述因應措施仍在討論階段,會隨時間而有所更動。如前所述,為防範濫用和大小限制而採用的所有緩解措施,都必須以遵循隱私權注意事項為前提。