Why we’re using Google Tag Manager

Granted, just adding Analytics to our websites already gives us a lot of data — anything from the order of pages users visit, to their average age and general interests. However, depending on the website and its KPIs, this data might not tell us everything we want to know.

We can, for instance, see the number of users that visit a page with a contact form, but how are we to know how many of them are successfully submitting that contact form? How do we find out if they’re ever clicking the related articles at the bottom of articles, or where they’re clicking when they visit a homepage? How do we track clicks on outbound links?

This is where ‘event tracking’ comes in. An event is programming speak for any interaction a user has with a page, from clicks to scrolls, to form submissions. Tag Manager makes it easy to add event tracking, by providing built-in tools to set it up.

Of course, we could manually add event tracking into the code, and Analytics does give us the ability to do that. However, when we say manual, we mean manual. It would mean writing a script to be included in the codebase or even adding a line of code to every individual button we want to track. That's not ideal, because every time a change is required we would need to update and deploy the codebase.

Tag Manager is separate from the codebase. All we need to do is add the snippet to the website, after which we can make changes to the tracking on the fly and test them easily before publishing. It’s also easy to roll-back if necessary because Tag Manager saves a new version of the container every time a change is made. Plus, to implement basic event tracking a developer isn’t even really necessary—a lot of times our project managers can make basic Tag Manager updates, meaning developers can spend their time finding other ways to improve our websites.

We have a lot of different clients with a lot of different needs. Some might want to serve adverts, others might want to track transactions, others again might just want some very specific insights that Analytics does not provide out of the box. Tag Manager has a lot of built-in functionality to solve these cases, and if what you need is not on the list it still allows us to add custom code into the site as necessary. This gives us a lot of flexibility while keeping our workflow organised and transferable across projects.

We maintain a lot of websites built over time by different developers, and each website comes with its own quirks and needs. We’re constantly looking for ways to make it easier for our team to jump smoothly into a project, regardless of whether they’ve worked on it before. If we’re able to keep everything tracking-related in one place, that removes some complexity—no one will have to go scouring through code to search for how a particular piece of tracking was set up.

So if we have a client who is posting ads on Twitter, and a client that needs to set up tracking for their affiliate partner like AWIN, or one who wants to install Hotjar to get specific user feedback, all we need to do is go to Tag Manager and sort it all out there. On top of that, it’s very straightforward to install these third-party tools using Tag Manager, because most of the popular tracking, ad and analytics tools have pre-configured tags set up and ready to use. We get to keep our codebases clean and organised and know to find all third party tracking snippets for any client in one place. We also have the ability to set them up to use or remove them in a matter of minutes, again without the help of our developers.

The Data Layer is one of the key concepts of Tag Manager. It’s basically a big virtual box in which information about user interaction and behaviour is stored so that we can pass it on to Tag Manager.

By default, the Data Layer doesn’t store anything particularly useful, but if we set up event tracking, these events will be collected in the box. If for an eCommerce website, we want to pass on transaction data, like a purchase total or what’s in a users basket, we can put this in the box as well. Tag Manager keeps track of what’s in the box and lets third parties, such as Analytics, pick up the data that they need from it and use it in a way that is helpful to you. For instance, once we’ve got that transaction data from an eCommerce or donation website pulled into Analytics, we can then help set up conversion reporting and goals.

We can really add anything to the Data Layer that we want; the possibilities are endless. We might have a website that allows users to customise a product. We can create a custom event for that to add to the Data Layer, set it up in Tag Manager to pass this data on to Analytics, and now the client will have access to reporting on their users’ customisation preferences.

Even if a client might not be planning to track more than pageviews for their site initially, they often do decide that later on that they want to have access to more specific data. When we add a Tag Manager snippet at set-up, we future-proof them because Tag Manager makes it so much easier to respond to a client’s shifting needs. Implementing changes will be quicker, and therefore less costly, too.

All these benefits have sealed the deal for us. We’re implementing Tag Manager on new websites, and updating from gtag.js where necessary on older ones. It’s as simple as that.