JSSによるトラッキング、分析、パーソナライズ

Sitecoreレイアウトサービスのリクエストの追跡

レイアウトサービスへのリクエストは、従来のSitecoreサイトと同様にサーバー側でページビューとして追跡されます。これには、ルート項目によってトリガーされるよう設定された目標やイベントなどが含まれます。Sitecoreのセッショントラッキングはクッキーベースであるため、JSSアプリはデフォルトでブラウザクッキーをレイアウトサービスのリクエストに渡します。

レイアウトサービスはSitecore MVCレンダリングエンジン内で実行され、標準的なページビュー、目標、イベント、コンポーネントレベルのパーソナライズ、コンポーネントレベルのコンテンツテストのためのSitecore分析追跡と機能を維持します。ページレベルのコンテンツテストはサポートされていません。

JSSアプリのルーティングにレイアウトサービスを使うと、各ルート変更は分析データにページビューとして反映されます。分析データ内のURLの混乱を避けるため、レイアウトサービスは解決済みの項目とそのパスをそれぞれ追跡対象とURLとして設定します。

JSSアプリや特定のレイアウトサービス呼び出しで分析の追跡を望まない場合は、trackingパラメータをfalseに設定してください。

!重要Sitecore 10.0.1以降、SitecoreはすべてのクッキーにデフォルトでSecureフラグを設定します。これは、接続モードやヘッドレスモードでJSSのローカル開発に影響を与えることがあります。なぜなら、アプリケーションがHTTPSで動作していない場合、プロキシされたSitecoreクッキー(分析クッキーを含む)はブラウザによって拒否されるため、訪問が追跡されず、コンテンツがパーソナライズされない場合があります。これを回避するために、以下のいずれかの方法があります:

• ノードサーバーを改変したり、ローカルリバースプロキシを使ったり、ngrokのようなサービスを利用したりして、ローカル環境でHTTPSを有効にしてください。開発用にコンテナでSitecoreを実行する場合は、そのdocker-compose環境で提供されているTraefikリバースプロキシを利用できます。

• Sitecore Web.configを次のように変換します:

• httpCookies構成では、requireSSLをfalseに、sameSiteをUnspecifiedに設定します。

• sessionState構成では、cookieSameSiteをUnspecifiedに設定します。

本番環境での回避策は推奨しません。

JSSトラッキングAPI

クライアントサイドアプリでは、通常XConnectに分析イベントを報告するために使われるサーバー側APIにアクセスできません。代わりに、JSS Tracking APIを使えば、ページやルートビュー、イベント、目標、成果などの分析イベントをクライアントから直接 プッシュできます。

レイアウトサービスと同様に、適切なイベント帰属を維持するためにブラウザクッキーをこのAPIに渡すことが重要です。

JSSトラッキングAPIには以下の制限があります:

• JSSアプリケーションは JSSが提供するRESTレイアウトAPIを使用する必要があります。
• 追跡データは直接Sitecoreサービスに提出されるため、 切断モードでJSS追跡APIを使うことはできません。
• グローバルクッキーやセッションクッキーが生成されなければ、JSSのトラッキングAPIは動作しません。

サーバー側でJSSアプリをレンダリングする際のトラッキング

JSSアプリは通常、初期ルートのためにサーバーでレンダリングされます。最初のページ読み込み後のルート変更はクライアント側でレンダリングされます。これは分析収集に問題を引き起こしません。なぜなら以下の点です:

• ルートビューはサーバー側レンダリング(SSR)中に追跡され、ルートはクライアントでロードされた後、レイアウトサービスにリクエストを送り戻さないため、追跡されるルートは1つだけです。
• JSSトラッカーはSSR中に自分自身にかけられた呼び出しを自動的に無視します。なぜなら、クライアントで読み込んだ後も同じ呼び出しが再び行われるからです。