Privacy Sandbox 隱私沙盒解決方案 : Protected Audience API（PAAPI）是什麼？
對每一個行銷人員來說，Protected Audience API（簡稱 PAAPI）是 Privacy Sandbox 解決方案之中最重要的工具，PAAPI 目的就是為了替代原本運用 Cookies 再行銷廣告機制。PAAPI 讓廣告主可以針對進到廣告主網站的使用者呼叫 API 進行標記，將使用者加入「興趣團體」（Interest Groups、也可視為競價方）。PAAPI 同時也會在每次標記時，同步設定一個 JavaScript 競價邏輯出價。瀏覽器執行相關競價得分邏輯（decisionLogicUrl）對每個出價進行評分，判定贏得這次的廣告競價，並且展示廣告。
Protected Audience API（簡稱 PAAPI） 是 Google Chrome Privacy Sandbox 的重點項目之一，目標是希望能在不使用第三方 Cookies 下，解決程序化廣告購買中的其中一塊問題：「針對曾經來訪、互動過的使用者，後續進行再行銷」。因此，Protected Audience API 就是 Cookieless 的環境下， Google 官方提出的對應解決方案。
Protected Audience API 的運作原理
在實作面上來說，Protected Audience API（簡稱 PAAPI） 讓廣告主可以針對進到廣告主網站的使用者呼叫 API 進行標記，將使用者加入「興趣團體」（Interest Groups、也可視為競價方）。PAAPI 同時也會在每次標記時，同步設定一個 JavaScript 競價邏輯出價。
當使用者到達媒體站，有曝光機會時，瀏覽器會執行標記時所設定的程式碼來出價，並且瀏覽器也會決定最終競價結果、展示廣告，然後將勝出資訊回傳給獲勝的出價方。包含 Header Bidding 也將是透過這樣的方式來取得廣吿。
const interestGroup = {
owner: 'https://dsp.example',
name: 'custom-bikes',
biddingLogicUrl: ...,
biddingWasmHelperUrl: ...,
dailyUpdateUrl: ...,
trustedBiddingSignalsUrl: ...,
trustedBiddingSignalsKeys: ['key1', 'key2'],
userBiddingSignals: {...},
ads: [bikeAd1, bikeAd2, bikeAd3],
adComponents: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2],
};
navigator.joinAdInterestGroup(interestGroup, 7 * kSecsPerDay);以上程式碼為範例，廣告主透過 joinAdInterestGroup 將使用者加入至 custom-bikes 興趣團體，並且指定瀏覽器當有機會競價時執行 biddingLogicUrl 網址中的出價邏輯，而此出價邏輯將在瀏覽器當中保留 7 天（7 * kSecsPerDay）。
const auctionConfig = {
seller: 'https://ssp.example',
decisionLogicUrl: ...,
trustedScoringSignalsUrl: ...,
interestGroupBuyers: ['https://dsp.example', 'https://buyer2.example', ...],
auctionSignals: {...},
sellerSignals: {...},
sellerTimeout: 100,
perBuyerSignals: {
'https://dsp.example': {...},
'https://another-buyer.example': {...},
...
},
perBuyerTimeouts: {
'https://dsp.example': 50,
'https://another-buyer.example': 200,
'*': 150,
...
},
componentAuctions: [
{
'seller': 'https://some-other-ssp.example',
'decisionLogicUrl': ...,
...
},
...
]
};
try {
const auctionResultPromise = navigator.runAdAuction(auctionConfig);
} catch (error) {
// Handle error.
}而當使用者到達網頁上的廣告版位時，透過 navigator.runAdAuction()，讓先前儲存的出價邏輯，來競價此次的曝光。
- 廣告主根據興趣團體來參與競價，競價過程中只有在媒體端指定興趣團體買家（
interestGroupBuyers），才能參與競價 - 針對不同買家可以設定參數值 （
perBuyerSignals）和不同的時間限制（perBuyerTimeouts） - 瀏覽器執行相關競價得分邏輯（
decisionLogicUrl）對每個出價進行評分，最終決定哪一個出價者得分最高，判定贏得這次的廣告競價，並且展示廣告
須注意，也有可能所有的 PAAPI 的出價最終都沒有展示，因為從伺服器端的廣告伺服器有更好的情境式廣告、或是媒體自家直售的廣告。這些都可以在競價得分邏輯中撰寫相關的規則。
對業界來說仍然不完美，但大家也積極測試
如同我們在 35 期曾經報導過 Criteo 在 Topics API 的測試結果，再行銷大廠 Criteo 也針對 Protected Audience API （前稱 FLEDGE） 做了一番的分析與調查。甚至早在 Google Privacy Sandbox 剛提出 TURTLEDOVE 草案時（FLEDGE 的前身），便也提出對案 SPARROW，而在 SPARROW 中的一些概念也被整合到目前正在測試的 PAAPI 版本當中。
那 Index Exchange 也在年初推出了 Protected Audience API 的範例網頁，可以透過簡單的介面測試多家 DSP、多家 SSP 與廣告伺服器的情況，並且提供原始碼和一張相當清晰的流程圖提供開發者能夠快速參考。
至於另一個瀏覽器大廠微軟 Edge，則在三月也釋出官方消息支持第三方 Cookies 的淘汰，也宣告將在 Edge 當中提供 Ad Selection API 作為再行銷的解決方案，此一 Ad Selection API 為 PPAPI 的擴充版本，相容於 PAAPI 的介面，並且針對一些當前設計的問題做了修正與調整，目前也受到廣告產業廣泛的正面評價。
典範的轉移：拉 vs. 推
相較於在 Cookies 時代時，比較像是「拉」的做法：使用者到達媒體站，透過 Cookies 辨別使用者後去呼叫 DMP 「拉」（查詢）對應的使用者輪廓，最終透過這個輪廓決定出價。
PAAPI 則比較像是「推」的做法：使用者到達廣告主網站，DSP 透過 PAAPI 將競價邏輯「推」（儲存）到瀏覽器端，當使用者後續瀏覽到媒體站時，由瀏覽器呼叫出價邏輯、決定最終是否展示曝光。
那這個很大的差異在於，過去透過第三方 Cookies 的拉資料，這些在網路上交換的資料正是使用者的個資，而現在透過推的方式，則是僅將出價資訊存在瀏覽器端，在網路上交換的資料自然少了非常多，也保護了消費者的隱私。
結論
透過瀏覽器來進行再行銷活動，而非透過 DSP 收集 Cookies 資料來決定是否要出價，就是希望能夠限縮 DSP 在資料收集上的能力，避免做到過於強大的追蹤而洩露使用者隱私。若是不同的再行銷活動，能夠互相彼此知道對方的廣告展示狀況，那就會進一步的導致資料外洩的風險。
此外，在目前既有的第三方 Cookies 的廣告運作原理，第三方廣告技術廠商甚至是被曝光的媒體，都是有機會及能力去攔截廣告主和使用者數據，變成自己獲利的數據資產。用一句更簡單白話文來說，在業界我們常聽到 DSP 或 SSP 廠商「洗數據」變成自己的 DMP，再轉賣給其他廣告主。因此，在 Protected Audience API 機制下是完全阻斷資料洩漏及被竊取的可能。
相信在未來半年之內，將有越來越多廠商加入 Protected Audience API 的測試，這種變化不僅僅是技術層面的更新，更是對於全球數位廣告行業的一種倫理和規範的重新定義。當然，也很有可能讓廣告產業競爭商業版圖重新洗牌，甚或更加圖利擁有一方數據花園圍牆，如 Google、Meta 等公司。本刊更希望台灣數位行銷、廣告、媒體業者，加入討論和關注相關技術、議題發展，提出完整的解決方案。相信距離 Q4 到來之前，除了持續追蹤 TPG 週刊 Privacy Sandbox 主題討論，我們仍有足夠的時間投入準備和應對未來挑戰。
