16 Most common Google Tag Manager mistakes

Updated: October 6th, 2022. We’ve all been there: you open Google Tag Manager, set up tags, triggers and variables properly (at least you thought so), but that new implementation doesn’t work. You read that in-depth 5-step tutorial a few more times, but it doesn’t help.

You feel stuck and irritated and decide it’s enough GTM for today. The next day you open GTM, take a fresh look and realize you did an obvious mistake (which could have been fixed in a blink of an eye).

I’ve been there. Too many times. That’s why I’m sharing a list of the most common Google Tag Manager mistakes I’ve made or I have seen others doing them. Let’s hope this blog post will save you some time and energy.

 

Table of Contents

Here is the list of common Google Tag Manager mistakes that are covered in this blog post:

• Viewing the wrong Google tag manager account
• The container is not published
• Using Data Layer variable before its respective dataLayer.push occurs
• Not using preview and debug console properly
• Not using other debugging tools
• Not checking real-time reports or debugview
• Not removing old Google Analytics implementation (completely)
• Not using the GA Settings Variable
• Using dataLayer = []; and putting it after GTM snippet
• Not monitoring page performance
• Typos
• Not cooperating with developers
• Not Using Regex in order to reduce the number of conditions/triggers
• Publishing all the changes at once
• Tracking forms with Click Trigger
• Not having a proper naming convention
• Final words

 

#1. Viewing the wrong Google tag manager container

This mistake is popular among newbies and/or multi-taskers. The problem of “GTM Preview and Debug mode is not working” might be caused by a distraction and the wrong GTM account/container.

If you track multiple websites and/or have access to multiple Tag Manager accounts, you might be using the snippet from another account and/or container (by accident, of course). Double-check whether ID in your GTM account is the same as in the Javascript snippet that is hardcoded on a site.

 

#2. Container is not published

So you’ve started working on a new project, set up all triggers, variables, tags, etc., but you get way too little data (as if only your browser is being tracked. But what about all those other visitors?). This has probably happened because you didn’t publish the container.

Once you do a significant portion of changes in your GTM container, TEST it and then go Live by pressing the Submit button in the top-right corner of the GTM interface (+ complete all the steps that you will be asked).

 

#3. Using a Data Layer variable before its respective dataLayer.push occurs

Here’s another common mistake. You have a tag that fires on the Container Loaded event. The tag uses a data layer variable that accesses the page_category key from the data layer.

So every time a page_view event is fired, you send the page_category to, say, Google Analytics 4.

But here’s the problem. page_data dataLayer.push (that contains the page_category) occurs only after DOM Ready. This means that on Container Loaded, page_category is not available yet. Therefore, you will always send undefined with the GA4 tag.

It’s important to understand this. You can use a certain Data Layer variable only after that particular data is available in the Data Layer. What options do you have in this case?

• Either fire a tag on that particular dataLayer.push that contains the page_category key
• Or ask a developer to activate that dataLayer.push code before the GTM container snippet is loaded

 

MISTAKE #4 – Not using the preview and debug console properly

When an event is selected in the left column of the Preview and Debug console, the Tags tab will show the tags present during that event. They are split into Tags that fired and Tags that did not.

This is where you should look for the answer to Why didn’t this tag fire? A tag will be fired only if all conditions of a single trigger are met. A red X icon indicates which conditions weren’t satisfied. Use them as clues and find out how you can fix the trigger.

 

If you want to learn more about proper debugging in GTM, feel free to read this guide.

 

#5. Not using other debugging tools

GA debugger and Data Layer Inspector are among the most popular debugging tools you should be aware of. Both are free Google Chrome extensions that will make your life much easier.

Data Layer Inspector is like a Swiss army knife that adds additional information to the browser’s console, also allows you to temporarily inject the GTM container on any site, debug other analytics tools (including server-side setup), etc. Learn more here.

As for GA debugger, when it comes to Ecommerce tracking, the GA debugger is irreplaceable for me (together with the GTM/GA debugger). When enabled, it displays all data that is passed to Google Analytics. Thus, I can troubleshoot much faster.

I have prepared a comprehensive list of Chrome extensions and tools for GTM. Take a look at this list here. Also, a bunch of debugging tips is explained here.

 

#6. Not checking real-time reports or GA4 DebugView

I’ve seen a lot of beginners not checking their GA real-time reports or GA4 DebugView once they have implemented Google Analytics tracking via GTM. They had a false perception that once the GA tag fired (according to the Preview and Debug console), their task was completed.

But that is very far from the truth because, in some cases, they accidentally send data to the wrong Google Analytics property (or maybe some other technical problem occurs). Constantly checking the incoming data in real-time prevents this issue.

If you are working with Google Analytics 4, then DebugView is your friend. If you want to learn more, take a look here.

Lastly, other tools you want to implement (e.g. Facebook Pixel) can also offer real-time debugging features. Always use them if they are available.

 

#7. Not removing hardcoded tracking codes

If you have decided to migrate from hardcoded Google Analytics (or some other tool) to a more flexible implementation via Google Tag Manager, beware: the process won’t be easy. This warning does not apply to small websites with basic tracking – just simply add GTM container snippet, publish Google Analytics tag (or some other tool’s tag) and simultaneously remove hardcoded tracking codes from a website.

But if you’re thinking about migrating a larger website with more complex tracking, many things can go wrong. My e-book for Google Tag Manager beginners covers some points related to migration.

The most common issue (from my experience) was not removing some parts of the hardcoded event tracking, which caused data duplication. Some of those hardcoded events were simply missed by the developer.

 

#8. Not doing audits and not having someone in charge

When various people/parties have access to the same Google Tag Manager container, the chaos begins. An agency adds a bunch of marketing pixels, then a colleague from another department adds more tags, and then more and more.

Very often, the left hand does not know what the right hand is doing, meaning that one department/agency might not necessarily know/care what others are doing in Google Tag Manager.

The result is a bloated container full of tags that might conflict with each other. Or even better, maybe some of those tags haven’t been properly used for the last year or so. But they are still in the container, being fired on a website (thus affecting the page speed).

Remember, every additional tag affects the page speed (the impact might be trivial, but it’s still there).

So to avoid this situation, I would recommend auditing the container at least once in 6-12 months. Review all tags, and ask your colleagues if all of those tools are still being used. I have seen way too many situations where GTM still contains a tag of a tool that the company hasn’t been using anymore for the last two years. Remove everything that is no longer used.

Or even better, have one person/team in the company who is responsible for Google Tag Manager. If something must be added to the container, that person/team must be informed. And if the request is illogical or harmful, it should be rejected.

 

#9. Using dataLayer = []; and putting it after GTM snippet

Data Layer is a fundamental ingredient of a successful Google Tag Manager implementation. A data layer is an array that contains all of the information that you want to pass to Google Tag Manager. Here are a few examples of what data can be passed to dataLayer:

• User’s pricing plan
• User’s registration country, etc.

What can you do with that data? Anything you like!

For example, you can pass the user’s pricing plan as a custom dimension to Google Analytics. However, there’s one catch (and if developers make this mistake, your entire GTM event tracking will break).

If a developer adds custom information to the Data Layer like this (I mean dataLayer = xxxxxx):

var dataLayer = [{
 'pricingPlan' : 'premium',
 'registrationCountry' : 'Lithuania'
}];

…and places this code snippet below the Google Tag Manager container JavaScript code, the Data Layer will break.

No new events will be visible in the Preview and Debug mode. In other words – things will go wrong.

So it’s important that dataLayer’s snippet (as shown below) would be placed above the GTM container snippet (according to Google’s recommendation):

<script>
 dataLayer = [{
 'pricingPlan': 'Premium',
 'registrationCountry': 'United Kingdom'
 }];
</script>
<!-- Google Tag Manager -->
...
<!-- End Google Tag Manager -->

An even better option is to manage dataLayer with the dataLayer.push method. If you need any particular data to be passed to the dataLayer, ask your developer to use the dataLayer.push method instead (see the example below).

window.dataLayer = window.dataLayer || [];
dataLayer.push({
 'pricingPlan': 'Premium',
 'registrationCountry': 'United Kingdom'
});

Are you a little tired? If yes, bookmark this blog post about common Google Tag Manager mistakes and come back later. If not, let’s roll!

 

#10. Not monitoring page performance after adding additional codes/tags to GTM

When you started using Google Tag Manager, you probably saw statements like “Google Tag Manager optimizes page loading speed”.

The reality is — “it depends”. I have done a bunch of tests and saw some improvement when you compare hardcoded tracking snippets (added directly to the website) vs tags added to GTM.

Nevertheless, every added code piece to a website negatively impacts page loading speed. So if you add a bunch of different pixels, like Facebook Pixel, GA3, GA4, Reddit Pixel, Quora Pixel, Linkedin insight tag, and a bunch of other stuff, your page loading time will increase by A LOT.

So after you add some new tags, it is a very good practice to take a look at your page speed. Actually, you should run several tests before adding the codes and then compare them to what happens after you publish your changes.

I have published an article about GTM vs Pagespeed, so take a look there.

 

#11. Typos (duh…)

I’ll be quick here. When a tag doesn’t fire, always check for typos in the:

• Trigger’s conditions. If you’re using regular expressions in your conditions, double-check whether you need standard regex or ignore case option.
• Names of variables. This usually happens with Data Layer variables for me.

Also, keep in mind that the majority of fields in GTM are case-sensitive (or maybe all of them? I’m not sure.). This means that the S letter is not the same as the s.

 

MISTAKE #12 – Not cooperating with developers

Many marketers and digital analysts started using Google Tag Manager (probably) because they believed the promise that they would not need to rely on developers anymore. Ever.

The reality is quite the opposite. Even though Google Tag Manager greatly increases flexibility and the agility of marketing teams, developers might still be needed. Especially, when you have to deal with more complex setups or projects.

Google Analytics Ecommerce implementation is a good example. If you’re working on a custom e-commerce platform, you WILL need to work with developers and ask them to push the transaction/product/checkout/etc. data to the Data Layer.

Trying to implement everything on your own (and scrape the website for some data) will result in fragile setups that can easily break.

Another thing – ask a developer to quickly review the custom JavaScript code you found online and now plan to implement via Custom HTML tag. I’ve seen way too many cases when marketing teams added some unknown script and temporarily broke some features (or the entire front end) of a website.

The end result of this? The marketing team lost access to publish GTM container changes. Marketing/analytics teams and developers should be friends, not enemies.

 

#13. Not Using Regex to reduce the number of conditions/triggers

What happens when you want to add multiple conditions to fire one tag? Usually, people create multiple conditions in a trigger or assign multiple triggers to the same tag.

Technically, this will work, but there is a more optimal way to do that, regular expressions (RegEx).

Instead of having, say, multiple “contains” conditions, you can match different data with just one Regular Expression. If you want to have multiple conditions connected with “OR”, you’ll have to either create separate triggers and assign them to the same tag, or you can use just one trigger with a regular expression.

Aleksandrs Pasters has explained how you can utilize regex in GTM. You should check it out. Also, I constantly use Regex 101 online validator to check whether my regular expressions are configured correctly.

If you want to learn more about all the possible options for creating “OR” conditions in Google Tag Manager, read this guide.

 

#14. Publishing all the changes at once

When you work on a bunch of new tracking features for a week and then publish all of them at once, I call this “big bang” deployment.

And this is not a good thing. If something goes wrong with your newly published container version, you will have to revert the entire version (including things that were working).

The rule of thumb that I follow: work with smaller portions. If you implement X tracking functionality, publish it. Then start working on another one. In that case, if something goes wrong with your latest version, your previous smaller batches that you published will still be live and work fine.

 

#15. Tracking forms with Click Trigger

This mistake is popular among beginners who tried and failed to use a built-in Form Submission trigger in GTM. What they do not know is that the Form Submission trigger sucks and does not work with most online forms. At least, that’s what I’ve experienced.

And what do beginners do after the built-in trigger form does not work? They choose a Click trigger as plan B, which is a bad idea. Why? Because the click trigger tracks all clicks of a Submit button (not only successful submissions)

If a visitor tries to submit the form but accidentally leaves a required field empty, then the click trigger will be activated anyway. As a result, you’ll have way too many form submissions/conversions, which are false positives.

Solution? There is a bunch of other techniques on how to track forms with Google Tag Manager. Just try one of them.

 

#16. Not having a proper naming convention in place

Working in a GTM container that has a lot of tags/triggers/variables but with no decent naming convention is a real hell. Imagine that you see a tag called “contact”.

Contact what?

Is that a form submission of the contact form? Is that a click on a “contact us” link? Is that something else?

If you have 10 or 20 tags, even the most terrible naming of your GTM assets can cause no problem. But when you deal with 100+ items, you will waste more time.

But you don’t always know whether the new GTM container that you have just created will eventually become massive. So start using proper naming conventions from day 1.

I have published a guide about GTM and GA conventions that you might find useful.

 

Common Google Tag Manager Mistakes: Final words

In short, we all do mistakes. If I got a penny for every mistake, I’ve made… I’d probably have two pennies right now.

Just kidding! I’d be a millionaire. Mistakes teach us valuable lessons, so I wanted to share this list with you. Hopefully, you’ll manage to avoid them.

Remember, it’s much cheaper to learn from the mistakes made by others.