RTB周りで使われているというCookie Syncについて興味がわいたので調べてみる。
Quoraから。
http://www.quora.com/How-does-cookie-sync-work-between-DMP-and-DSP
- クライアントはWebサイト上に DMP Universal Container Tagを設置する
- クライアントが設置したTagの中にDSPのピクセルが置かれる
- クライアントのブラウザには、DMPとDSPが発行したCookieを受け取れる
- このときにDMPとDSPはユーザーIDを振ることができる
- 「ここで同期」 DMPがDSPを呼び出すときにクエリストリングを用いて自身のIDを渡す
- DSPはDMPのCookie IDと自身のCookie IDを紐づけられる(DSP Cookie ID 123 = DMP Cookie ID 456)
- DMPはそのCookie IDに紐づいた情報を集め、バッヂ処理でDSPにデータを送る
- DSPはCookie IDの紐づけできてるから誰だかわかるよね
Quoraの説明では、DSP-SSP間について「プロセスは大体同じだけどServer間のやりとりができない場合について説明されている。
全部ピクセル呼び出しとクエリストリングで行われる。」と言って以下のリンクを進めている。
Server間のやりとりを行うことで、レイテンシを下げられて、ピクセル利用時のデータロスも制限できるとか。
この内容をまとめておく。
http://www.adopsinsider.com/ad-exchanges/ssp-to-dsp-cookie-synching-explained/
参考として、(DSP/RTBの基本的な仕組み | DSP/RTB入門書特別公開 #1)[http://web-tan.forum.impressrd.jp/e/2012/07/02/13001]から図を引用しておく。
http://web-tan.forum.impressrd.jp/files/images/article2012/DSP/DSP01_02_03.png
想定するユースケース:「ショッピングサイトでカートに入れたまま別のサイトに行ってしまったユーザーをターゲティングして"戻って来て買い物終わらせて！"という広告を出す」
- ショッピングサイトのuser123はカートに商品を入れる
- ショッピングサイトはDSP456を利用しており、1×1ピクセルの画像を置いている
- user123に対応するDSPのCookieが発行される(ドメインはDSPのものでCookie IDはDSPcookie789)
- user123はその後様々なサイトを周り、awesomesite.comにたどりつく。awesomesite.comはSSP123を使って広告を出している
- awesomesite.comの3rd party redirectによりSSP123はuser123に対するCookieを発行(ドメインはSSPものでCookie IDはSSPcookieXYZ)
- SSP123はDSP456を含む入札者にビッドリクエストを送る
- このとき、SSPがCookie ID(SSPcookieXYZ)を含まない場合、DSP456はuser123であることがわからないので広告が出せない
- 最初の入札が終わった後、SSP123はJSを実行し、各入札者へのリダイレクトにはクエリパラメータとしてSSPのCookie ID(SSPcookieXYZ)が付与される
- DSP456はCookie IDの紐づけを保存(DSPcookie789=SSPcookieXYZ)
- その後のビッドリクエストでDSP456はuser123であることを確認できるため入札を行う
- これらの処理が各SSPとの間で行われている
レイテンシとUXの問題(Cookie IDとの紐づけ処理などを待っていられない)で最初の入札時にSSPはCookie IDを送らないと言っている。
これは各社仕様が異なるのだろうか？
メジャーなSSPがpiggyback scriptを実行するためのHTMLが紹介されている。
- Pubmatic : vcodeというクエリパラメータでCookie IDを送信
- Rubicon Project : Cookie IDはnid?ちょっとよくわからない
- Admeldは別のソリューション やはり、SSP側の実装はバラバラということなのだろうか。対応コストとか考えるとちょっと嫌だな。
ここまででなんとなくCookie Syncのしくみを理解したつもりになってきた。
- DMPがDSPに共通のCookie ID(ユーザー識別子)を送る :「DSP間であるDMPのCookie IDを用いたデータの意図せぬ名寄せが可能なのでは？」
- SSPが各入札者(DSP)に共通のCookie ID(ユーザー識別子)を送る :「DSP間でSSPのCookie IDを用いたデータの意図せぬ名寄せが可能なのでは？」
- DSPから両者の紐づけが漏れたらDMP-SSP間で名寄せができてしまう
↓こうすべきか？↓
- DMPがDSP単位でPPID化した識別子を送る
- SSPがDSP単位でPPID化した識別子を送る
- Dmp - cookie synching : なぜあなたをターゲティングできるのかという内容でCookie Syncやpiggybackについてもちょっと図に含まれる
GoogleというかDoubleClickというかのドキュメント。
Cookie マッチング - DoubleClick Ad Exchange Real-Time Bidding Protocol
ざっくりこんなことが書いてある。
- パートナーはCookieマッチングを用いてパートナードメインのCookieとdoubleclick.netドメイン内のユーザー識別子を紐づけられる
- 紐づけのためのマッチテーブルはGoogleがホストしていて、パートナーが管理する
- マッチテーブル使ってるとRTBのアプリからユーザー識別子が来るので紐づいたユーザー情報を簡単に入札に使えて便利
例示されている図と説明がわかりやすいので引用する。
まずはCookieが存在しない初回の処理。
- ExampleNews.com が表示され、Google に対して広告の呼び出しが行われます（DFP）。
- 広告ユニットがダイナミック アロケーションに対応しているため、Ad Exchange が FinestDSP を呼び出します。
- FinestDSP が入札エンジンで呼び出しを処理します。
- FinestDSP がオークションに勝ち、広告とマッチ タグ（ピクセル）を Ad Exchange に送信します。
- Ad Exchange が FinestDSP の広告とマッチ タグを山田さんに配信し、山田さんの DoubleClick Cookie も設定します。
- マッチ タグが Google の Cookie マッチング サービスを呼び出します。
- Cookie マッチング サービスが山田さんの DoubleClick Cookie を読み取り、google_user_id を設定してリダイレクトを FinestDSP に送信します。
- ブラウザが FinestDSP の URL を読み込みます。
- FinestDSP が Cookie を生成し、その Cookie が山田さんの google_user_id と関連付けてマッチ テーブルに保存されます。
- FinestDSP が山田さんのブラウザに Cookie を送信し、1×1 の空のピクセルで応答します。
Cookie Matching Serviceの処理だけ見ると、
- 6のマッチングタグにより処理が始まる
- 7ではFinestDSPのURLに自身のCookieに対するユーザー識別子をつける
- 8のクエリパラメータにユーザー識別子がついてくるのでFinestDSPは発行するCookieとの紐づけができる
続いて2回目以降
- ウェブページが表示されるとき、HTML コードには広告の呼び出しが含まれています。
- 広告のオークションでは、DoubleClick Ad Exchange が RTB パートナーの FinestDSP を呼び出すので、インプレッションに入札することができます。
- 購入者が、インプレッション情報と google_user_id を設定した広告呼び出しを受信します。
- FinestDSP がマッチ テーブルで google_user_id を参照し、例 1 で 1 週間前に作成された Cookie を見つけます。
- Cookie に関連付けられた情報を利用して、FinestDSP が入札に参加し、インプレッションを勝ち取ります。
- FinestDSP が持つ情報に基づき、山田さんの関心に合わせて広告が表示されます。
DoubleClick側では自身のCookieに紐づくユーザー識別子を広告呼び出しに指定する。
FinestDSPはユーザー識別子がマッチングテーブルに保存されているのでそれに紐づく情報を用いて入札を行う。ってだけの話。か。
パラメータの指定方法などが細かく説明されているが今回は割愛。
DoubleClickのCookie情報はやりとりされないというところが特徴かもしれない。
google_user_idというのは共通なのかどうかが気になる。
そして、英語版の方にはPixel Matchingというものの説明がある
Cookie Matching - DoubleClick Ad Exchange Real-Time Bidding Protocol
DoubleClickが選択したパートナーに対してユーザー識別子を送り、パートナーからはCookie Matching Serviceへのリダイレクトと共にパートナーIDが返ってくる。
Cookie Matching Serviceはそのパートナーとユーザーが紐づけしたよという情報を保存する。
DoubleClick主導のマッチングというイメージか。よくわかっていない。