EEFC(Exchange Enforced Frequency Capping)とは何か

概要

PrivacySandboxに含まれる、広告のフリークエンシー(FQ)制御に関するCookie廃止への代替手段。

DSP側でFQの設定をBidResponseに記述し、実際のFQ制御をSSP側で行うことでDSP側にCookieを渡さなくてもFQ制御できるようになるよという理屈。

実験段階なので仕様が変わる可能性がかなりある

資料

• ads-privacy/experiments/frequency-capping at master · google/ads-privacy (github.com)

詳細

背景

Chromeの3rd party Cookie廃止でDSPがCookieを取得できなくなるため、FQ制御が行えなくなる。FQ制御が行えない(=同じ広告を何回も見させられる)事は広告主側の広告効果、ユーザー側の体験双方に悪影響を与える。

元来DSP側で行っていたFQ制御をSSP側で制御することによって、プライバシーを守りながら広告効果及びユーザー体験を保つ仕組みを用意する。

目的

• 扱うこと
  • ユーザー識別子を用いないFQ制御
• 扱わないこと
  • クロスデバイスのFQ制御
  • SSP間のFQ制御

他技術との関連性

• 3rd party Cookie, idfa/anid: 既存のFQ制御ロジック
• TURTLEDOVE: デバイス側オークションでFQについて考慮する
• PETREL: デバイス側の広告除外グループにてFQについて考慮する

仕組み

流れ

1. 予めDSP管理画面でFQの設定を行う
2. ユーザーがメディアを開く
3. メディアがSSPに広告をリクエストする
4. SSPがDSPにBidRequestを送る
5. BidResponseにFQの設定を記述して返す
6. SSP側で対象のユーザーが、DSPから返却された fcap_id に過去何度接触したかを捜索し、BidResponseのFQの記載に従って落札可否を判定する
   • DSPが指定したFQ設定を超過していた場合、オークションプライスが一番高かったとしても落札されず、次点のクリエイティブが表示される
7. 落札されたクリエイティブがメディアに返される
8. クリエイティブをユーザーが見る

BidResponse内のFQの設定

”fcap”: [
  {
    "fcap_id": "kuruma-1",
    "time_unit": "WEEK",
    "time_range": 1,
    "max_imp": 10
  }
]

• fcap_id
  • FQ制御単位のID
  • 必須
  • オーダー単位でも、スケジュール単位でも、クリエイティブ単位でも、とにかくこのID単位でFQが制御される
    • IDをスケジュールやクリエイティブと定めないことで仕様の柔軟性を保っているらしい
• time_unit
  • FQ制御が解除される時間の単位
  • 必須
  • ["MINUTE", "DAY", "WEEK", "MONTH", "INDEFINITE"]
• time_range
  • FQ制御が解除される時間の数字
  • 任意
  • time_unit: WEEK, time_range: 1 なら1週間後に制限が解除される
• max_imp
  • IMPが許可される最大数
  • 必須

個人的な感想

入札時にFQ超過していた場合、DSP側としては無駄撃ちになる

DSP側でFQ制御をする場合は別案件を入札することができるが、それができない。
一応FQ超過で却下された場合のために、他の入札情報をBidRequsetに含めることができるらしい

Frequency caps are applied to each bid independently. This means that a bidder may include additional bids in their bid response if they would like an alternate bid to be considered should their frequency-capped bid be rejected.

SSP側で落札拒否された場合の理由がDSP側に検知できないので、FQが超過しているユーザーに延々と無駄撃ちになる広告をレスポンスする

一応落札拒否理由はlurlとかで送れるが、キャップ期限とかfcap_idとかも送らないと不十分だと思う。
扱ってる案件規模にもよるがDSP/SSP双方の負荷コストが高そう。

SSP側での制御なので、同一ユーザーであってもSSPが違うとFQが別々に制御される

例えば、SSP A経由の面とSSP B経由の面を同一ユーザーが閲覧した場合、FQ制御はSSP別々に実施されるため、10回というFQ制御をDSP側でかけた場合、合計20回表示される

ドキュメントにはDSP側でSSPごとに「7回 / 3回」と分けて設定してよと書いてある~~(わりと無茶苦茶)~~