MMPではAnalyticsのID管理とCookieがこう変わる

posted Sep 7, 2014, 9:06 AM by Makoto Shimizu   [ updated May 8, 2015, 5:33 AM ]

Master Marketing Profile (MMP)の登場でAdobe Analyticsが訪問者IDを管理する方法が変わったので、実際に実装してみました。実はスゴいです。

MMPの実装方法

今回の検証の条件は

  • VisitorAPI.js 1.3.2:Marketing Cloud Visitor ID Serviceに必要なファイル
  • AppMeasurement.js 1.4.1
  • Data Collection Serverは地域固定の2o7.netではなくRDC (*.omtrdc.net)で、自社ドメインのCNAME設定なし
  • ブラウザは3rd-party Cookieを受け付ける

最新バージョンのライブラリを使ってスケルトン的なHTMLページを作って検証しました。

サンプルページの構成

検証ページでは、以下のように、<head>から2つのJavaScriptファイルを参照しています。

  • レガシーな従来のs_code.jsとは違い、AppMeasurement.jsはheadの中に入れられる
  • VisitorAPI.js は AppMeasurement.js や mbox.js よりも先にロードする必要がある
  • 手を入れるとアップグレードの時に面倒なので、外部JSファイルはダウンロードしたままの状態(HTMLソースにべた書きした設定系のJS文は、実際にはDTM側で処理するか、共通JSファイルを作るなどが必要)

訪問者ID発行と保管の流れ

初めてアクセスした時と二度目以降では挙動が変わるので、HttpFoxCharlesでパケットを確認できる状態にしてから検証ページを開いてみてください。

結果はこうなりました。

  1. ユーザーがサイトに初めてアクセスする
  2. 1st-partyドメインのAMCV Cookieが存在しないので、Audience Manager (dpm.demdex.net) のID管理サービスにOrganization IDを渡し、Marketing Cloud IDを問い合わせる
  3. demdex.netドメインのCookieが存在しないので新規と判断してMarketing Cloud IDを発行し、Cookieをセットする
  4. Marketing Cloud IDをJSONで返す
  5. 収集サーバー (DC) のID管理サービスにOrganization IDとMarketing Cloud IDを渡す
  6. 従来のs_vi CookieがDCサーバーのドメインに存在しないので、従来のAnalytics ID (s_vi CookieのVisitor ID) をJSONで返さない
  7. IDが確定したので、AppMeasurementがそのIDを使って各種のデータをDCへ送信する
  8. 1st-partyドメインで各種情報 (Organization ID, Marketing Cloud ID, Analytics ID) を格納するAMCV Cookieをセットする
  9. ユーザーが次のページに移動する
  10. 1st-partyドメインのAMCV CookieからMarketing Cloud IDを得る
  11. AppMeasurementがそのIDを使って各種のデータをDCへ送信する

IDの管理が一つ上のレイヤーに移動するので、AnalyticsやTarget, Audience ManagerなどMarketing Cloud間で統一された顧客プロファイル管理を実現できる、ということですね。

別ドメインに遷移する場合もOK!

上の図で1.htmlと2.htmlが別のドメインになる場合は、10のステップでIDを得るのに失敗するので、2〜4までのステップが繰り返されます。この時に、demdex.netの3rd-party Cookieに格納されたIDを読める場合は、orgidとdemdex IDの組み合わせから発行済のMarketing Cloud IDがルックアップされ、8と同じMarketing Cloud IDが発行されます。つまり、GAのようにURLにパラメータを付与しないでも、ドメイン間でセッションがつながります。

クロスドメイン時の挙動については別記事でまとめました:実は複雑なAdobe Marketing CloudのクロスドメインID管理

参考:公式ヘルプ

3rd-party Cookieが拒否される場合は?

(複雑なので別の記事でまとめます)

従来のs_vi方式の流れ

比較のため、従来のs_vi Cookie方式の場合の挙動も図解しておきます。

  1. ユーザーがサイトに初めてアクセスする
  2. s_code.jsが計測データをDCへ送信する
  3. DCドメインのs_vi Cookieが存在しないので新たにAnalytics IDを発行し、s_vi Cookieをセットすると同時にLocationヘッダを返すことでリダイレクト(再送信)をブラウザへ指示
  4. Locationヘッダを受けて、ブラウザが2のリクエストを繰り返す
  5. s_vi CookieからAnalytics IDを入手し、データを記録
  6. ユーザーが次のページに移動する
  7. 計測データをDCへ送信する
  8. s_vi CookieからAnalytics IDを入手し、データを記録

注:3rd-party Cookieが拒否された場合はJSがランダムのIDを発行するという例外処理は省略しています

参考:公式ヘルプ

2014/9/10追記:公開時はクロスドメインに未対応としていた点を訂正。図にdemdexのCookieを追加。

Comments