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 (although there are some nuances and the classic “it depends” plays a large role here). Anyway, 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.
Google Tag Manager best practices:
+ Show table of contents +
Plan before the implementation
Account/container structure and ownership
Use Proper Naming Conventions
Give GTM control only to the right people
Leverage Workspaces
Use GA Settings Variable
Consider using constant variables
Use Lookup/Regex Tables
If possible, use Custom Templates
Server-side tagging
Consult with developers prior to using unknown Javascript codes
Utilize Data Layer
If developers/CTO are opposing Google Tag Manager
Ask a Developer to Add “data-” Prefix to Important Website Elements
Ask a Developer to add ID’s to Important Website Elements
Keep an eye on the page speed performance
Always Test Before Publishing
Use Debugging Tools
Check real-time reports, debug views, etc.
Write clear descriptions and names of version releases
Publish/Create versions in smaller chunks
Collect Data And Verify First
Avoid Double Tagging
Follow Industry News
Check online courses to get you up and running
Final words
#1. Plan before the implementation
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.
#2. Account/container structure and ownership
Google Tag Manager is made of accounts and containers. The idea here is a bit similar to Google Analytics account structure – one account holds many containers (in GA it’s property). Each container has its own Javascript code that must be placed in a website’s source code.
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.
#3. Use Proper Naming Conventions
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:
The author of this image is unknown to me (couldn’t find it). I remember seeing it in GTM Google+ community and then recreated it from my memory.
Best tips for naming tags, triggers, and variables:
Include track type if you are creating Google Analytics Tags. For example, you can have “Event”, “Config” in the tag name. For Google Ads Tags, you can have the Tag Type, such as Conversion or Remarketing, in the name.
Include specific pages. If a tag should fire on a specific page or a set of pages (like a subdirectory), then include the page/subdirectory in the tag name. Examples:
GA4 event – generate_lead – contact form.
Google Ads Remarketing – Thank You page.
For more of naming convention tips read these tips
#4. Give GTM control only to the right people
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:
Read: The user will see the container listed and may browse the tags, triggers, and variables in the container, but will not have the ability to make any changes.
Edit: The user has the rights to create workspaces and make edits but not create versions or publish.
Approve: The user has the rights to create versions, workspaces, and make edits but not publish.
Publish: The user has full rights to create versions, workspaces, make edits, and publish.
Tip – give “Publish” permission only to those team members who know GTM the best in your team.
#5. Leverage Workspaces
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.
#6. Use GA Settings Variable
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.
#7. Consider using constant variables
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.
#8. Use Lookup/Regex Tables
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:
If Page Hostname equals to https://www.analyticsmania.com, set Lookup Table’s value to UA-11111111.
If Page Hostname equals to https://dev.analyticsmania.com, set Lookup Table’s value to UA-22222222.
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).
#9. If possible, use Custom Templates
With the rise of custom templates in Google Tag Manager and the community gallery, more and more people are building and sharing ready-made templates. They are easier to use than just editing plain JavaScript codes and they are not as harmful as Custom HTML tag or Custom JS variable.
Since many GTM users are not proficient with JavaScript, templates can be a no-brainer. Also, they are designed in a way that they can play better with the Content Security Policy (CSP) of your website.
In a nutshell, CSP is a way for website developers to limit some harmful things that JavaScript can do on a website. With Custom Templates, website developers can still keep some limitations intact while you can use Custom Templates in GTM. This is also mentioned briefly here.
#10. Server-side tagging
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.
#11. Consult with developers prior to using unknown Javascript codes
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.
#12. Utilize Data Layer
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:
Form Tracking. If GTM form triggers don’t catch your form’s submissions, ask a developer to fire dataLayer.push event with data you’re interested in. I have posted a detailed step-by-step guide on how to track form submissions with Data Layer. If you’re into form tracking with GTM, consider reading my extended guide of form tracking methods with Google Tag Manager.
Passing Ecommerce data from an online store. If you plan to track Google Analytics Ecommerce transactions with Google Tag Manager, your developers will need to push transaction data into Data Layer (e.g. product ID, price, etc.) by using that very same dataLayer.push method.
I have also written a comprehensive post on what Data Layer in Google Tag Manager is and how it works.
#13. If developers/CTO vs against Tag Managers
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.
Additional resources:
User permissions in GTM
Policies for Custom Templates
#14. Ask a Developer to Add “data-” Prefix to Important Website Elements
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.
#15. Ask a Developer to add ID’s to Important Website Elements
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.
#16. Keep an eye on the page speed performance
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.
#17. Always Test Before Publishing
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.
#18. Use 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.
#19. Check real-time reports, debug views, etc.
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.
#20. Write clear descriptions and names of version releases
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:
A meaningful name that reflects the additions and changes made to it.
Detailed notes that include:
Who requested the changes
Who published the changes
What are the new tags, triggers, and variables in this container
What changes were made to existing tags, rules, and variables
Why those changes were made
#21. Publish/Create versions in smaller chunks
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.
#22. Collect Data And Verify First
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:
Hard-coded tracking keeps working as usual.
GA via GTM sends data to another Google Analytics account/property (temporarily).
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.
#23. Avoid Double Tagging
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.
#24. Follow Industry News
Join the communities if you want to be the first to hear the GTM news, solve your problems, or get new ideas.
GTM Facebook Community (recommended, but I am biased here)
GTM community on Reddit
Official Google Tag Manager Forum
MeasureSlack
Also, subscribe to the Analytics Mania newsletter for comprehensive GTM guides like this one.
#25. Check online courses to get you up and running
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:
Free Google Tag Manager mini-course (with 90+ minutes of video content)
Premium Google Tag Manager Course for Beginners. I’ve been crafting this one for quite some time. It explains basic and intermediate topics related to GTM, e.g. form tracking, conversion and sales tracking, GDPR, etc.
Premium Intermediate Google Tag Manager course (+ advanced topics). This is the next level course after you become comfortable with GTM (and exit the beginner zone). You will learn how to unlock GTM’s potential, properly test your implementation, implement GA Ecommerce tracking, server-side tagging, etc.
Google Tag Manager Best Practices: Conclusion
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.
In the long run, it will be nearly impossible to work in a mess of randomly titled tags, triggers, and variables. That’s why you need to have a strict order in your container.
If you end up in the dead-end and cannot track a particular interaction on your website – ask the developer’s help. They can push the data via dataLayer.push.
And I guarantee that without proper testing most of your tracking setup is doomed to fail. I have made a whole bunch of mistakes and all of them were spotted while testing the Google Tag Manager implementation.
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.
The post Google Tag Manager Best Practices: 25 Tips appeared first on Analytics Mania.
Read MoreAnalytics Mania
