Common Google Tag Manager Mistakes & How to Avoid Them

Migrating to Google Tag Manager for your analytics and tag management needs can be incredibly beneficial. This is because GTM enables agile working and data enrichment with limited, and often no developer assistance. However, as a web analytics consultant I regularly come across common Google Tag Manager mistakes that can break GTM or prevent you getting the full benefits.

What is Google Tag Manager?

Google Tag Manager is a platform for managing marketing code or scripts (known as tags) on a website or app. These marketing solutions include Google Analytics, Google Adwords, remarketing tags, customer experience tools (e.g. Hotjar or SessionCam), Facebook pixel and A/B testing (e.g. Google Optimize or Optimizely) platforms.

How does it work?

Google Tag Manager injects the scripts onto your website. For example, if you are using GTM to manage Google Analytics, when a user lands on your website GTM will fire the Google Analytics script. It triggers tags which load when a visitor hits your site. This will enable you to track the interactions of website visitors on every page.

If GTM has been carefully planned and implemented it can reduce load times and help to enhance the user experience. However, because GTM injects code directly onto your website, if you do not look a it carefully, it can break a website and increase load times. That’s why migrating to Google Tag Manager needs to be planned and managed by technical experts.

Why should you use Google Tag Manager?

Google Tag Manager minimises the amount of marketing code on your website. It only injects script when it is required. This can improve load speed by removing JavaScript which can often delay page rendering.

It also allows you to create complex triggers and tags to measure user behaviour on a website. You don’t need any help from developers. GTM is a must when you are working in an agile team. The implementation and testing can be done within GTM and on your website using the preview and debug mode.

The Most Common Google Tag Manager mistakes to avoid:

1. No Measurement Plan:

The easiest mistake is to begin with the data, rather than defining what you need to measure. Use the ecommerce performance framework from Jonny Longden to align customer objectives with the organisation’s business model. This will ensure you focus on customer needs and identify the relevant metrics and dimensions to include in your measurement plan.

Source: Jonny Longden

By creating a measurement plan you can define the scope of your GTM implementation and how to structure the GTM account. The best practice is usually to create a separate GTM container for each website (i.e. for subdomains and domains). You will also need to consider how you want report on the data.

What about other domains (e.g. payment gateways), and subdomains for different environments or areas of the website? How important is page load speed and data security to your business? If these are critical issues. Do you need to consider server-side GTM to prevent the leaking of personal identifiable information (PII) and the optimisation of site performance?

These issues should be in your measurement plan and put into actions for your tag plan.

2. No Audit of Google Analytics:

Using a Google Analytics audit checklist and documenting what you find will help inform your planning for implementing Google Tag Manager. It will highlight gaps in data collection and data quality issues. You need to be aware of these before you implement GTM.

The lack of a Google Analytics audit often accounts for a GTM implementation which has a poor scope. It doesn’t fully meet the performance measurement needs of the business.

3. Lack of allocated IT or developer resource:

To implement GTM script and preload data in the data layer it is essential that you have IT buy-in and resources. Many IT people have no experience of Google Tag Manager or an understanding of data layers. Which means that they will need training.

The best GTM implementations I have seen are in small agile teams. That’s because agile teams usually include front and back-end developers, a tester and a business analyst who defines business requirements and manage priorities.

4. Insufficient Technical Planning:

How will GTM be implemented? Will adding the script to the top of the <head> and <body> tags be a problem or are plugins to be used? Will the same GTM container be used for all subdomains and how will iFrames and other domains be tracked? It is normally better to add script directly to the website. This may depend on the platform your website sits on and the plugins you use.

To avoid Google Tag Manager mistakes, these details will need to be thought out before implementation. When technical planning is forgotten about you will often find there are gaps in GTM coverage because no one thought to include other domains or iFrames and embedded applications in the scope of the project.

5. No QA planning process:

Google Tag Manager should be deployed to multiple websites, such as pre-production sites (e.g. DEV and UAT) for QA testing purposes. This allows for testing tags on secure pages and a robust testing regime before any changes are published in the live environment.

This enables tag configuration and testing for new content before it goes live. It ensures you can measure the impact of a release from day one. GTM also has a Preview/debug mode which can test changes in GTM tags on either a pre-production or live site. Chrome Tag Assistant is another tool which can review and debug your GTM implementations.

Ensure you have implemented GTM to utilise these resources and have a robust QA process in place. This will reduce the risk of GTM changes breaking your live site or experiencing a loss data in Google Analytics.

Unless tags are tested on either a pre-production environment or on the live site, it is impossible to know they are working correctly. It is important to have confidence that tags are sending accurate data to Google Analytics. I often come across tags that have clearly never worked.

Example

If a tag is set to fire on the click ID, but the ID in the trigger is incorrect. It would never work until the spelling mistake changes. Furthermore, the event was on a secure page, and it was difficult to get a test account for the live site. But all triggers were set to fire based upon the exact page URL and so it could not have been tested on UAT either.

6. No Modification of Content Security Policy:

If your site has a Content Security Policy (CSP) and it’s implemented without modifying it to make allowance for Google Analytics and Google Tag Manager, you will find neither work correctly. CSP automatically blocks JavaScript inline snippets, Google Analytics and Google Tag Manager use this. As GTM uses JavaScript snippets to fire Google Analytics script you need to modify your content security policy for both solutions.

CSP issues:

• Blank debug panel in Preview mode
• Debug panel displays, but without styles
• Google Tag Manager fails to load, and you will see Content Security Policy errors in the Chrome JavaScript console (see below)

You will also notice tracking beacons (e.g. image requests) from Google Analytics to send data will also be blocked by the CSP (see example below). If you are using GTM to load third-party pixels (e.g. Facebook or Hotjar), you will also need to permit the appropriate image of scripts to run for these solutions as well.

If you have problem caused by a CSP, go to this excellent article from Bounteoeus entitled Using Google Analytics and Google Tag Manager with a Content Security Policy. This explains the nature of all the issues and how your IT department can fix them.

7. Over Tracking of Events:

There is a danger that organisations become too enthusiastic about GTM and as a result they try to measure everything. Your measurement plan will help to avoid this happening, but it is certainly the case that sometimes a GTM container will have multiple tags measuring the same event.

A large number of tags makes managing a GTM container time consuming. It becomes more difficult to keep track of everything. But of more concern is that your site’s load speed will inevitably suffer as the size of your GTM container grows and more hard-coded tags are added to the site.

Creating a tag plan for each container will allow you to understand the nature of each tag and whether it is activated or not. This will help you identify duplicate tags. It also allows you to remove redundant or unnecessary tags to prevent the GTM container becoming bloated.

8. Don’t use RegEx or Lookup Tables:

Many GTM containers have too many overly specific tags because they do not use RegEx or Lookup tables. These variables allow you to minimise the number of individual tags by grouping related or similar events into a single tag.

I explained the use of these RegEx and Lookup Tables in my blog how to deploy GTM across multiple sites. But to summarise, RegEx Tables use a pattern (e.g. hostname) and Lookup Tables use an input (e.g. a click ID) to define the event category, action and label. RegEx Tables are more scalable because they don’t have to be as narrow in how they define a pattern as Lookup Tables define the input.

For this reason, Lookup tables can become very large and time consuming to complete. This means Lookup tables can be less efficient in terms of container size, which may impact the weight of the js tag which GTM loads on a page. However, because many Lookup tables measure events which occur after the page has fully loaded (e.g. click events). The size of the table is unlikely to impact on load speed.

If you are concerned about the size of a Lookup table and how it might affect load speed, try delaying when the script loads. By using variables and inbuilt triggers you can specify when a tag fires to minimise the impact it has on load speed.

I often use Lookup tables for click events which can create very large variables. To help with this process Simo Ahava has produced a post. This explains how to create a Lookup Table generator to make this more efficient.

9. Conversions Not Correctly Tracked:

Form submissions and other call-to-action button clicks are often tracked as conversions when we don’t know if they were successful. Similarly, when the payment confirmation page URL is identical for all payment outcomes (i.e. accepted, declined or error), measuring this as a goal conversion is also misleading.

The solution is to set up form tracking correctly. Implement e-commerce tracking in Google Tag Manager to measure transactions rather than just progress through a website. This will provide you with much more accurate data on conversions and significantly enrich the data you send to Google Analytics.

10. Old Google Analytics Implementation not removed:

This is normally not an issue for small websites and simple implementations where there are no hard-coded tags. It is more problematic for larger sites and where tags have been hard-coded onto the website.

This can cause conflicts with GTM, duplication of data and in some cases prevent tags from working. It’s important to completely remove hardcoded events and Google Analytics code during your implementation to avoid these issues.

We all make mistakes:

Google Tag Manager is a powerful and flexible platform for managing marketing tags. However, like most digital marketing solutions it requires careful planning and technical knowledge to implement and maintain. Not surprisingly we all makes mistakes. You may recognise some of the common Google Tag Manager mistakes. But by sharing some of the more common errors, you can avoid making the same ones.