Why not use Google's autrotrack lib in place of your Analytics modules?

[elisechant]

Just taking a look at your Analytics modules, seeing a lot of direct similarity between what you guys have built and GA's Autotrack plugins:

Alphagov:
https://github.com/alphagov/govuk_frontend_toolkit/blob/master/docs/analytics.md
Google:
https://github.com/googleanalytics/autotrack

Wondering if you already had considered this and/or what your reasons may have been for rolling your own instead of using the official lib?

[NickColley]

Hey @elisechant

Thanks for sharing this, it does look like there's an opportunity here to reduce effort on our end.

My initial thought is the browser support seems low (https://github.com/googleanalytics/autotrack#browser-support) for us.

I'm going to chat with the frontend community at GDS and see if we can take advantage of this.

Will update you with any more details. 👍

[tombye]

Hi @elisechant

I've done a bit of research that (I hope) helps answer your question.

History

Our GOVUK.analytics codebase was made a separate library in 2015. I think Autotrack was released at the start of 2016 (based purely on the commit log) so I'm guessing it wasn't around in 2015 to compare against.

The original GOVUK.analytics code previously sat in Static, the place the GOVUK Rails apps pull any shared view code from.

• Port analytics API from static #162
• Use frontend_toolkit’s analytics static#557

Our requirements for the new library were:

1. it should work in all projects not just those using Rails
2. it should provide a single interface not tied to either Google Analytics (GA) classic or universal
3. it should have enough documentation that anyone could get going with it easily, understand the API and what data is being sent to GA

We wanted a single library rather than raw GA code so developers could take what they learnt about using it on one project onto others. We also wanted it to be easier for teams to swap GA out for another solution if needed by hiding the internals.

Centralised control was an important part of this because it lets us push features/fixes out to all teams and creates a single place for any discussions on how we track things.

Outcomes

In taking this approach we’ve also found that committing to a single library we own means we get a nice process for controlling the analytics code that ends up in our projects. The code is on github so anyone can suggest a feature/fix but they need to write a pull request explaining the need which can then get checked by the community.

For example: #208

This has meant all new features end up being properly discussed and documented.

Comparisons to autotrack

Of all the plugins built for GOVUK.analytics, only external link tracking is included in the Autotrack library.

If/when we have need for more of the plugins contained in Autotrack it should be easy enough to make all those available through the existing GOVUK.analyticsPlugins interface.
In the same way the fact that Autotrack is trying to solve a lot of the same problems is useful. Anything we're doing that Autotrack implements in a better way should be used to make ours better, with the appropriate attribution of course 😊

We'd be keen to keep the GOVUK.analytics abstraction layer which, even though heavily based around the GA approach, gives us more freedom than calling window.ga directly.

[elisechant]

Wow @tombye! thanks for such a comprehensive response! Totally understand and agree with yours and @NickColley's points - makes sense. I do like the brevity of autotrack's interface though. It's possible I suppose that Google actually are leveraging your codes - some very similar naming conventions and behaviourals. Now that would be cool! Thanks again, can close.

[NickColley]

Thanks for raising @elisechant 👍 :)