Tracking Single Page Apps

Share this article

What is a single page app/websites?

Single page web application or SPAs are seamlessly adopted a lot over the last few years, with content being rendered on the fly makes for a continuous and easy-to-use digital web experience. But with all the advantages it may bring, there’s a few things we need to take into account when developing an analytics implementation.

A distinguishable trait of an SPA is the loading of the web page once with all content hence forth loaded asynchronously. With this, users are not faced with multiple page loads providing a better user experience because of common resources such as HTML, CSS and scripts that do not require a reload.

SPA developments are typically coded with, but are not limited to the following JavaScript frameworks:

  • Angular JS – a JavaScript-based open-source front-end web application framework mainly maintained by Google
  • React JS – developed in house at Facebook and released in 2013.
  • Vue JS – is an open-source JavaScript framework for building user interfaces. Integration into projects that use other JavaScript libraries is simplified with Vue because it is designed to be incrementally adoptable
  • Ember JS – is an open-source JavaScript web framework, based on the Model–view–view model pattern. It allows developers to create scalable single-page web applications by incorporating common idioms and best practices into the framework
  • Meteor JS – is a free and open-source isomorphic JavaScript web framework written using Node.js. Meteor allows for rapid prototyping and produces cross-platform code

Before you start tracking a single page app/site

Due to the nature of single page apps loading content asynchronously, problems with tracking data via any tag management solution can quickly surface, These can include but are not limited to:

  • Page element i.e. button, is not available on page load.
  • Data not available on the click of a button i.e. the transaction ID is not available on click and is being retrieved asynchronously on the button click.
  • Tracking a page change does not work because the URL does not change.
  • Data falling off because how the content is loaded has changed or is somehow delayed.
  • Inaccurate bounce rates and large time on site.

Designing a single page app/site implementation

As much as tag management systems (TMS) offer functionality to allow non-developer involvement in tag implementations, SPAs are unfortunately an inevitable exception. While your TMS may have the ability to cater for single page apps/sites, the nature of asynchronous loads, content or data availability differing from server to server, alternate development styles or even user internet speeds, can all result in the need for specialised and technical solutions.

As such, the key to managing and implementing tracking for any SPA is a framework of data tracking governance. This provides all involving parties (analyst, developer and tag manager) a single source of truth that everyone can reference to.

SPA Implementation Examples

A commonly used method to facilitate the implementation of analytics across an SPA is to use a structured and re-useable framework which provides both familiarity in how and where data is stored, but is also flexible enough to handle the many different ways in which data may need to be captured. W3C digitalData is an early example of such a framework and at Digital Balance we have iterated on this design over projects with many different clients. Here is a list of advantages of using a data layer populating information on data availability:

  • Allows the tag managers to pick up the data when it’s available. This prevents an empty variable being tracked on occasions where tracking requires lists of information being available.
  • Allows a platform agnostic implementation (GTM, DTM will be able to pick this up. This also simplifies the process of migrating tag management solution (if necessary).
  • There is visible on page code that the developer can see and is aware of, so analytics code isn’t accidentally removed from a code fork.
  • Dismisses any timing issue where a tag is fired too early or late, as rules are triggered on data element population.
  • One source of truth – An article name retrieved from a data layer leaves little room for interpretation when it comes to reporting.

How does the website function?

Your first priority when determining how to track your single page app is to figure out how the website actually works. Once you have got that down pat, you will need to create a framework, and then functions to cater to that framework. The frameworks you create could mostly be made up of direct call rules, or even looking at which data layer elements can be populated before firing the tag yourself.

Figuring out what needs to be tracked…

The next step in the process is to figure out what you actually need tracked. The best way to go about this is to work hand in hand with your data planner to figure out which sections and functions of the site are important to track. Once you have this mapped out, you can create the code to hand off to the developers for implementation.

How to go about tracking the site…

The nature of a single page app is it’s asynchronous page loading, which can result in major headaches for developers when it comes to analytics tracking. The difficult part is coordinating the data to be present before actually firing the tag.

In order to make sure tracking is correctly set-up on a single page app, a developer needs to wait for the new values to arrive in the data object before firing a direct call rule (if using DTM). Alternatively, an event handler can be bound to the data object which can react to any changes and execute tracking calls accordingly.

Want to talk to us about tracking? Get in touch!


Share this article