How does it work?

Motivation

The problem

Developing websites often require interventions from multiple people, from developers to QAs, Business Analysts to Digital Analysts, and many more. On large modern websites with rich user interactions, like typical E-Commerce sites, validating Analytics features can become tricky.

While everyone agrees that these features are essential in order to gauge the success of a website, it might take a few iterations before starting to gather reliable, actionable data. Incomplete implementations due to cut back features or short deadlines, lack of understanding of best practices, lack of ownership are but a few causes of improper or unreliable data.

Without reliable or complete data, decisions cannot be made. Insights cannot be gathered. Reports cannot be analysed.

This is why members of the team should all be mindful of the importance of collecting proper data as soon as possible in the development lifecycle. As soon as a feature with an Analytics component is added, it should be part of a test plan.

Only testing Analytics requirements can be long. Few people are willing to manually execute test suites requiring opening browser tabs and waiting for data to appear in the Realtime View... And thus, it is easy to stop executing these tests. And then, it is too late.

Once in production, data is skewed, missing, incomplete or incorrect.

The solution

The solution is to run tests regularly, and to involve the whole team.

By allowing tests to be run automatically, in real browsers, in multiple resolutions, by mimicking the actions real users do, it becomes possible to gain visibility on the data collected. Reacting to changes becomes easier, changing implementations without losing features becomes easier to validate, and people become more involved in the process because they can now see the data, which is no more invisible to them.

This is the problem Google Analytics Web Tester tries to solve.

How it works

The tool packages a set of helper functions for Protractor, an end-to-end test framework runnings tests against an application running in a real browser, interacting with it as a user would.

Using Protractor as a test runner, the tool injects custom JavaScript code into the browser for each page loaded, so that calls made to Analytics' ga() function can be intercepted.

Thus, it becomes possible to return it to Protractor and validate that it matches the expected values.

Example

For example, say you wanted to send a Custom Event to Google Analytics when clicking on a button:

jQuery('#jumbotronCTA').on('click', function (event) {
   ga('send', 'event', 'Button', 'Click', 'Jumbotron CTA');
});

The library would then intercept that data and return it to Protractor after simulating a click on the button. Using that information, developers and QAs can write tests validating that the data sent to Analytics actually matches the expected values:

// (In Protractor test file.)
// ...

// Actual intercepted data:
// gaData = ['send', 'event', 'Button', 'Click', 'Jumbotron CTA']

expect( gaData ).toEqual( ['send', 'event', 'Button', 'Click', 'Jumbotron CTA'] ); // true! Success!

Note: The data format is covered in more details on Getting the Google Analytics Event data.

Now say, due to some last-minute changes the day before deploying to production, someone accidentally replaces the Custom Event Label to the following:

jQuery('#jumbotronCTA').on('click', function (event) {
   ga('send', 'event', 'Button', 'Click', 'Add to Cart CTA');
});

When running the Protractor test scenarios, this would cause a failure, since the labels "Add to Cart CTA" will not match the expected "Jumbotron CTA":

// (In Protractor test file.)
// ...

// Actual intercepted data:
// gaData = ['send', 'event', 'Button', 'Click', 'Add to Cart CTA']

expect( gaData ).toEqual( ['send', 'event', 'Button', 'Click', 'Jumbotron CTA'] ); // false!

With this test failing, the accidental code change can be reverted and the test suites can run without error. No loss of data in production!

Getting the Google Analytics Event data

Base mechanics

How do you know which Event structure to expect in order to write your tests?

Let's say your standard ga() call looks like this when clicking on the Jumbotron CTA of the demo application (will be the same if Event Tracking is set through GTM *):

ga('send', 'event', 'Button', 'Click', 'Jumbotron CTA');
    │       │        │         │        └──> 5. Event Label
    │       │        │         └───────────> 4. Event Action
    │       │        └─────────────────────> 3. Event Category
    │       └──────────────────────────────> 2. (Standard Google Analytics parameter)
    └──────────────────────────────────────> 1. (Standard Google Analytics parameter)

Then, after the ga() is executed, the value of window.GAWebTester.getLastEvent() will be:

  ['send', 'event', 'Button', 'Click', 'Jumbotron CTA']
    │       │        │         │        └──> 5. Event Label
    │       │        │         └───────────> 4. Event Action
    │       │        └─────────────────────> 3. Event Category
    │       └──────────────────────────────> 2. (Standard Google Analytics parameter)
    └──────────────────────────────────────> 1. (Standard Google Analytics parameter)

*: If using Event tracking through Google Tag Manager (GTM), then the Container will generate some JavaScript exactly matching the pattern of the ga() call above. Just add the send and event values to the Array.

Getting more samples

More Spec file samples are available for the following Google Analytics features:

How does it work? How-to Guide