No products in the cart!
Please make your choice.View all catalog
Updated on May 10th, 2021
Google Tag Manager (GTM) is a powerful tool that lets you add and edit tracking codes (tags) without much intervention from the IT department. It is much more convenient to control all your tags in one dashboard rather than having them scattered across your website’s source code.
But creating and managing tags, triggers, and variables within the GTM still require certain skills. If you are not sure about how to best use the GTM, you may end up with a real mess in your account or in the worst case, may end up breaking the website functionality and causing significant financial loss to your client/company.
To show you the right direction, here are a bunch of Google Tag Manager best practices that you should start following immediately.
Obviously, this is not a definitive list (or whatever) and it never will be. But I just hope maybe some of the list items will give you ideas/inspiration for your next task/project with GTM.
+ Show table of contents +
When you start working on a new project, don’t rush to blindly implement various tracking techniques. Instead, prepare a measurement plan and a tag implementation plan.
First, start with identifying the business objectives. What are the main goals of the business? If you are working on tracking the website, try to identify which of those business objectives will a website help achieve?
For example, one of the main business objectives will be to (obviously) increase the revenue. If the website is an e-commerce site, then obviously, the main thing that should be tracked is purchases.
Then identify what kind of smaller events/interactions lead your users/visitors towards that main goal (purchase). It can be “add to cart”, “start checkout”, “subscribe to newsletter”, etc.
When you prepare the list of events, your measurement plan will start to materialize. And that’s where you can start preparing a list of tags that you are going to implement in Google Tag Manager. Prepare a spreadsheet of all tags and their settings that you are going to implement.
By having this kind of spreadsheet, you will start seeing what you are going to need from your developers, what will be the names of the events, etc. This will help you also create a solid naming convention (more on that, a bit later).
I have ~1 hour of content on planning and preparing the measurement/tag implementation plans in my GTM course for beginners.
Google recommends using only one account per company and one container tag per website. Yet I still sometimes see installations where several GTM accounts have been created just for one company or several container tags just for one website. Multiple GTM accounts/containers can cause tracking and diagnosing issues sooner or later.
Moreover managing tags, triggers, and variables spread across several accounts/containers can become a nightmare as your account grows. Use only one GTM account per company and one container tag per website.
Of course, there might be some exceptions, e.g. two websites (due to their significant similarity) may use the same GTM container code. But in this case, you will have to be very careful when setting up triggers only on one website.
As for containers, you might be wondering how many containers do you need? The answer is “it depends” and this article explains everything you need to know.
Another important thing: it is a bad practice for digital agencies to create GTM containers for their clients under a single agency GTM account. The client should ALWAYS own the container. The agency should either ask the client to create the account & container, or the agency creates a separate account + container and gives admin permissions to the client. I have seen some nasty cases where agencies just block the client from the GTM container when the client wants to end the relationship.
I just can’t emphasize enough how important to me this Google Tag Manager best practice is.
If you’ve used GTM for real, then you may have found that the number of tags, triggers, and variables can grow very quickly into a hard to manage mess. Therefore, you should use clear naming guidelines which will help you to manage your GTM implementation far easier. Easier for you and your teammates. Easier = less risk, less time, and less money wasted on tagging. Otherwise, this will happen:
Best tips for naming tags, triggers, and variables:
Google tag manager is a very powerful tool and if used irresponsibly or without proper thought, planning, and testing, can break your website functionality. So you should limit access to this tool to only those who are actually involved in tag deployment.
GTM allows you to delegate access to other users at the Account and Container level. Users can be granted the ability to view or administer other users at the Account level and can be granted read, edit, approve, or publish rights at the Container level.
To add or modify users, click Admin in Tag Manager menu bar, choose an account or container you need and then click “User Management”. Create a new user or edit an existing. There are 4 possible permissions levels each user can have access to:
Tip – give “Publish” permission only to those team members who know GTM the best in your team.
This Google Tag Manager best practice is especially useful for larger teams. In GTM, workspaces enable you to create multiple and differing sets of changes to your container. Different users and teams can work on these sets of changes in separate workspaces at the same time to independently develop and test tag configurations.
With Workspaces, you’ll be working with multiple Container Drafts. In essence, when a Workspace is created, a new Container Draft is separated from the latest GTM container version, and this becomes your new Workspace.
Each container has one stream of versions. When a new version is created, each workspace will display a notification that the workspace is out of date, with a prompt to update the workspace.
When another Workspace is turned into a Version, all other Workspaces will get a notification that the Latest Container Version has changed. Any changes implemented in this new Container Version need to be synchronized with all other Workspaces before those can be turned into new Versions.
You don’t have to do it immediately, but you will see the notification in the Container Overview reminding you that you need to update the current Workspace with changes in the Latest Container Version.
The workspace must be updated before creating a version and publishing from it. If there any conflicts between the changes synced to your workspace while updating and any of the changes already in your workspace, you will see a “Conflict found” indication on the Workspace Overview page. Selecting to resolve the conflicts will bring you into a conflict resolution tool.
I will not get into details of conflict resolution. You can learn more about it in Simo’s blog post.
This tip applies to Universal Analytics (GA3). If you use Google Tag Manager and Google Analytics, you already know that every new analytics tag you create requires Google Analytics property ID (a.k.a. Tracking ID), e.g. UA-XXXX123, and other settings. If you are creating multiple tags, this can be a pain and can also lead to possible typos/errors that will cause your tags to fail later on since you won’t be sending data to the right GA accounts.
And what will you do if one day you need to switch your Google Analytics account and start sending data to the new one? Well, you’ll need to manually change the Tracking ID in each GA tag. And that sucks…
Did you know that Google Tag Manager can remember your Google Analytics Tracking ID (and other settings) for you? Doing this saves time, energy, and value. To do so, you’ll need to create a Google Analytics Settings Variable and reuse it in multiple Google Analytics tags.
GA settings variable in Universal Analytics is a real timesaver. However, most of the other tags (if not all) in GTM don’t support this type of configuration. This means that you will still need to individually configure things like tracking IDs, some other settings.
For example, if you are using facebookincubator’s Facebook Pixel tag template in GTM, you will need to enter the same tracking ID in every FB pixel tag. Imagine what would happen if you have 30 FB pixel tags and one day you have to change the Pixel ID from X to Y.
You would need to go through every FB pixel tag and manually replace that. Not very optimal and there is some space for human errors.
Luckily, you can use a thing called Constant Variables in GTM. Go to Variables > New > Constant.
Here you will see only one field. Let’s continue with our Facebook Pixel ID example. Here I could paste my Pixel’s ID and save the variable.
Now, I can use this variable in every FB Pixel tag.
And if in the future I need to change the ID, I will have to change it only once, in the constant variable. Then, all FB Pixel tags that use this variable will automatically inherit the change.
A lookup table in Google Tag Manager makes it much simpler to manage lots of values in your tracking setup. It can drastically reduce the number of tags required and turn your messy GTM into a neat environment.
A lookup table in Google Tag Manager is a variable that has the value of another variable as input. It works like this: When [input variable] equals to _______, set [this output variable] to_______.
The most popular use case from my experience: Different Google Analytics Tracking IDs – one for production (live) website, and the other one – for the development version. This way all page views from “development” website will be sent to my GA test account and will not mess my actual tracking data:
You can read this Lookup Table tutorial to learn more.
GTM also offers Regex Tables. They work as Lookup tables + every field supports regular expressions (more complex conditions, but more powerful as well).
With the ever-changing landscape of digital analytics, more and more businesses are moving towards server-side solutions that offer more control for business over what data is shared with 3rd party vendors and increase the accuracy of the data that is collected by your business.
In 2020, Google Tag Manager also joined this movement and introduced server-side tagging. You can learn more about it here.
This is not for every business (because it incurs additional monthly costs that can be too large for small businesses) but the benefits outweigh the drawbacks by a lot.
And if you want to dive deeper and implement not only GA4 but also Facebook Conversions API, enroll in my intermediate/advanced GTM course.
If you do find a possibly useful custom code on some websites, I highly recommend consulting with a developer (if possible) prior to using it.
Even if the code is provided by a well-known and respected source.
Why? Because custom codes that you implement via Custom HTML tag (or something similar) can break the website. I have seen cases where the marketing team adds some codes (without properly testing them) and temporarily breaks the site resulting in thousands of dollars of lost revenue.
As a result, that marketing team lost permission to publish the GTM container changes. With great power/flexibility, comes great responsibility. And not everyone is aware of that.
Google Tag Manager Data Layer is incredibly useful when it comes to custom data and triggers. Although it’s a pretty difficult concept to master for beginners, it is one of the key parts of tag management. So whether you like it or not, you will have to understand it.
If you want to track certain parts/features of your website and default GTM auto-event listeners do not catch any interactions, my recommendation would be utilizing Data Layer.
Just ask your developers to put the data you want into Data Layer, then Google Tag Manager will easily access it and use it in triggers, tags, or variables. Not sure how to ask developers for data in the data layer? I explain that here.
Most common examples of where the use of Data Layer is highly recommended:
I have also written a comprehensive post on what Data Layer in Google Tag Manager is and how it works.
It is not something new that in some companies, the IT department is strictly against Tag Managers. After all, they can be used to inject scripts and indeed affect the performance and security of the websites.
As a result, the IT department just declines anything related to this topic and the implementation of GTM.
However, what they usually don’t know is that Google Tag Manager offers a suite of features that allow the IT department to have a lot of control and limit what the marketing/analytics team can do. But at the same time, the marketing/analytics team can still do a lot of their usual work without compromising the security.
For example, the IT department can automatically prevent the marketers from implementing Custom HTML tags and can allow to only use Google Analytics, Google Ads, and some other tags. This can be achieved with the allowlist/blocklist.
Want to implement a server-side tagging setup? Your developers can configure policies to allow only certain actions.
And these are just some of the things that the IT department can have control of.
Yes, this introduces more limitations for the marketing/analytics people, but it’s still much better than having no GTM at all.
If possible, ask developers to add additional and useful information to your website’s source code – e.g. id or “data-id=xyz” to elements you need to identify for tracking. Let me show you an example:
I used to work at a startup, called Omnisend. We offered an email marketing solution that could be easily integrated with popular e-commerce platforms (Shopify, Bigcommerce, etc.). In the older version of our website, we displayed various logos of e-commerce vendors (we call them platforms). Some logos redirected our visitors to app stores (where they can install Omnisend).
So I was interested in which vendors are the most popular among our website visitors. I asked a developer to add data-platform attribute to each logo and then with the help of auto-event variable I could pass that data to Google Analytics.
I have written a detailed step-by-step guide on how I passed “data-platform” to GA with the help of Auto-Event Variable.
This tip is useful when you have several call-to-action buttons on the same page but in different locations. They all have the same CSS class and target URL. You want to track them separately in Google Analytics. What should you do here?
Ask a developer to add IDs to each button, for example:
// ID of the first button is "menu-button" <a class="button" id="menu-button">https://www.example.com</a> // ID of the second button is "footer-button" <a class="button" id="footer-button">https://www.example.com</a>
Then in GTM enable built-in variable “Click ID”. After a click, in Preview and Debug console’s Variables tab you’ll see that Click ID equals either “menu-button” or “footer-button” ID.
You can name ID whatever you want. Just make sure that every ID must be unique per webpage.
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.
This seems like a no-brainer, but yet sometimes we are still doing this (when the change is really minor and we’re in a hurry). There should be no excuse for this!
Regardless of what change was committed in the GTM container, it always must be tested. GTM offers a great Preview and Debug mode, there are other debugging tools out there that help you test and rapidly spot bugs. Use them!
Speaking of debugging tools, let’s move to the next tip.
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.
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 Universal Analytics 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.
Whenever a new container version is published, you are given the opportunity to name the container version and add notes. You should take advantage of this option to leave full notes for someone who may be auditing your site’s tagging or troubleshooting your changes at a later date.
Even if you don’t care about the auditor, you should care about yourself. Six months after you publish a new version of the GTM container, you won’t remember what you did or why you did it. Detailed description and version name will remember for you.
The ideal version description should contain:
The beauty of container versions in Google Tag Manager is the ability to restore the previous version in case some parts of your new implementation goes wrong. Imagine what would happen if you implement FB Pixel, GA tracking, Google Ads tracking, etc. in a single version. All of these configurations would end up in a single container version.
What if Facebook Pixel was implemented incorrectly? You have to roll back, therefore, disable Google Analytics, Google Ads, and other tags (which were in that version).
It would be much better if you first implemented Google Analytics tracking and published it. Then Google Ads, then Facebook. Then during the roll-back, you would just have to temporarily get rid of Facebook’s tags, keeping GA and G ads tags up and running.
Also, deploying large tracking functionalities at once means that the testing process will be more complex and you’ll have to check EVERYTHING at once.
If you are migrating from hard-coded Google Analytics (where all tracking codes are scattered across the entire website) to Google Analytics via GTM, you should first let them both work at the same time:
After a week or so you’ll need to check Google Analytics reports in both accounts. These numbers should be within 1-2% of each other (they will not match exactly). If data in both GA accounts appears to be out of sync, investigate your implementation, and see if you can spot where things are different.
My GTM ebook for beginners describes this with additional details.
After you’ve completed verifying the new Google Tag Manager implementation (see Tip #19), remove the old GA code. This is one of the most common issues I see with tag deployment.
If you have deployed tags via Google Tag Manager then you should remove the corresponding hard-coded tags from your website as soon as possible. Failing to do so may result in inflation of your analytics data and duplicate pageviews/events.
Join the communities if you want to be the first to hear the GTM news, solve your problems, or get new ideas.
Also, subscribe to the Analytics Mania newsletter for comprehensive GTM guides like this one.
You can call me biased here as well (and I kinda am). But I really believe in this and I apply this same principle to myself as well. I now try to always take some courses if I need to learn the topic. Yes, it can cost more money but in the end, it saves me a lot of time, hence the price is usually worth it (of course, you need to do some research about the course before taking it, read reviews, etc.).
When I started using Google Tag Manager in 2013-2014 I struggled with almost everything. There was from little to no information about how to get started and achieve something meaningful, in addition to that the user interface was clunky and difficult to understand.
But everything changed in 2015 when the Google Tag Manager V2 was introduced. A totally redefined user interface, much clearer workflow, auto-event listeners, and most importantly – a rapidly growing number of Google Tag Manager online courses and tutorials.
Here are several options you can choose from:
So there you have it – a pretty long list of Google Tag Manager best practices – from account structure to testing and deployment.
My suggestion – don’t start using them all at once. Try one by one and see which ones fit your needs the best (and give the maximum outcome).
I’d like to emphasize the importance of account structure (+ naming conventions), the data layer, and testing.
Do you have anything to add to this blog post? Are the any essential Google Tag Manager best practices I missed? I’d be happy to hear your thoughts out in the comments below.