Analytics with React-Redux SPAs and Google Tag Manager

React-Redux has become a hugely popular web development combo, but I’ve found that there aren’t too many guides out there on how to sprinkle in analytics. Most implementations I’ve seen require some modification to your app’s code, often with analytics specific business logic.

The most common pattern seems to be with redux middleware, which definitely is a step in the right direction. The redux-analytics package encompasses this pattern nicely. Every redux action becomes a place where insights can be extracted, simply by appending some analytics information to the action metadata.

const action = {
  type: 'MY_ACTION',
  meta: {
    analytics: {
      type: 'my-analytics-event',
      payload: {
        some: 'data',
        more: 'stuff'
      }
    }
  }
};

This is a great start, and I had many of these analytics payloads throughout the codebase for a while and it worked great. The problem was that whenever someone wanted to change pretty much anything, it required a redeployment. Plus you’ll often have less tech savvy users wanting to add their own insights.

We already had an integration with Google Tag Manager (gtm.js), so I was a little biased towards this implementation. This goes two-fold for other departments who were already familiar with gtm.js, which is currently reaping it’s benefits with less development overhead when adding analytics insights.

Anyway lets get started on a basic Redux integration with gtm.js and my personal analytics platform of choice — Mixpanel.

Getting Started

If you’re not already familiar with gtm.js, you can simply inject it’s javascript snippet into your app then get going. All of the configuration is driven through the gtm web UI, which has come a long way in the years.

Now on the app side, the Redux middleware approach is still the way to go here:

const analytics = () => next => action => {
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({
    event: action.type,
    payload: action.payload
  });
  return next(action);
};
// Add in the analytics middleware
let store = createStore(
  todoApp,
  applyMiddleware(
    analytics,
    thunk,
  )
);

Instead of dispatching analytics events from the application, it’s now firing everything to the gtm.js dataLayer. Each dataLayer event needs an event attribute to denote the type of event, but other than that you can structure your data format in any way that suits your application.

Now that’s pretty much it for the initial setup, assuming you already have the gtm.js snippet embedded in your application somewhere. Everything else can now be driven by the Tag Manager UI. I’ve started storing tags/triggers/variables in their own respective folders, but these can be changed at any time.

Creating the first event

To get started, lets setup the beloved page load events that management always seems to want. A typical React SPA usually has some form of client-side routing, so there needs to be a method to track the initial page view (landing) and route transitions. To capture both of these, 2 triggers are required.

Create the trigger in some folder of your choice

First, create the tag for the page load. I used the window loaded trigger here, and named it Global.pageLoad for use later.

Create the first pageLoad event

Next, create the history change event, which will capture route transitions from your SPA router (e.g. react-router). This is similar to the Window Loaded event above, but the History Change trigger can be selected instead.

Create a new tag Page View that triggers on either of these. I’ll be using Mixpanel throughout, but the same can apply to Google Analytics or your platform of choice.

Tracking authentication

The place where Mixpanel shines is tracking arbitrary events, with arbitrary (and sometimes changing) event attributes. This is the perfect behavior for a dynamic web application, and especially for the range of redux events that are fired.

In many applications, there’ll be some kind of authentication event fired. In my current app it’s structured as follows:

const authenticateAction = {
  type: 'AUTHENTICATE',
  payload: {
    user,
    token
  }
}

1. Create the trigger

This event is now available to use in Tag Manager as a custom event. Create a new trigger referencing this authenticate action:

The Event name should match the string type field in the redux action

2. Access the data

To access variables within your redux events, you need to create a Tag Manager variable for each primitive you want to access. Unfortunately there is no object dot notation access (yet).

Access the user id variable within the redux action

3. Send the analytics event

The complete authentication tag

Now that we have the trigger, and the data, we can send an analytics event. For user identity, this often varies per analytics-platform.

Create a new tag that uses the previous AUTHENTICATE event, along with the User.id variable. Inside a Custom HTML tag, the variable can be accessed using the {{VARIABLE}} notation.

Conclusion

That’s all there is to it to get started, now try login to your application and you’ll see the identification action get triggered and sent to your analytics. Now your analytics platform can grow as your application grows, without littering the code base with metadata tags.

It’s just as easy to add other actions and variables, and create triggers that fire conditionally based on the value of a variable — all within Tag Manager.