実は複雑なAdobe Marketing CloudのクロスドメインID管理

posted May 3, 2015, 9:30 AM by Makoto Shimizu   [ updated May 8, 2015, 5:36 AM ]

前回は同一ドメイン内のページを遷移する場合のVisitor ID Serviceの挙動について紹介しました。

今回は、別ドメインへの遷移、既存レガシーサイトにおけるMMP (Visitor ID Service) 導入、も考慮して解説します。

（3rd-party Cookieが無効の場合とCNAMEを利用している場合は別途）

前提条件：

  • VisitorAPI.js 1.3.2
  • AppMeasurement.js 1.4.1
  • Data Collection Serverは地域固定の2o7.netではなくRDC (*.omtrdc.net)で、自社ドメインのCNAME設定なし
  • ブラウザは3rd-party Cookieを受け付ける
  • 従来のs_vi Cookieは残っているが、Visitor ID Service導入後は初めてアクセスする

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

Visitor ID Service (VisitorAPI.js) 導入前のs_viクッキーが残っている状態でドメインの異なる2ページを閲覧した場合の流れについて図解します。

  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をセットする（demdex idが存在する場合はorgidとのコンビネーションで発行済みMarketing Cloud IDを調べて返す）
  4. Marketing Cloud IDをJSONで返す
  5. 収集サーバー (DC) のID管理サービスにOrganization IDとMarketing Cloud IDを渡す
  6. 従来のs_vi CookieからAnalytics IDを入手
  7. 従来のAnalytics Visitor ID (s_vi CookieのVisitor ID) をJSONで返す
  8. Marketing Cloud IDとAnalytics Visitor IDを結びつけるため、Audience Managerにデータを送信
  9. 1st-partyドメインで各種情報 (Organization ID, Marketing Cloud ID, Analytics ID) を格納するAMCV Cookieをセットする
  10. IDが確定したので、AppMeasurementがそのIDを使って各種のデータをDCへ送信する
  11. ユーザーが次のページに移動する
  12. （2と同じ）
  13. （3に近い）demdex idが存在するので3と同じMarketing Cloud IDをサーバーから取り出す
  14. （4と同じ）
  15. （5と同じ）
  16. （6と同じ）
  17. （7と同じ）
  18. （8と同じ）
  19. （9と同じ）
  20. （10と同じ）

まとめ

  • 3rd-partyクッキーが有効でdemdexのクッキーが残っていれば、ドメインを超えてもIDが同じになり、訪問がつながります。
  • 従来のs_viクッキーが残っていると、AnalyticsのVisitor IDが引き継がれるので、Visitor ID Serviceを入れてもデータはリセットされません。
Comments