16 Most common Google Tag Manager mistakes

Updated: May 6th, 2021. 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 super awesome 5-step tutorial few more times, but it doesn’t help.

You feel stuck, irritated and decide it’s enough GTM for today. The next day you open GTM, take a fresh look and realize you did a stupid and 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 committed or I have noticed that others are 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 Google analytics real-time reports
• Not removing old Google Analytics implementation (completely)
• Not using the GA Settings Variable
• Using dataLayer = []; and putting it after GTM snippet
• Using too many auto-event listeners
• Typos (duh…)
• 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

 

MISTAKE #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.

 

MISTAKE #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).

Another tip – right after you (or your developer) adds a GTM snippet to a new website, publish a version of the empty container (with default settings).

If an unpublished GTM container’s snippet is placed on a website, you’ll get a 404 error (GET http://www.googletagmanager.com/gtm.js?id=GTM-XXXXXX) in the browser’s Javascript console (learn more about that here). This isn’t a big problem, but if your developers are tracking Javascript errors with particular tools (e.g. TrackJS), they’ll see those 404 errors in reports. This will create an unwanted noise for them (yes, I know they can use filters, but simply publishing an empty container won’t hurt anybody 🙂 ).

 

MISTAKE #3 – Using 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 is using a data layer variable, that accesses the page_category key from the data layer.

So every time a page_view event is fired, you also 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 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 the place 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.

I apologize a bit for the outdated screenshot of the preview mode. But in my defense, that does not change the essence here 🙂

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

 

MISTAKE #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 of these 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 Enhanced E-commerce tracking, GA debugger is irreplaceable for me (together with the GTM/GA debug). When enabled, it displays all data that is passed to Google Analytics, thus I can troubleshoot much faster.

In fact, 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.

 

MISTAKE #6 – Not checking realtime 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 was very far from the truth because in some cases, they were accidentally sending data to the wrong Google Analytics property. Constantly checking real-time reports prevents this issue. And in other cases, they were not seeing data at all (because of filter misconfiguration in GA).

If on the other hand, you are checking GA real-time reports but they are just not working, read this guide.

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

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

 

MISTAKE #7 – Not removing hardcoded tracking codes (completely)

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, a lot of 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 all hardcoded link tracking events which caused data duplication. Some of those hardcoded events were simply missed by the developer.

 

MISTAKE #8 – Not using the GA Settings Variable in Universal Analytics

If you have ever tried to use Google Tag Manager, you’ve probably noticed that for every Universal Analytics tag, you need to set parameters/settings individually, e.g. Tracking ID, cookie settings, Cross-domain tracking parameters, etc.

Back in the old days, this was super difficult to manage. You had to create a bunch of Constant (or other types of) variables and manually set in every GA tag.

Eventually, things have gotten much easier with the help of a Google Analytics Settings Variable. This is a central place where your GA settings are kept. Whenever you want to create a Universal Analytics tag, you just reuse the same GA Settings Variable that contains parameters like Tracking ID, etc.

To learn more, read this guide.

 

MISTAKE #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. 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 snipper below the Google Tag Manager container JavaScript code, the Data Layer will be broken.

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 -->

Even a better option (MUCH MUCH BETTER) is to command dataLayer with 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, then bookmark this blog post about common Google Tag Manager mistakes and come back later. If not, let’s roll!

 

MISTAKE #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.

 

MISTAKE #11 – Typos (duh…)

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

• 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

A lot of marketers and digital analysts started using Google Tag Manager (probably) because they believed the promise that they will 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 frontend) 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.

 

MISTAKE #13 – Not Using Regex in order to reduce the number of conditions/triggers

What happens when you want to add multiple conditions to fire one tag? Usually, people create either 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 definitely 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 on how to create “OR” conditions in Google Tag Manager, read this guide.

 

MISTAKE #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.

 

MISTAKE #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 the majority of online forms. At least that’s what I’ve experienced.

And what do beginners do after the built-in trigger form does not work? Apparently, they choose a Click trigger as plan B, which is a super bad idea. Why? Because 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, 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.

 

MISTAKE #16 – Not having a proper naming convention in place

Working in a GTM container that has a lot of tags/triggers/variables but as 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, that’s why 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.

 

Do you know other common Google Tag Manager mistakes?

Have you come across any other common Google Tag Manager mistakes? I’d really like to hear them and add them to this list. You can contact me via Twitter, LinkedIn, o just simply post a comment below.