Privacy Sandbox 隱私沙盒解決方案 : Protected Audience API(PAAPI)是什麼?

Protected Audience API(簡稱 PAAPI) 是 Google Chrome Privacy Sandbox 的重點項目之一,目標是希望能在不使用第三方 Cookies 下,解決程序化廣告購買中的其中一塊問題:「針對曾經來訪、互動過的使用者,後續進行再行銷」。因此,Protected Audience API 就是 Cookieless 的環境下, Google 官方提出的對應解決方案。

Protected Audience API 的運作原理

來源:Google

在實作面上來說,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);

來源:Buyer guide: join interest groups and generate bids

以上程式碼為範例,廣告主透過 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.
}

來源:Seller guide: run ad auctions

而當使用者到達網頁上的廣告版位時,透過 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 主題討論,我們仍有足夠的時間投入準備和應對未來挑戰。

延伸閱讀