Why your Google Tag Manager set-up needs a spring clean

What is Google Tag Manager?

Google Tag Manager (GTM) was released eleven years ago (February 2013) and is older than the now-retired Universal Analytics, even though to me it feels like the newer of the two. It is a way of managing what data is recorded on a website. Google Say:

“Google Tag Manager is a tag management system (TMS) that allows you to quickly and easily update measurement codes and related code fragments collectively known as tags on your website or mobile app. Once the small segment of Tag Manager code has been added to your project, you can safely and easily deploy analytics and measurement tag configurations from a web-based user interface”.

That’s potentially eleven years of tag accumulation!

How does GTM work?

Google Tag Manager is a js script that sits on every page of your website and controls what information is captured and when.

For example, a page_view will be captured when someone looks at a page and a navigation click can be recorded when someone navigates from the homepage to a service page.

While these can be hardcoded onto the page, GTM means that after the initial implementation, this can be done through a web UI, so developers don't need to be involved.

Why is GTM used?

It's a great way for an agency or internal team to manage social and event tags without involving a Dev team every time something needs adding, which in the quick reaction digital world can be an amazing thing to have.

It also has good controls and can manage both a single site and complex multi-site environments, and can have publishing controls to go alongside that. So you can (for example) give an agency view access but not publish access.

It's a fantastic tool and over time there is likely to be an accumulation of tags, something that as an analytics team we include within our audits.

Generational Cruft!

With any codebase there is 'cruft', which is the accumulation of old, dead, spaghetti code that contributes to 'technical debt', it makes it harder to implement functionality and will most likely make a site slower.

What contributes to Analytics Cruft?

There are a lot of reasons why your analytics container is bigger than it needs to be, for example, there could be:

• Old Social pixels
• Old Adwords pixels
• Custom HTML and .js
• Now defunct UA tags
• Tags and triggers that aren't needed
• Duplicated / old triggers, events and page views
• No longer used CRO Tools (like Hot Jar and Crazy Egg)
• Cookie Banners

The list goes on.

In most GTM containers you'll find tags that are specific to website measurement (like page_view events and conversions) alongside social pixels, custom HTML and scripts for CRO tools like Hotjar and Crazy Egg. At the same time, custom HTML and JS can be added. If this is badly written, or has been superseded, it's all adding weight to the container.

Over time, marketing agencies change, and internal owners change which can mean that the GTM container is bigger than it needs to be - it's these that we are interested in cleaning up.

Practical things you can do

1. Remove UA tags and specific event triggers

As UA has recently been replaced by GA4 it's a good time to remove the tags, triggers and events associated with it as these are no longer being used.

2. Audit Custom HTML and .js

Custom code can be added through GTM and is a powerful way to manipulate the datalayer for better data capture. The downside is that without a process in place to remove old code these will run forever.

Depending on how the code was implemented there could also be issues with the efficiency of the code, if it’s dependent on site CSS then if that has changed it will break the tag.

A recent example was a donate button where the CSS class had changed from big-red-button to red-button in a site redesign, as the trigger was based on the former, it hadn't worked in 7 months.

GTM functionality changes and is improved all the time, it's worth auditing these and removing any that can be implemented more efficiently.

3. Old social pixels

This is both an optimisation opportunity, in that you can remove all the old accounts that aren't needed, and a good reason to check how your social triggers work.

There have been instances recently where charities have been shown to send very sensitive data back to social platforms when they probably shouldn't. Understanding what sensitive content you have and ensuring that social tags aren’t being fired on them is critical to maintaining customer trust.

4. User access

While we're looking at GTM (and GA) it's worth taking a look at who has access. We’re looking to remove access to the old agencies, people that have left and gmail addresses that no longer need it. After it, you'll have a much more secure GTM container.

Does this work?

Yes. It can work really, really well.

On a recent client audit for Marie Curie, we found a very large container which had over 100 custom HTML tags, marketing tags and social pixels, and was 91% full. From a practical perspective, it meant that the client team were having real issues managing the container as it was too complex and unwieldy.

Our analysts worked with the client to streamline all of these tags down to just 20 tags, using custom variables to still provide all of the previous marketing functionality. This reduced the size of the container by 60%, this improved page load times from over 4 seconds down to under 2 seconds on desktop. Which, when you’re looking at 200ms making a difference,is a massive win!

I'll be talking more about this at BrightonSEO in April 2024, taking place on the 25th and 26th. Be sure to stop by and say hello if you're attending.