1. Architecture overview

Tracking, analytics, and personalization with JSS

Version:

Sitecore gathers behavioral analytics data on visitors that can be used for informing personalization and future analysis.

Tracking and analytics

In a JSS site, there are several paths to collecting analytics data:

Tracking Sitecore Layout Service requests

Requests to the Layout Service are tracked on the server-side as page views just like in a traditional Sitecore site. This includes any goals, events, and so on, configured to be triggered by the route item. Because the session tracking in Sitecore is cookie-based, JSS apps pass browser cookies to Layout Service requests by default.

The Layout Service executes within the Sitecore MVC rendering engine and retains all Sitecore analytics tracking and functionality.

If you use the Layout Service for routing in your JSS app, each route change reflects as a page view in your analytics data. To avoid confusing URLs in your analytics data, the Layout Service sets the resolved item and its path as the tracked item and URL, respectively.

If you do not want analytics tracking for your JSS app, or for particular Layout Service calls, set the tracking parameter to false.

Important

From Sitecore 10.0.1, Sitecore sets the Secure flag on all cookies by default. This can impact JSS local development in Connected and Headless modes, as the proxied Sitecore cookies (including analytics cookies) are rejected by the browser if your application is not running under HTTPS, and therefore visits are not tracked and content might not be personalized. To work around this, you can do one of the following:

  • Enable HTTPS in your local environment by modifying the node server, using a local reverse proxy, or using a service such as ngrok. If you are running Sitecore in containers for development, you can make use of the Traefik reverse proxy that is provided in the docker-compose environment.

  • Transform the Sitecore Web.config as follows:

  • In the httpCookies configuration, set requireSSL to false and sameSite to Unspecified.

  • In the sessionState configuration, set cookieSameSite to Unspecified.

We do not recommend this workaround in production environments.

JSS Tracking API

In a client-side app, you do not have access to the server-side APIs normally used to report analytics events to XConnect. Instead, the JSS Tracking API allows you to push analytics events, such as page/route views, events, goals, and outcomes, directly from the client.

As with the Layout Service, it is important to pass browser cookies to this API to retain proper event attribution.

The JSS Tracking API has the following limitations:

Tracking while server-side rendering JSS apps

JSS apps are usually rendered at the server for the initial route. On route changes after the initial page load, they are rendered at the client. This does not cause problems with analytics gathering because:

  • Route views are tracked during server-side rendering (SSR), and a route does not make a request back to the Layout Service after it loads on the client, so there is only one route tracked.
  • The JSS tracker automatically ignores calls made to itself during SSR, because the same calls would be made again after it loads on the client.

Personalization

One of the major advantages of Sitecore is its ability to personalize and respond to a visitor's behavior. JSS takes this capability and seamlessly extends it to the headless realm, including the personalization of components.

The Layout Service renders pages using the same pathway as a traditional Sitecore site uses - meaning that personalization rules, multivariate tests, and so on are all respected, requiring no additional development.

The content returned to your JSS app is personalized before it is received.

If you have suggestions for improving this article, let us know!