Show Menu
TOPICS×

Analytics および Experience Cloud ID の設定

Experience Cloud Identity Service は、従来の Analytics 訪問者 ID 方式を置き換えるものです。
ID サービスの実装後、AppMeasurement の前にこのコードが実行されます。ID サービスは Experience Cloud および Analytics の ID を取得するので、AppMeasurement が読み込まれたときには、これらの値が利用できる状態になっています。
AppMeasurement が読み込まれると、Experience Cloud および Analytics の ID の値が ID サービスからリクエストされ、各サーバーコールでデータ収集サーバーに送信されます。ID サービスは訪問者 ID を決定してそれを AppMeasurement に渡すだけなので、各ページでは ID サービスを AppMeasurement JavaScript ファイルの前にインクルードして実装しておく必要があります。

Analytics ID プロセスの変更点

Experience Cloud ID サービスに移行する際の大きな変更点は、データ収集 Web サーバーから返された HTTP ヘッダーを使用するのではなく、JavaScript を使用して ID Cookie を設定することです。この変更を理解できるように、以下の節でこの 2 つの方法を使用して Cookie を設定する方法について説明します。
HTTP ヘッダー
Web サーバーからの HTTP 応答がブラウザーの Cookie に設定されます。この処理により、
s_vi
Cookie が設定されます。
s_vi
Cookie は Analytics 訪問者を識別するものです。設定された Cookie は、以後そのサーバーに送信されるすべての HTTP リクエストに含まれます。
リクエストがアドビのデータ収集サーバーに送信されると、ヘッダーで
s_vi
Cookie の有無がチェックされます。この Cookie がリクエストに含まれている場合、この Cookie を使用して訪問者が識別されます。この Cookie がリクエストに含まれていない場合、サーバーは一意の Experience Cloud ID を生成し、それを HTTP 応答ヘッダー内に Cookie として設定した後、リクエストとともに返送します。この Cookie はブラウザーに保存され、その後のサイト訪問の際にデータ収集サーバーに返送されます。このしくみによって、複数回訪問する訪問者を識別できます。
ただし、Apple Safari などの一部のブラウザーでは、サードパーティ Cookie が受け入れられません。サードパーティ Cookie とは、現在の Web サイト以外のドメインからブラウザーに設定される Cookie のことです。また、Safari では、訪問者が訪問したことのないサードパーティドメインの Cookie がブロックされます。例えば、
mysite.com
を表示しているとき、データ収集サーバーが
mysite.omtrdc.net
である場合は、
mysite.omtrdc.net
からの HTTP ヘッダーで返された Cookie はブラウザーによって拒否される可能性があります。
この状況を避けるために、多くのお客様はデータ収集サーバーに対して CNAME レコードを実装しています。これは、 ファーストパーティ Cookie を実装する 効果的な方法の 1 つです。お客様のドメインのホスト名をデータ収集サーバーにマッピングするように CNAME レコードを設定すると(例えば、
metrics.mysite.com
mysite.omtrdc.net
にマッピングする)、データ収集ドメインは Web サイトのドメインと一致するので、Experience Cloud ID Cookie が保存されます。この方法により、ID サービスの Cookie が保存される可能性が上がります。ただし、CNAME レコードを設定して、データ収集サーバーの SSL 証明書を維持する必要があるので、オーバーヘッドが発生します。
JavaScript
JavaScript は、ファーストパーティドメイン(現在の Web サイトのドメイン)の Cookie セットの読み取りと書き込みを実行できます。これにより、Experience Cloud ID サービスではすべての訪問者 ID を含む
AMCV_###@AdobeOrg
Cookie を設定できるので、トラッキングサーバーのドメインが Web サイトのドメインと一致していない場合でも、訪問者 ID Cookie を保存できます。CNAME レコードおよび SSL 証明書を使用するオーバーヘッドが不要となるので、ほとんどの場合においてこの方法で ID サービス Cookie を設定することをお勧めします。
ただし、状況によっては、クロスドメイントラッキングでは HTTP ヘッダーに Cookie を設定する方がメリットが大きい場合もあります。これについては データ収集 CNAME およびクロスドメイントラッキング で説明します。

カスタム Analytics ID

s.visitorID
を使用して顧客 ID を設定すると、Analytics でユーザーを特定しやすくなります。しかし、
s.visitorID
を使用して訪問者を特定する場合は、ID サービスを用いて Analytics データをエクスポートまたはインポートする統合機能を使用できません。
これには共有オーディエンス、Analytics for Target(A4T)、顧客属性などが該当しますが、これらに限定されません。これらの統合機能では、カスタム Analytics ID の設定はサポート対象外となります。

Analytics 訪問者 ID の順序

訪問者 ID サービスをデプロイすると、Analytics で訪問者を識別するために次の 5 つの方法を使用できることになります(次の表では、優先度の高い順に並べています)。
使用される順序
クエリパラメーター(収集方法)
次の場合に存在
s.visitorID が設定されている場合
Experience Cloud
ID サービスをデプロイする前に、訪問者に既存の s_vi Cookie がある場合、または 猶予期間 を設定している場合。
mid(Experience Cloud 訪問者 ID サービスによって設定される AMCV_ Cookie)
訪問者のブラウザーがファーストパーティ Cookie を受け入れる場合
ブラウザーがサードパーティ Cookie を受け入れず、Analytics トラッキングサーバーがサードパーティトラッキングサーバーとして設定されている場合
注意:
fid
は、従来の識別子で、サイトに ID サービスを実装している場合、使用されません。この場合、ファーストパーティである AMCV cookie がもう使用していないので、
fid
は必要ありません。fid は、レガシーコードをサポートするために、および歴史的な理由により、保持されています。
訪問者のブラウザーが Cookie を受け入れない場合。
ほとんどのシナリオでは 1 回の呼び出しに 2 ~ 3 種類の ID が存在しますが、Analytics では、最も優先度の高い ID が正式な Experience Cloud ID として使用されます。例えば、'vid' クエリパラメーターに格納されるカスタム訪問者 ID を設定している場合は、この ID が、同じヒットで存在する他の ID よりも優先して使用されます。