Technical

Analytics, Analysis and JS
App Architecture

by on 2nd June 2016

If you’re building things in Angular 2 or React, have a component that composes the application and track module loads, as well as specific interactions to learn interesting things.

Background

A while ago I built a search-friendly React.JS app to test how people interact with very long form content on the web, on different devices. However, in doing so, I also decided I wanted to test ideas as to how to track content built in JS based front ends (namely React and Angular 2).

React and Angular

There’s a problem with traditional GA setup on the majority websites – it’s a fishing expedition. The tracking code is added, it spits out numbers on page views, conversions, goals etc and you’re happy because now you have analytics. But you can’t do any real analysis on that.

Here’s why…

Towards Scientific Analytics

To use analytics properly, we have to have something we want to analyse at the outset. Otherwise we’re just collecting data and hoping it’ll tell us something useful. That may be the case, but it’s better to have an initial thing you want to understand.

In my case, the questions that I wanted to answer were:

  1. Will people read really long content?
  2. Do people interact with components embedded in long text content?

The former I could answer with standard analytics. How many people visit, how many people share through social networks, what’s the sentiment of those messages, how long do they stay on various pages, what’s the return rate and so forth.

These things don’t answer the second question though. For that, you need to turn to event tracking.

For me, this is where analytics really comes alive; when you’ve got a question you want the answer to, and you collect data specifically to answer it.

In this case, I looked at loads of individual components on each page, which gave me a nice reference for what goes where, and whether people interact with various elements.

To do the first was simple, as there’s a single factory component which iterates through everything to be rendered, and then instantiates each component. As it does so, it fires a call to GA to log the component setup.

For the latter, I added event tracking to the Gallery forward and back buttons, and to a few of the Moon Landing transcript elements.

The Benefits

Because I had a question (do embedded interactive elements affect how people engage with content), and a hypothesis (yes they do), I could also create a null hypothesis (no they don’t), gather data by having some visitors see the components and some not and test the outcomes.

(For those interested, the result is that people engage better when there’s interactive pieces which regularly break up content, leading to higher overall dwell time).

This hypothesis and event tracking driven approach is something that is made trivially simple with React and Angular 2. It also allows us to treat website tracking more like app tracking, monitoring components and interactions, rather than pages and visitors, leading to more actionable data.

It also allows for movement away from the standard visits/bounce rate/page views type reporting that is often so pervasive, and towards reporting that is actionable, and research that provides real business value.

google analytics developer

(image source: GA for developers)

Non-Interaction Events

It’s worth noting that on loading component events, you need to set non-interaction event notice to GA. Events which are triggered by a user should affect bounce rate. However, instances where your code is generating the event automatically can interfere with bounce rate unless GA is otherwise told.

To make sure you deal with this correctly, take a look at the GA documentation on non-interaction events.

Wider Implications

There’s no reason that this has to be confined to small SPAs. In my day to day role, I’m using this same methodology to track interactions on a large data analysis and reporting platform. In fact, given the simplicity of setting it up, and the massive value it provides, it’s worth looking at implementing this style of architecture and tracking for any project from a CMS or blog front-end to an enterprise scale SaaS product.

The provision for developers, designers and UX teams to trivially run tests and gather data in GA to research and deploy interface interactions cannot be underestimated, nor the business value that provides.

Like this? Sign up to read more