21 Most common Google Tag Manager mistakes

Updated: March 29th, 2025

If you’re reading this article, you’ve probably been in this situation: you open Google Tag Manager, set up your tags, triggers, and variables correctly (at least you thought so), and then it doesn’t work (or doesn’t work how you expected)! You even retraced every line in that 12-step tutorial, but still no luck.

Feeling frustrated and stuck, you call it a day with GTM. The following day, upon reopening GTM with a fresh perspective, you quickly realize there was an obvious mistake in the container (which you could have fixed in the blink of an eye yesterday if you had noticed).

Don’t worry—you’re not alone. Luckily, you can learn from the comprehensive list of Google Tag Manager mistakes (that we will cover in this article) to reduce the likelihood of this situation happening again!

Table of Contents

Here are the most common Google Tag Manager mistakes:

• #1. Viewing the wrong GTM container
• #2. The container is not published
• #3. Using a data layer variable before its respective dataLayer.push
• #4. Not using the preview and debug console properly
• #5. Not using other debugging tools
• #6. Not checking the GA4 DebugView
• #7. Not removing hardcoded tracking codes
• #8. Not doing audits and not having someone in charge
• #9. Using dataLayer = [], and putting it after the GTM snippet
• #10. Not monitoring page performance
• #11. Typos
• #12. Not cooperating with developers
• #13. Not Using Regex to reduce the number of conditions/triggers
• #14. Publishing all the changes at once
• #15. Tracking forms with Click Trigger
• #16. Not having proper naming conventions in place
• #17. Not adding the event settings variable to tags
• #18. Not labeling your container versions
• #19. Putting event parameters as user properties and vice versa
• #20. Failing to plan
• #21. Overlooking the importance of a container backup
• Final Words

#1. Viewing the wrong Google tag manager container

Beginners and multitaskers often encounter this common error. If you find that GTM Preview and Debug mode is not working, this could be caused by the wrong GTM account/container.

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

On the topic of multiple GTM containers, you should also be cautious of using the same GTM container for various websites. This can lead to data leakage, confusion and management issues. It’s best practice to create separate containers for different websites. The rule of thumb is one website, one GTM container.

#2. The container is not published

So, you’ve set up a new project and configured the triggers, variables and tags, but you notice that you’re getting too little data compared to what you expect. It’s almost as if tracking works only on your browser, but what about all the visitors to your site? This probably occurred because you forgot to publish the container.

Once you have updated or added some new elements to your GTM container (but not too many—see #14), test your changes (using Preview and Debugview) and then push your changes live by clicking the “Submit” button at the top-right corner of the GTM interface (check out mistake #19).

#3. Using a data layer variable before its respective dataLayer.push occurs

Another common mistake is trying to access data before it’s available.

Imagine this: you have a tag that fires on the Initialization 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 – the page_data dataLayer.push (that contains the page_category) occurs after the DOM Ready. This means the page_category is not yet available on the Container Loaded tag. Therefore, you will always send undefined with the GA4 tag.

Understanding that you can only access a data layer variable after that particular data is available in the data layer is crucial. What options do you have in this case?

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

#4. Not using the preview and debug console properly

When you select an event from the left column of the Preview and Debug console, the Tags tab will show the tags present during that event categorized 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?” GTM will only trigger the tag 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, check out this guide.

#5. Not using other debugging tools

GA debugger and Data Layer Inspector are among the most popular debugging tools. Both are free Google Chrome extensions that will make your life infinitely easier.

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

When it comes to e-commerce tracking, the GA debugger (together with the Analytics debugger) is irreplaceable to me. When enabled, it displays all data passed to Google Analytics 4, making troubleshooting much faster.

I have prepared a comprehensive list of Chrome extensions and tools for GTM. Take a look at this list here. I have also provided several tips for debugging here.

#6. Not checking the GA4 DebugView

I’ve seen many beginners not check their GA4 DebugView once they have implemented Google Analytics 4 tracking via GTM. There is a false perception that you have completed your task once the GA4 tag has fired (according to the Preview and Debug console).

However, that is very far from the truth because, in some cases, users might accidentally send data to the wrong Google Analytics 4 property (or maybe some other technical problem occurs). It is essential to confirm that you can see that data in DebugView, too.

When testing a new event, go to GA4 > Admin > Data display > DebugView. Here, you can see all the events that GA4 receives. Click on an event to see its parameters and user properties.

Lastly, there are other tools you can implement (e.g. Facebook Pixel) which offer real-time debugging features. Always use them if they are available. Better to be safe than sorry!

#7. Not removing hardcoded tracking codes

If you have decided to migrate from hardcoded Google Analytics 4 (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 the GTM container snippet to the website, publish the Google tag (or some other tool’s tag) in GTM and remove any hardcoded tracking codes from the website.

But if you’re considering migrating a more extensive website with more complex tracking, many things can go wrong. My Google Tag Manager for beginners course explores topics related to the migration process in greater depth.

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, so be vigilant when auditing your migration process.

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

Not to be dramatic, but when various people have access to the same Google Tag Manager container, chaos will inevitably ensue. Imagine a contractor from an agency adds some marketing, then a colleague from another department adds tags for a new feature, and so on.

Like two ships passing in the night, there may be a lack of coordination among all parties with access to the container; people either don’t know or don’t care about what others are doing in GTM.

The result is a bloated container full of tags that could conflict with one another. Or even better, maybe some of those tags haven’t been used for a year (or years), but they are still in the container (thus affecting the page speed). Remember, every additional tag affects the page speed (the impact might be trivial, but it’s still there).

How do you avoid this situation? I recommend auditing the container at least once every 6-12 months. Collaborate with your colleagues and contractors to review all the tags in the container to confirm if they are still active.

I have seen way too many situations where GTM still contains a tag of a tool that the company hasn’t even used in the last two years. Be sure to remove everything that your business is no longer using.

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 provide approval. And if the request is illogical or harmful, it should be rejected.

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

The data layer plays a pivotal role in ensuring a successful implementation of Google Tag Manager, serving as an array containing all the information you want to pass to Google Tag Manager. The data layer object initialized by the Google tag or Tag Manager is called the dataLayer.

Here are a few examples of what data can pass to the dataLayer:

• User’s pricing plan
• User’s registration country

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 4. However, there’s a catch – if developers make this one mistake, your entire GTM event tracking will break.

If a developer adds custom information to the data layer like this:

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 simpler words – things will go wrong.

So, the developer must place the dataLayer snippet (as shown below) 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 -->

While talking about mistakes, you’ll find that following best practices will limit mistakes made. In this case, an even better option is to ask your developer to use the dataLayer is an even better option.push method instead (see the example below).

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

This is an excellent example of why we don’t want to make mistake #12.

Are you a little tired? If so, bookmark this blog post about common Google Tag Manager mistakes and return later. If not, let’s keep it rolling!

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

When you started using Google Tag Manager, you probably saw something about how Google Tag Manager supposedly “optimizes page load time”.

The reality is — it depends. I have done a bunch of tests and saw some improvements when comparing hardcoded tracking snippets (added directly to the website) vs. GA4 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, GA4, Reddit Pixel, Quora Pixel, or LinkedIn insight tag, your page load time will increase by A LOT.

It’s good practice to check your page speed after you add a new tag. Actually, you should run several tests before adding new tracking and then compare page load times to what happens after you publish your changes.

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

#11. Typos

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

• Trigger conditions: If you’re using regular expressions in your conditions, double-check whether you need standard regex or the “(ignore case)” option.
  
• Names of variables and triggers: This usually happens with data layer events, where the custom event trigger and the variables need to match exactly what the developer has inputted into the codebase. For example, you could ask your developer to add an event into the data layer to track clicks on menu items on your site.
  

Now, when you create your custom event trigger and data layer variable, you need to ensure that you enter the name exactly as it’s shown above.

Also, keep in mind that all of the fields in GTM are case-sensitive. This means that “Menu_Item” is different from “menu_item”.

#12. Not cooperating with developers

Many marketers and digital analysts have started using Google Tag Manager (probably) because they believe in 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 the flexibility and agility of marketing teams, developers will likely still be needed, especially when dealing with more complex setups or projects.

The Google Analytics 4 ecommerce implementation is a good example. If you’re working on a custom e-commerce platform, you must work with developers and ask them to push event 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.

Additionally, ask a developer to quickly review any custom JavaScript code you find online and plan to implement it via a Custom HTML tag. Way too many times, I’ve seen cases where marketing teams add some unknown script and temporarily break 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.

Fostering a strong relationship between marketing/analytics teams and developers is crucial for the best, most robust tracking. By building these relationships, you can enhance your tracking capabilities and, who knows, maybe even make a new friend along the way!

#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 (or RegEx). Instead of having, say, multiple “contains” conditions, you can match different data with just one RegEx pattern.

If you want multiple conditions connected with “OR”, you’ll have to 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 to utilize regex in GTM, so you should check it out. Also, I constantly use the Regex 101 validator to verify my regular expressions.

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 them all at once, I call this the “big bang” deployment.

Unlike the scientific theory that explains the universe’s origins, this is not a good thing (in my opinion).

If something goes wrong with your newly published container version, you must revert the entire version (including things that were working). Sometimes, you may not even be able to tell what’s causing issues, so you must start from the beginning again.

A good rule to follow is one feature, one version. So, as you implement small portions of your total work, publish each feature as a new container version once you have confirmed that it is working correctly using Preview and Debug mode.

In this case, if something goes wrong with your latest version, the previous smaller batches that you published will still be live and will work fine.

To go along with this, check out mistake #20.

#15. Tracking forms with Click Trigger

This mistake is widespread among beginners who need help using the 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 (let us know if you have any tricks up your sleeve for this in the comments).

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 Submit button clicks, not just the successful submissions.

If a visitor tries to submit a form on your site but accidentally leaves a required field empty, the click trigger will cause the event to fire successfully, saying that the form was submitted. As a result, you’ll have an inaccurate, overinflated event count for submissions/conversions.

The solution? There are a bunch of other techniques for tracking forms with Google Tag Manager. If you find yourself in this scenario, give one of them a try!

#16. Not having proper naming conventions in place

Working in a GTM container with many tags/triggers/variables but no decent naming convention is 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 don’t have many tags, even the most terrible naming of your GTM assets won’t cause a ton of problems, but when you start to deal with 50+ tags, poor naming conventions will come back to haunt you and waste your time.

Since none of us can see into the future (but if you can, please let us know when GA4 will bring back annotations), you never know when your GTM container will start to explode with tags. So, build good habits early on and use proper naming conventions from day 1.

I have published a guide on GTM and GA4 conventions that you might find helpful.

#17. Not adding the event settings variable to tags

The Event Settings variable provides the ability to define extra parameters accompanying every event it’s added to. This saves time updating multiple event tags each time you need to add a new parameter.

However, just because you have set up the Event Settings variable doesn’t mean that this will automatically apply to every event. You need to ensure that you go through every tag in your container and add the variable to each tag.

Another mistake would be to not set up an Event Settings variable, so check out this article to find out why and how.

#18. Not labeling your container versions

Even if you ensure that you aren’t making mistake #14 (publishing all changes at once), this is no help when you want to go back and look at different versions and need to click through each version to see what was updated.

To mitigate this issue, label your container versions (following these naming conventions) so that it’s easier to find what updates were made in case any issues arise later on.

#19. Putting event parameters as user properties and user properties as event parameters

If you’re new to Google Tag Manager, then you may find it hard to determine the distinction between what should be an event parameter and a user property in the Event Settings variable (or just in a tag if you’re doing it individually).

Event parameters provide additional information about actions that visitors take on your site. However, user properties are attributes that describe groups of your user base, such as their language preferences or the pricing plan they subscribe to. You can use user properties to define audiences.

If you have a share event, then the group that the shared content falls into is an event parameter (content_group), and the information on the pricing plan the visitor is on (pricing_plan) is a user property.

#20. Failing to plan

Not thinking through your ultimate tracking goals can cause many issues within your GTM container.

Firstly, over-tagging can slow down your website and clutter your GTM containers. Not planning what you want to track can lead to unnecessary or incorrectly configured tags.

Similarly, if you fail to plan, then you may ignore the automatically tracked events and built-in variables. Not leveraging these variables can lead to unnecessary custom events and custom variable creation.

Lastly, as part of your planning process, you want to ensure that you have documentation of tags, triggers and variables. When you have multiple people making tags, or even if it’s only you, things can get very confusing very quickly if you fail to have proper documentation.

Here is an example of a spreadsheet with events you could update for your needs. You can use it as an example/inspiration to create your own spreadsheet.

#21. Overlooking the importance of a container backup

There is a feature that allows you to export a JSON file of your container, which is a great practice to get into since you never know what can happen to your container, especially if you have multiple people with access to it

If anything were to happen to your container, you can import the JSON file you exported from your lost container into a new container, so you don’t need to worry about having to recreate everything.

Now, you may be thinking, “Aren’t container versions our backups?” Yes, but not in the case of a container being deleted altogether.

Sometimes things happen – rogue agency takes your GTM container as a hostage, or an employee leaves the company, their email is deleted, and nobody at the company knows how to get access to the container.

To export your container, go to Admin > Export Container.

Click the container version that you want to export (likely just your Default Workspace, assuming it’s up to date with all changes you’ve made) and then “Export”.

So, take the path that has been less traveled and export your container. Your future self may be really grateful for it.

Most common Google Tag Manager mistakes: Final Words

In short, we all make mistakes; we’re human, after all! If I had a penny for each mistake I’ve made… well, let’s just say, I’d likely be a millionaire by now!

All jokes aside, mistakes are powerful teachers, so I want to share this list with as many people as possible. I hope you can steer clear of these mistakes, but in case you don’t (and that’s ok!), this list is here to help you work things out.

If you think I missed something, let me know in the comments. Remember, it’s much cheaper to learn from the mistakes of others, so let’s help each other out!