単一ページアプリケーション(SPA)での Adobe Analytics 実装のベストプラクティスについて説明します。これには推奨される実装方法である Experience Platform Tags の使用が含まれます。
最初のメモ:
メモ:これは Experience Platform Tags を使用した Adobe Analytics 実装において、SPA ページがどのように処理されるかを簡単に示した図です。次の節では、考慮すべき手順と問題を説明します。
新しいコンテンツの読み込み時、または SPA ページでのアクション発生時は、最初にデータレイヤーを更新します。これは Experience Platform Tags でルールをトリガーするカスタムイベントが実行される前に行う必要があります。これにより、正しい値がデータレイヤーからタグに、その後 Adobe Analytics にプッシュされます。
次に、サンプルデータレイヤーを示します。これらの要素は、最初のビューや、SPA ページで実行されたアクションによるその後のビューの変更に基づいて変更する場合があります。例えば、フルビューまたは大部分のビューの変更時には、Adobe Analytics のレポートにおいてビューを区別するために一意の「pageName」値を渡すことが一般的な要件となっています。
<script>
digitalData = {
pageInstanceID: "Launch Demo Site",
page:{
pageInfo:{
pageID: '2745374',
pageName: 'acs demo - product listing page'
},
attributes:{
project: "Experience Platform Launch Project"
}
},
user : [ {
"profile" : [ {
"attributes" : {
"gender" : "male",
"age" : "35"
}
} ]
}],
libraries : {
adobe : {
launch : {
state : 0, // 0 = not loaded , 1 = loaded
domain : "assets.adobedtm.com"
}
}
}
};
</script>
新しいコンテンツの読み込み時、または SPA ページでのアクション発生時は、Analytics にデータを送信するルールを実行するよう Experience Platform タグに通知する必要があります。これには、直接呼出しルールまたはカスタムイベントの 2 つの方法があります。
例: このヘルプドキュメントには、Analytics を実装するサンプル SPA サイトおよびその他の Experience Cloud ソリューションへのリンクがあります。これらの例では、次のカスタムイベントが使用されています。
これらのイベントの発生の仕方とタイミングについて詳しくは、上記のページとドキュメントを参照してください。実装で同じイベント名を使用する必要はありません。使用されるメソッドの機能的なユースケースは、それぞれの推奨ベストプラクティスとして理解するのに不可欠です。次のビデオでは、カスタムイベントをリッスンする Experience Platform Tagsでのサンプル SPA ページとサンプルコードを説明します。
SPA の操作をする際に Analytics について理解しておくべき重要な概念は、s.t()
および s.tl()
の違いです。コードは、Experience Platform Tags でこれらのメソッドのうち 1 つまたはその他をトリガーし、Analytics にデータを送信します。
s.t() - 「t」は「track」を指し、ページビューを表します。ビューが新しい「ページ」として見なされる程度に変更された場合は、この呼び出しを使用します。一意の値を s.pageName 変数に設定し、s.t()
を使って Analytics にデータをに送信します。
s.tl() - 「tl」は「トラックリンク」の意味で、リンククリックまたは小規模なコンテンツ変更を表します。ビューの変更が最小限の場合は、s.tl()
を使用して、インタラクションに関する一意の値を Analytics に渡します。渡された変数は s.pageName ではないので、s.tl()
の呼び出しを受信したときに Analytics で無視されます。
ヒント: 一般的なガイドラインとして、画面が 50%以上変わった場合は、s.t()
ページビュー呼び出しを使用します。 それ以外の場合は、s.tl()
を使用します。 ただし、新しい「ページ」を構成するアクションと、Adobe Analytics レポートでの表示方法を検討する際には、ご自身で判断するようにしてください。
次のビデオでは、タグで s.t()
または s.tl()
をトリガーする場所と方法を示します。
適切なデータを的確なタイミングで Analytics に送信します。SPA 環境では、Analytics 変数に格納された値が保持され、不要になった時点で Analytics に再送信される可能性があります。Analytics Tags 拡張機能には、次回の呼び出しで誤って Analytics にデータを送信しないように変数をクリアする関数があります。
上の図は、データを送信した後にクリアされた変数を示しています。実際には、呼び出しの前でも後でも構いませんが、Experience Platform Tags のルールの一貫性を保つことで、よりクリーンな実装が可能になります。s.t()
を実行する前に変数をクリアする場合、呼び出しの直後に新しい変数を設定したあと、新しいデータを Analytics に送信します。
注意:s.tl()
を実行するたびに変数のクリアが必要になるわけではありません。この呼び出しでは、linkTrackVars 変数を使用して、設定する変数を Analytics に指示する必要があります。これは、設定を通じて Experience Platform Tags で自動的に行われます。SPA 環境での s.t()
呼び出しの動作とは異なり、誤った変数が設定されるのを防ぐことができます。最もクリーンで最も信頼性の高い実装を確保するために、SPA 環境では、両方の呼び出しに変数クリア関数を使用する方が簡単な可能性があります。
次のビデオでは、Tags で変数をクリアする場所と方法を説明します。
Tags Analytics 拡張機能でカスタムコードを挿入できる場所としては、「ライブラリ管理」セクションと「カスタムコードを使用したトラッカーの設定」セクションの 2 つがあります。
これらの場所のいずれかで、SPA ページの最初のページ読み込みに対して、そこに含まれるコードが 1 回だけ実行されます。 ビューまたはアクションの変更時にコードを実行する場合は、そのコードを適切なルール(例:「ページの読み込み:イベント/表示/終了」ルール )に実装して、そのルールが実行されるたびにコードが確実に実行されるようにします。ルールでそのアクションを作成するときは、拡張機能 = コアとアクションタイプ = カスタムコードを設定します。
一部に、従来のページと SPA ページの組み合わせで構成されているサイトがあります。このような場合は、両方のページタイプで機能する戦略を使用します。サイト上でカスタムイベントを設定し、Experience Platform Tags でルールをトリガーする場合は、ハッシュの変更などに基づいて重複ヒットが Analytics に送信されないようにしてください。この場合は、ページビューの 1 つを抑制して、Adobe Analytics に重複データが渡されないようにします。
より詳細な制御を行うために、機能を一意のルールに分ける場合は、それを行ったことをドキュメントに残しておくことを忘れないでください。一方のルールを変更する場合は、もう一方のルールにも同じ変更を行うようにします。
A4T を使用して Target と統合する場合は、同じビューまたはアクションで送信された Target および Analytics リクエストが同じ SDID パラメーター値を渡すことを確認します。これにより、データがバックエンドで正しく同期されます。
これらのヒットを表示するには、デバッガーまたはパケット監視ツールを使用します。 アドビでは、このための Experience Platform デバッガーを提供しています。これは Chrome 拡張機能で、ここからダウンロードできます。 Target は、ページで最初に実行される必要があります。これは、デバッガーでも確認できます。