15 Most common Google Tag Manager mistakes

Updated: March 26th, 2020. 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. Let’s hope this blog post will save you some time and energy.

 

Table of Contents

• #1. Viewing the wrong Google tag manager account
• #2. The container is not published
• #3. Not refreshing Preview & Debug mode or browser tab
• #4. Not using preview and debug console properly
• #5. Not using other debugging tools
• #6. Not checking Google analytics real-time reports
• #7. Not removing old Google Analytics implementation (completely)
• #8. Not using the GA Settings Variable
• #9. Creating datalayer dataLayer = []; and putting it after GTM snippet
• #10. Using too many auto-event listeners
• #11. Typos (duh…)
• #12. Not cooperating with developers
• #13. Not Using Regex in order to reduce the number of conditions/triggers
• #14. Publishing all the changes at once
• #15. Tracking forms with Click Trigger
• Final words

 

MISTAKE #1 – Viewing the wrong Google tag manager account

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

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 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 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 – Not refreshing Preview & Debug mode or browser tab

Google Tag Manager’s preview mode allows you to preview all your current changes of the GTM container (without publishing them to all of your visitors) After you enable the Preview and Debug mode, a large orange notification banner will appear in GTM user interface.

Once the preview mode is enabled, navigate to the site where the container is implemented and you will see a debug console window at the bottom of the browser showing detailed information about your tags, including their firing status and what data is being processed.

Each time you do changes in Google Tag Manager (e.g. add new tags, triggers, etc.), you need to complete the following steps:

• Click Refresh link in orange preview notification banner.
• Refresh the browser tab of the site you are currently testing.

Remember: You must complete these steps every time you want to preview and test new changes in your GTM container, in THIS EXACT ORDER.

MISTAKE #4 – Not using preview and debug console properly

When an event is selected in the left column of Preview and Debug console, the Tags tab will show the tags present during that event. They are separated between those that fired during the selected event and those 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.

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

 

MISTAKE #5 – Not using other debugging tools

Tag Assistant and GA debugger are among the most popular debugging tools you should be aware of. Both of these are free Google Chrome extensions which will make your life much easier.

Tag Assistant helps troubleshoot the installation of various Google tags including Google Analytics, Google Tag Manager, Adwords Conversion Tracking and more. You can find out 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, there are even more useful Chrome Extensions to ease your work with GTM. Take a look at this list here.

 

MISTAKE #6 – Not checking Google analytics real-time reports

I’ve seen a lot of beginners not checking their GA real-time reports 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.

 

MISTAKE #7 – Not removing old Google Analytics implementation (completely)

If you have decided to migrate from hardcoded Google Analytics 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 GA Pageview tracking – just simply add GTM container snippet, publish Google Analytics Pageview tag and simultaneously remove Google Analytics tracking code from a website.

But if you’re thinking about migrating a larger website with more complex tracking, a lot of things can go wrong. Dan Wilkerson has outlined a few possible problems and how you can safely migrate to GTM without interruptions in data flow.

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

If you have ever tried to use Google Tag Manager, you’ve probably noticed that for every Google 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.

Now, 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 Google 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 – Creating datalayer 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 object (or array, depending on where are you looking) 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 + a Pageview event will not appear in the debug console. 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 – Using too many auto-event listeners

If you’re an avid fan of Google Tag Manager (like I am), you’ve probably already tried the majority of recipes posted here, googled and tested a bunch of other custom auto-event listeners (like Vimeo).

Are they all installed in your GTM containers? Do you constantly use them? If your answer is yes, then my question is do you regularly check their data as well? My mistake here was that I was tracking as many events and interactions on my websites as I could. The problem that I realized later was that I utilized only ~10% of the collected data. Everything else was just a trash in my reports.

Yes, scroll tracking is an awesome feature, but do I need it in every project? Do I always need to track Vimeo or Youtube player interactions? The usual answer is No.

First, you need to create a measurement plan and then track only what matters for that particular project. With this kind of mindset, you can easily get rid of a few auto-event listeners (at least) in each of your GTM containers. Here’s why:

• Every auto-event listener is a piece of code that needs to be executed. The more code and requests there, the more time it will require a window to completely load. Of course, usually, those pieces of code are fairly small, but (hypothetically speaking) multiply 100 milliseconds by 10 and you’ll get and 1 second added to page load duration. You can read more on how GTM can affect your page speed and performance here.
• At Omnisend (the company that I used to work in), we were using not only Google Analytics, but also Mixpanel to track user interactions. I could easily send every interaction I can to Mixpanel, but we chose to push only the most important ones because a) too many events = too much noise in various reports (especially “Filter by event” drop-downs), b) we would quickly exceed our monthly event limit. In fact, a free Google Analytics version also has some limits (10 000 000 hits per month)

Prioritize quality over quantity here. You can add additional listeners later on.

 

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 cases 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 S letter is not the same as 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.

Enhanced 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” deployments.

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: publish changes in 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 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 they the built-in trigger form does not work? Apparently, they choose a Click trigger as a 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, 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.

 

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 my lessons 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.