前回は同一ドメイン内のページを遷移する場合の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ページを閲覧した場合の流れについて図解します。
- ユーザーがサイトに初めてアクセスする
- 1st-partyドメインのAMCV Cookieが存在しないので、Audience Manager (dpm.demdex.net) のID管理サービスにOrganization IDを渡し、Marketing Cloud IDを問い合わせる
- demdex.netドメインのCookieが存在しないのでMarketing Cloud IDを新規発行し、Cookieをセットする(demdex idが存在する場合はorgidとのコンビネーションで発行済みMarketing Cloud IDを調べて返す)
- Marketing Cloud IDをJSONで返す
- 収集サーバー (DC) のID管理サービスにOrganization IDとMarketing Cloud IDを渡す
- 従来のs_vi CookieからAnalytics IDを入手
- 従来のAnalytics Visitor ID (s_vi CookieのVisitor ID) をJSONで返す
- Marketing Cloud IDとAnalytics Visitor IDを結びつけるため、Audience Managerにデータを送信
- 1st-partyドメインで各種情報 (Organization ID, Marketing Cloud ID, Analytics ID) を格納するAMCV Cookieをセットする
- IDが確定したので、AppMeasurementがそのIDを使って各種のデータをDCへ送信する
- ユーザーが次のページに移動する
- (2と同じ)
- (3に近い)demdex idが存在するので3と同じMarketing Cloud IDをサーバーから取り出す
- (4と同じ)
- (5と同じ)
- (6と同じ)
- (7と同じ)
- (8と同じ)
- (9と同じ)
- (10と同じ)
まとめ
- 3rd-partyクッキーが有効でdemdexのクッキーが残っていれば、ドメインを超えてもIDが同じになり、訪問がつながります。
- 従来のs_viクッキーが残っていると、AnalyticsのVisitor IDが引き継がれるので、Visitor ID Serviceを入れてもデータはリセットされません。
|