このページでは、Marketing Cloud ID サービスでどのようにして訪問者を従来の Analytics ID から Marketing Cloud ID に移行するかを説明します。いくつかの概念が簡略化され、理解しやすくなっています。

ビデオ:MCID で従来の Analytics 訪問者を移行する仕組み


環境

標準的な Web 環境を以下に示します。左に示すのは、訪問者のブラウザーです。中央に示すのは、My Company Inc. が所有する Web サイトです。どちらの Web サイトにも Marketing Cloud ID サービスが正しくデプロイされています。右と左下の円筒状の図形は、アドビのサーバーを表しています。

標準的な Web 環境の図

ユーザーのブラウザーには s_vi cookie が保存されています。これは SiteA.com ドメインで設定される cookie と思われます。Analytics トラッキングに精通している方なら、この cookie に「aid」値が含まれていることをご存知でしょう。この cookie があるということは、このユーザーはこれまでに、My Company Inc. が所有する Web 資産にアクセスしたことがあります。

シナリオ

以下では、2 つの異なるシナリオについて説明します。

最初のシナリオは、ユーザーが、My Company Inc. による Marketing Cloud ID サービスのデプロイ後に初めて SiteA.com を再訪したときの状況です。このシナリオでは、Marketing Cloud ID サービスが既存の ID を従来の s_vi cookie から AMCV cookie にどのように移行するかを示します。このシナリオは、この図の中では青で示されます。

2 つ目のシナリオは、同じユーザーが、My Company Inc. が所有する別ドメインを訪問したときの状況です。この別ドメインにも Marketing Cloud ID サービスがデプロイされています。このユーザーがこのサイトを訪問するのはこれが初めてです。このサイトは、最初のドメインと同じ Analytics トラッキングサーバーを利用しています。このシナリオでは、Marketing Cloud ID サービスが同じ ID サービス ID を維持しながら、トラッキングサーバーから従来の ID を取得する方法を示します。このシナリオは、この図の中では赤で示されます。

 

2 つの訪問者シナリオを示す図

注意:

複数のドメインで同じ Analytics トラッキングサーバーを使用することは、Marketing Cloud ID サービス以前にドメイン間トラッキングを実現するために使用されていた一般的な方法です。

手順

  1. ユーザーが、My Company Inc. による Marketing Cloud ID サービスのデプロイ後に初めて SiteA.com を訪問します。

     

    Step 1
  2. ID サービスコード(VisitorAPI.js)がページの一部として読み込まれ、現在のドメイン(SiteA.com)に「AMCV」cookie があるかどうかが確認されます。そのような cookie が存在しないので、ID サービスは、demdex.net ドメインに Demdex cookie があるかどうかを確認します。demdex.net cookie も存在していません。

    cookie の有無を確認
  3. 現時点で、このブラウザーには Marketing Cloud ID はありません。したがって、ID サービスコードは、ID サービスサーバー(dpm.demdex.net)に ID をリクエストします。dpm.demdex.net に対して、Experience Cloud 組織 ID を含むネットワークリクエストが作成されます。

    ネットワークリクエストを作成

    注意:

    Experience Cloud 組織 ID は、実装の一部としてページから取得されます。この組織 ID は、Adobe Experience Cloud 内のクライアント会社を一意に識別します。ID の例:016D5C175213CCA80A490D05@AdobeOrg

  4. ID サービスサーバーがリクエストを受信します。リクエストに「uuid」値が含まれていないので、サーバーは Marketing Cloud ID または「mid」値の生成に使用する「uuid」値を生成します。「uuid」値が生成されると、サーバーはその「uuid」と Experience Cloud 組織 ID を使用して「mid」を生成します。 

    ID サービスサーバーがリクエストを受信
  5. ID サービスは、リクエストに応答して「uuid」と「mid」の両方を返します。

    uuid と mid を使用した応答
  6. ID サービスは最後に、従来の Analytics ID の有無を確認します。そのために、Analytics トラッキングサーバーのドメインに「s_vi」cookie があるかどうかを調べます。この例では、metrics.siteA.com が Analytics トラッキングサーバーとして使用されています。

    従来の Analytics ID の有無を確認

    注意:

    この確認は必須です。Analytics では、従来の Analytics ID または「aid」を持っていない訪問者のプライマリ ID として「mid」値を使用します。既存の ID の移行が完了していない場合、ユーザーは新しい訪問者として認識され、従来の「aid」に関連付けられていたすべての履歴データはその新しい訪問者に関連付けられなくなります。

     

  7. この例では、ブラウザーはトラッキングサーバードメインの従来の s_vi cookie を含んでいます。つまり、ID サービスはこの s_vi cookie を読み取ってそこから「aid」値を取得できます。

    ブラウザーは従来の cookie を含んでいる
  8. これで、必要なものが揃ったので、ID サービスコードは現在のドメイン(SiteA.com)に AMCV cookie を設定します。また、demdex.net cookie はまだないので、ID サービスは、UUID を含む demdex.net cookie を設定します。

    ID サービスが AMCV cookie を設定

    注意:

    ID サービスは、その cookie を現在のドメインに書き込みます。これが、従来の Analytics での識別とは異なる点です(以前は、cookie はトラッキングサーバーのドメインに書き込まれていました)。

    また、Analytics トラッキングサーバーのドメインと Web ページのドメインは必ずしも一致しません。

  9. AMCV cookie がブラウザーに書き込まれると、残りのページが読み込まれ、アドビソリューションのビーコンが開始されます。

    ページが読み込まれ、アドビソリューションのビーコンが開始
  10. 2 つ目のシナリオでは、同じユーザーが同じブラウザーを使用して、Marketing Cloud ID サービスがデプロイされている My Company Inc. 所有の別の Web プロパティを訪問します。

    シナリオ 2 - 同じブラウザーで訪問
  11. ID サービスコードが読み込まれ、手順 2 と同じように、現在のドメイン(siteB.com)に AMCV cookie があるかどうかが確認されます。このユーザーがこのサイトを訪問するのは初めてなので、AMCV はありません。AMCV cookie はないので、次は、demdex.net cookie の有無が確認されます。Demdex cookie は前のシナリオの手順 8 で設定されています。ID サービスは Demdex cookie を読み取って、「uuid」値を返します。

    AMCV cookie の有無を確認
  12. 最初のシナリオ(手順 3)と同じように、ID サービスコードは ID サービスサーバーに ID をリクエストします。ただし、今回は、Demdex cookie からの「UUID」値が既にあります。「UUID」と Experience Cloud 組織 ID が一緒に送信されます。

    ID サービスが ID をリクエスト
  13. サーバーはリクエストを受信し、リクエストと一緒に送信されたuuid」(ABC)と組織 ID(1234)を使用して「mid」を生成します。「mid」値は、前の例と同じ組織 ID と「UUID」を使用して生成されることに注意してください。ID の生成に同じ 2 つのパラメーターが使用されるので、同じ結果になります。このようにして、ID サービスでドメイン間トラッキングが実現されます。

    サーバーがリクエストを受信し、「mid」値を生成
  14. ブラウザーはリクエストに応答して「mid」値をページに送り返します。

    ブラウザーが「mid」値をページに返信
  15. ID サービスコードは、最後の確認として、Analytics トラッキングサーバーに s_vi cookie があるかどうかを調べます(最初のシナリオと同じように、既存の訪問者データに断絶が生じないようにするため)。

    ID サービスコードが cookie の有無を最終確認
  16. トラッキングサーバーのドメインと、ブラウザーが現在訪問しているドメイン(siteb.com)が一致しないので、トラッキングサーバーがリクエストに応答できるように、metrics.siteA.com に対する呼び出しがおこなわれます。トラッキングサーバーは、AID 値があると仮定して、AID 値を使用してリクエストに応答します(このブラウザーの例に示すようにおこなわれます)。

    metrics.siteA.com に対する呼び出しを実行
  17. これで、必要な情報がすべて揃ったので、ID サービスコードは現在のドメインに AMCV cookie を書き込みます。今度は、この cookie は siteB.com に書き込まれます。AMCV cookie には「mid」と「aid」の両方が含まれます。両方の値があれば、従来の ID に関連付けられているデータをすべて引き続き使用できる一方で、MID を介してクロスソリューション ID を利用する多くのメリットが得られます。

    現在のドメインで AMCV cookie を書き込み
  18. 最後に、残りのページコードが実行され、アドビソリューションのビーコンが開始されます。

ご質問がある場合

この記事では、Marketing Cloud ID サービス(MCID)の仕組みについて詳しく説明しています。いくつかの概念が簡略化され、理解しやすくなっています。その他のご質問がある場合は、Marketing Cloud ID サービスのドキュメント を参照してください。コミュニティフォーラム で質問することもできます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー