November 29, 2018
Google Tag Manager Best Practices: 24 Actionable Tips
Updated on November 29th, 2018. Google Tag Manager (GTM) is a powerful tool which lets you add and edit tracking codes (tags) without much intervention from the IT department. It is much more convenient controlling 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. Here are 24 Google Tag Manager Best Practices that you should start following immediately.
Before we continue, I’d like to ask you a favor – please read this guide carefully. If you see that some Google Tag Manager best practices are missing, please let me know in the comments. The objective of this guide is to become an ultimate resource for beginners who are just starting to understand how tag management works.
Do we have a deal? Alright! First, let’s start with the shortlist of Google Tag Manager best practices and then we’ll proceed with each tip individually.
Google Tag Manager Best Practices: Chapters
- Account structure
- Variables, auto-event listeners
- A developer is not your enemy
- #10. Utilize Data Layer.
- #11. Ask a developer to add a visitor’s IP address to Data Layer.
- #12. Ask a developer to add “data-” prefix to important website elements.
- #13. Ask a developer to add IDs to important website elements.
- Optimization is a priority
- Migration from hardcoded solutions
- Stay hungry, stay foolish
- Google Tag Manager Best Practices: Conclusion
Google Tag Manager Account structure
#1. Structure your GTM account properly
Google recommends using only one account per company and one container tag per website. Yet I see many 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 could turn out to be a nightmare as your account grows. Use only one GTM account per company and only one container tag per website.
Of course, there might be some exceptions, e.g. two websites (due to their major 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.
#2. Use 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 the 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:
- Include track type if you are creating Google Analytics Tags. For example, you can have Pageview, Event, or Social in the tag name. For AdWords 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:
- GA Pageview – Contact Form.
- AW Remarketing – Thank You page.
- For more naming convention tips read the following resources:
#3. Use Folders
Remember that you can group your Tags under separate Folders to be able to sort them easily and understand where they belong to at a glance.
For example, you can have separate folders for vendor departments (Marketing, UX, etc.), or you can create folders for different sites if the Container contains Tags for multiple domains. Unfortunately, a Tag/Trigger/Variable can only be in one folder at a time. You can use the drop-down menu in each Tag/Trigger/Variable to save it under a folder.
#4. Give GTM control only to the right people
Google tag manager is a very powerful tool and if used irresponsibility or without proper thought, planning, and testing, can break your website functionality. So you should limit the 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 rights to create workspaces and make edits but not create versions or publish.
- Approve: The user has 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.
Variables, Auto-Event Listeners
#6. Use Constant Variables
If you use Google Tag Manager and Google Analytics, you already know that with every new analytics tag you create requires Google Analytics property ID (a.k.a. Tracking ID), e.g. UA-XXXX123. 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 Google Analytics account and start sending data to the new one? Well, you’ll need to manually change Tracking ID in each GA tag. And that sucks…
Did you know that Google Tag Manager can remember your Google Analytics Tracking ID for you? Doing this saves time, energy and value. To do so, you’ll need to create a constant string user-defined variable for your Property ID.
Constant variable means that its value will always remain the same and can be reused unlimited times in other tags and triggers.
Follow this tutorial by Google to create user-defined constant variables (including GA Tracking code, a.k.a. gaProperty).
#7. Use Lookup 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://www.analyticsmania.com, set Lookup Table’s value to UA-22222222.
You can watch this Lookup Table video tutorial by Measureschool to learn more.
Hungry for more Google Tag Manage best practices? If yes, then continue reading. If you feel tired, bookmark this guide and come back later.
#8. Search for ready-made custom auto-event listeners
But the list of auto-event listeners does not end here – there are plenty of custom listeners online that you can make use of, e.g. this Extended Library of GTM Recipes.
So if you want to track a specific element/action on your website, check whether a ready-made auto-event listener is publicly available.
P.S. If you actually find one, don’t rush with installing it in your Google Tag Manager container. Read the next best practice first and find out why.
Developer Is Not Your Enemy
You have a full right not to trust me or my devs (teammates on Soundest). Be always suspicious and cautious. Using low-quality codes might even break your website.
#10. Utilize Data Layer
Google Tag Manager Data Layer is incredibly helpful 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.
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 5 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.
#11. Ask a Developer to Add Visitor’s IP Address to Data Layer
If you’re following Google Analytics best practices, you are already filtering out your company’s internal traffic. But this affects only Google Analytics reports.
What about Facebook Pixel? Or Adwords Remarketing? It would be awesome to exclude your own visits from those systems too, wouldn’t it?
There’s actually a pretty simple way to solve this:
- Ask a developer to add visitor’s IP address to Data Layer.
- Create Data Layer Variable in Google Tag Manager.
- Update this IP exception to all your tags and triggers – they mustn’t fire when visitors IP address is equal to *your office’s IP address*.
#12. 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 work at a startup, called Soundest. We offer an email marketing solution which can be easily integrated with popular e-commerce platforms (Shopify, Bigcommerce, etc.). In our website, we display various logos of e-commerce vendors (we call them platforms). Some logos redirect our visitors to app stores (where they can install Soundest).
So I was interested 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.
#13. 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 to 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.
Optimization is a priority
#14. Always think twice before adding tags or auto-event listeners
If you’re an avid fan of Google Tag Manager (like myself), you’ve probably already tried all recipes created by Lunametrics, 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 which I realized later was that I utilized only ~10% of the collected data. Everything else was just an unnecessary noise 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 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 which needs to be executed. The more code and requests there are, the more time it will be needed for 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 1 second added to page load duration.
- At Soundest, we’re 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 quota.
We prefer quality over quantity here.
#15. Don’t Set Too Many Tags to Fire at Once
This limitation is a result of browsers, rather than of Tag Manager, but the consideration is still important. Browsers limit the number of HTTP requests that can happen at a time. If you fire 10 different tags all on the same dataLayer event, for example, some tags will likely not fire. If you still need fire most of your tags asap, consider prioritizing your tags or using Tag Sequencing.
#16. 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 GTM container, it always must be tested. GTM offers a great Preview and Debug mode, there are other debugging tools out there (e.g. Tag Manager Assistant) which help you test and rapidly spot bugs. Use them!
#17. Use Debugging Tools
Tag Assistant helps troubleshoot installation of various Google tags including Google Analytics, Google Tag Manager, Adwords Conversion Tracking and more. You can find out more here. P.S. As of February (2017) Tag assistant still does not support the newest recommendation to place GTM container’s snippet in website’s <head>, therefore you’ll get a validation error. We all hope it will be fixed soon. In the meantime, you should ignore it.
As for GA debugger, I don’t use it too often (because previously mentioned debugging tools provide enough valuable information for me). But when it comes to Ecommerce tracking, GA debugger is irreplaceable for me. When enabled, it displays all the data that is passed to Google Analytics, thus I can troubleshoot much faster.
#18. Check 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’s 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.
Still thirsty for more Google Tag Manage best practices? If yes, then continue reading. If you feel tired, bookmark this guide and come back later.
#19. Write clear descriptions 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 GTM container, you won’t remember what you did or why you did it. Great documentation 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
#20. 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.
Migrating from Hard-coded implementation
#21. 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 send data to a Google Analytics test account (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.
Lunametrics have posted a comprehensive guide on How to Safely migrate to Google Tag Manager.
#22. Avoid Double Tagging
After you’ve completed verifying 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.
Stay Hungry, Stay foolish
#23. Follow Industry News
Join these two communities if you want to be the first to hear the GTM news, solve your problems or get new ideas.
I also highly recommend following Measureschool and Simo Ahava for thorough tutorials and how-tos. And, of course, subscribe to the Analytics Mania newsletter for comprehensive GTM guides like this one.
Pro tip: I prefer getting updates/new blog posts straight to my email inbox. Unfortunately not all GTM influencers send newsletters.
#24. Check online courses to get you up and running
When I started using Google Tag Manager in early 2013 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 Fundamentals course (with 90+ minutes of video content)
- Premium Google Tag Manager Course for Beginners (with 9 hours of video content). 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.
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. Usually, this can take very little of their time.
- And I guarantee that without proper testing most of your marketing tags will not simply work. I have made a whole bunch of mistakes and all of them were spotted while testing the Google Tag Manager implementation.
Oh, and don’t forget to stay up to date – follow the GTM community, forum, blogs (like Analytics Mania) and influencers/thought leaders.
Do you have anything to add to this blog post? Are the any Google Tag Manager best practices I missed? I’d be happy to hear your thoughts out in the comments below.