Tracking, analytics, and personalization with JSS

Current version: 19.x

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.

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.

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.


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.

In JSS apps, personalizing components work the same as in a non-headless Sitecore site.

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.

Do you have some feedback for us?

If you have suggestions for improving this article,