Skip to content

Instantly share code, notes, and snippets.

@ritou ritou/cookiesync.md
Last active Apr 8, 2019

Embed
What would you like to do?
Cookie Syncについてのメモ

Cookie Syncの調査メモ

RTB周りで使われているというCookie Syncについて興味がわいたので調べてみる。

http://www.scaleout.jp/26992/

DMP-DSP間

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間のやりとりを行うことで、レイテンシを下げられて、ピクセル利用時のデータロスも制限できるとか。

DSP-SSP間

この内容をまとめておく。
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

GoogleというかDoubleClickというかのドキュメント。

Cookie マッチング - DoubleClick Ad Exchange Real-Time Bidding Protocol

ざっくりこんなことが書いてある。

  • パートナーはCookieマッチングを用いてパートナードメインのCookieとdoubleclick.netドメイン内のユーザー識別子を紐づけられる
  • 紐づけのためのマッチテーブルはGoogleがホストしていて、パートナーが管理する
  • マッチテーブル使ってるとRTBのアプリからユーザー識別子が来るので紐づいたユーザー情報を簡単に入札に使えて便利

Cookie Matchingの流れ

例示されている図と説明がわかりやすいので引用する。

まずはCookieが存在しない初回の処理。

処理の流れ

  1. ExampleNews.com が表示され、Google に対して広告の呼び出しが行われます(DFP)。
  2. 広告ユニットがダイナミック アロケーションに対応しているため、Ad Exchange が FinestDSP を呼び出します。
  3. FinestDSP が入札エンジンで呼び出しを処理します。
  4. FinestDSP がオークションに勝ち、広告とマッチ タグ(ピクセル)を Ad Exchange に送信します。
  5. Ad Exchange が FinestDSP の広告とマッチ タグを山田さんに配信し、山田さんの DoubleClick Cookie も設定します。
  6. マッチ タグが Google の Cookie マッチング サービスを呼び出します。
  7. Cookie マッチング サービスが山田さんの DoubleClick Cookie を読み取り、google_user_id を設定してリダイレクトを FinestDSP に送信します。
  8. ブラウザが FinestDSP の URL を読み込みます。
  9. FinestDSP が Cookie を生成し、その Cookie が山田さんの google_user_id と関連付けてマッチ テーブルに保存されます。
  10. FinestDSP が山田さんのブラウザに Cookie を送信し、1×1 の空のピクセルで応答します。

Cookie Matching Serviceの処理だけ見ると、

  • 6のマッチングタグにより処理が始まる
  • 7ではFinestDSPのURLに自身のCookieに対するユーザー識別子をつける
  • 8のクエリパラメータにユーザー識別子がついてくるのでFinestDSPは発行するCookieとの紐づけができる

続いて2回目以降

  1. ウェブページが表示されるとき、HTML コードには広告の呼び出しが含まれています。
  2. 広告のオークションでは、DoubleClick Ad Exchange が RTB パートナーの FinestDSP を呼び出すので、インプレッションに入札することができます。
  3. 購入者が、インプレッション情報と google_user_id を設定した広告呼び出しを受信します。
  4. FinestDSP がマッチ テーブルで google_user_id を参照し、例 1 で 1 週間前に作成された Cookie を見つけます。
  5. Cookie に関連付けられた情報を利用して、FinestDSP が入札に参加し、インプレッションを勝ち取ります。
  6. 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主導のマッチングというイメージか。よくわかっていない。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.