By - Neal Cole

Common Google Tag Manager Mistakes & How to Avoid Them

Google Tag Manager console

10 Common Google Tag Manager Mistakes:


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 of GTM.


What is Google Tag Manager?


Google Tag Manager is a platform for managing marketing code or scripts (known as tags) to be deployed 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 when predefined rules are met. 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 and trigger tags which have been configured to load  when a visitor hits your site. This will enable you to track the interactions of website visitors on every page where GTM code has been implemented.


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 implementation is not planned and implemented with care 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 because 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. This can often be implemented without the need for any developer involvement. GTM is a must when you are working in an agile team because much of 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 created by 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 you need to include in your measurement plan.


Ecommerce Performance Framework for determining custom metrics needed
Source: Jonny Longden


By creating a measurement plan you will also be in a better position to define the scope of your GTM implementation and how you should structure of GTM account. The best practice is usually to create a separate GTM container for each website (i.e. for subdomains and domains), but 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 clearly dealt with in your measurement plan and translated 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 which you need to be aware of before implementing GTM.

The Google Tag Manager Audit Checklist


The lack of a Google Analytics audit often accounts for a GTM implementation which has a poorly defined scope and 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 do not have experience of Google Tag Manager or an understanding of data layers and so training is also often required.


The best GTM implementations I have managed have been where I worked as part of a small agile team. 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, but this may depend on the platform your website sits on and the plugins you use.


To avoid Google Tag Manager mistakes, these details should be investigated and mapped out before you begin the process of implementing Google Tag Manager. 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 and ensures you can measure the impact of a release from day one. GTM also has a Preview/debug mode which can be used to test changes in GTM tags on either a pre-production or live site. Chrome Tag Assistant is another tool which is often neglected and can be used to review and debug your GTM implementation.


GTM Preview window open on web page


A lack of testing is one of the most common Google Tag Manager mistakes because it takes time and uses up scarce resources. However, it is time well spent. 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, if at all.  It is important to have confidence that tags are sending accurate data to Google Analytics, and yet I often come across tags that have clearly never worked.


For example, I recently noticed a tag set to fire on the click ID, but the ID in the trigger had been misspelled. This meant it would never  work until the spelling mistake had been corrected. Further, the event was on a secure page, and it was difficult 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 block JavaScript inline snippets which are used by both  Google Analytics and Google Tag Manager. As GTM uses JavaScript snippets to fire Google Analytics script you need to modify your content security policy for both solutions.


CSP  issues are characterised in several ways:


      • 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).


Refused to load script due to Content Security Policy error


You will also notice tracking beacons (e.g. image requests) which are used by 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.


Refused to load image due to content security policy is a common Google Tag Manager mistake

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 and 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 deployed and whether it is activated or not. This will help you identify duplicate tags and allow 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.

A RegEx Table in Google Tag Manager


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 compared to RegEx tables, which may  impact the weight of the js tag which GTM loads on a page.  However, because many Lookup tables are used to 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 which 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  and 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 GTM 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 and you may recognise some of the common Google Tag Manager mistakes. But by sharing some of the more common errors here, you can avoid making these same mistakes. If you have come across other common Google Tag Manager mistakes, please share them below and we can all benefit from your experience.


  • About the author:  Neal  (@northresearch) provides web analytics and CRO consultancy services and has worked in many sectors including financial services, online gaming and retail. He has helped brands such Hastings Direct, Manchester Airport Group Online and Assurant  Solutions Ltd to improve their digital marketing measurement and performance.





Call Now ButtonCall Me Now!