Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Instantly share code, notes, and snippets.

@ritou

ritou/cookiesync.md

Last active April 14, 2023 12:45
Show Gist options
  • Save ritou/3888510 to your computer and use it in GitHub Desktop.
Save ritou/3888510 to your computer and use it in GitHub Desktop.
Download ZIP
Cookie Syncについてのメモ
Raw
cookiesync.md

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