Google Tag Manager Checklist – 73 Ways to Prepare a Website

If you’re constantly working with Google Tag Manager, you’ve probably started noticing some repetitions, each project requires checking the same set of things/settings/data over and over again: Have you double-checked whether all required Enhanced E-commerce data is in place? What about custom dimensions? The list could go on and on.

After implementing GTM on various projects, I’ve started writing down a list of things I need to check in different stages of implementation. Today, I’m sharing it with you (well, most of it). So without further ado, here’s a Google Tag Manager checklist which contains 73 things you should keep in mind before, during and after the GTM setup is launched.

In the past, I’ve used a GTM checklist prepared by Lunametrics but then I gradually started noticing that some list items never applied in my projects, while others were always missing. As a result, I’ve updated their list, by removing irrelevant items (just my opinion) and adding new ones.

All items in the GTM checklist are split into several categories:

• Planning
• Preparing the website and installation of Google Tag Manager
• Instructing your team about the Data Layer
• Preloading the Data Layer with user data
• Preloading the Data Layer with E-commerce data
• Other page information
• Tags, trigger, variables
• Google Analytics E-commerce
• Miscellaneous

Keep in mind that a lot of these items are optional and vastly depend on the complexity and structure of the project you’re working on, e.g. not all websites need an e-commerce tracking, especially the enhanced one.

Feel free to download the GTM checklist (as PDF) by entering your email address in the form.

Planning

#1. Think of the account/container structure, ownership, permissions. How many websites does the client/company have? Should they all use the same container or should they be separated? Which permissions should you assign to whom? I always try to answer these questions before I start working on GTM.

#2. Prepare tag implementation plan. Prepare a sheet with all tags you plan to publish. It will enable you to think everything through before taking actions, therefore you’ll be able to foresee possible roadblocks and avoid/solve them more easily. Julian from MeasureSchool has shared his sheet template which I’m also regularly using. Just make a copy of it and you’re good to go.

Preparing the website and installation of Google Tag Manager

#3. Add unique IDs to very important web elements. By having those IDs you will be able to track interactions much easier (Click ID and Form ID variables will become your best friends).

#4. Make forms friendlier for tracking with Google Tag Manager. There are several options you could ask your developers for:

• Forms should dispatch only valid submit events. If there are errors, the event should not be initiated.
• If the form is built with AJAX, ask a developer to return a clear response which can be used as a trigger rule. Learn more about AJAX form tracking.
• Or ask a developer to fire a dataLayer.push event when the form was successfully submitted. You can later catch it with a Custom Event Trigger. Here’s an example of the code a developer should fire:

  <script>
   window.dataLayer = window.dataLayer || [];
   window.dataLayer.push({
   'event': 'formSubmitted'
   });
  </script>

#5. Use “data-” prefix for additional information and fetch it with variables in Google Tag Manager.

If possible, ask a developer to add additional and useful information to your website’s elements – e.g. id or  “data-id=123” to elements you need to identify for tracking. Let me show you an example:

I work at a startup, called Omnisend. We offer an email marketing platform which can 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 of them redirected visitors to app stores (where they could install Omnisend).

So I was interested which vendors were the most popular among website visitors and asked a developer to add data-platform attribute to each logo. Later, with the help of the auto-event variable, I could pass that data to Google Analytics. You can also access that attribute with the DOM Element variable.

#6. If you can’t figure out how to track an interaction by yourself, ask a developer to fire a dataLayer.push event. Actually, the “dataLayer.push first” approach is recommended because it’s more robust than, for example, DOM scraping.

#7. Single-page websites should use URL Fragments (the part of the web address which comes after a hash mark #). That way you’ll be able to track different sections of the page and fire virtual pageviews (with help of History Change Trigger and its variables).

#8. If URL fragments are not an option, a developer should push an event to the dataLayer every time a visitor/user navigates from one page to another.

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
 'event': 'virtualPageView',
 'pageTitle': 'This is a page title',
 'pagePath': '/this-is-some-page-path/'
 });
</script>

This technique is explained in this blog post.

#9. One part of GTM container snippet should be placed in <head> and the second part right after the opening of the <body> tag. If that’s not possible, place both codes as high as possible in the website’s <body>. Never ever place the <noscript> part of GTM code in website’s <head>. Learn more about how to properly install the Google Tag Manager.

#10. Check if Google Tag Manager code is added to all pages. For this task, you should use a web crawler, for example, Screaming Frog, a solution which can be configured to crawl the entire website and look for https://www.googletagmanager.com/gtm.js in the website’s source code. This URL is used by the Google Tag Manager container. If it’s somewhere missing, the frog will report it.

#11. Use Tag Assistant to check if GTM is added successfully. Also, try enabling Preview and Debug mode: if it appears, that’s a good sign.

Instructing your team about the Data Layer

If you want to access custom data and then pass it to Google Analytics or other tracking tools, you should ask a developer to preload the dataLayer with that information. First, make sure that developers know what they’re doing.

#12. If needed, introduce the concept of the Data Layer to developers. Here are several resources you could start from:

• What is Data Layer?
• How to access data in the Data Layer?
• Data Layer variable in Google Tag Manager (this one is just for the context. Let developers know what you will do with the data they push to the dataLayer).
• All tips from #13 to #28 of Simo Ahava’s 100 Google Tag Manager Learnings.

#13. If some custom data is needed on ‘Pageview’ event, the Data Layer snippet must be above Google Tag Manager’s container <script>. Why? Because only then GTM will be able to access that custom data on the Pageview event and send it to 3rd party tools of your choice. Also, if you use the following syntax to define the Data Layer…

<script>
 dataLayer = [{
 ....
 }];
</script>

…the only way NOT to break the Data Layer is to place the code above GTM container snippet. If such code is placed below the container, your GTM event tracking will break.

#14. It’s recommended to prefix the dataLayer with window. As a result, all snippets should use window.dataLayer. According to Simo, this will help you avoid conflicts with any locally scoped structures that use the same name. P.S. yes, I know that my older blog posts still don’t use window. I just did not have the motivation to fix it, hoping to update them soon *sigh*

#15. It’s better to use push (window.dataLayer.push), even when the page loads. According to Google’s documentation, it’s sufficient to place this dataLayer snippet above the Google Tag Manager container script (keys and values are just an example):

<script>
 dataLayer = [{
 'pageCategory': 'signup',
 'visitorType': 'high-value'
 }];
</script>

But after reading multiple sources (including Simo Ahava’s blog), the recommended approach should be different. Never use the syntax which I’ve posted above. If this command is executed after the GTM container snippet or after you’ve already established a dataLayer object, you will end up overwriting the existing object with this newly initialized structure. This might end up breaking GTM.

The solution? use dataLayer.push, instead. The code snippet should look like this:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
 'pageCategory': 'signup',
 'visitorType': 'high-value'
 });
</script>

P.S. yes, I know that my older blog posts still use dataLayer = [{}]. I just did not have the motivation to fix it, hoping to update them soon.

If you want to download a PDF version of this checklist, enter your email address in the form below.

Preloading the Data Layer with user data

Now, that your team is introduced to what the Data Layer is and how to work with it, let’s preload it with some valuable data.

#16. Is user logged in? You can create certain triggers based on it, e.g. display a popup for users who aren’t logged in. This is also a valuable custom dimension in Google Analytics.

#17. Pricing plan/membership status. Is the user using Free or Premium plan?

#18. User ID. Read more about it here.

#19. IP address. This is really useful for those who want to filter out the internal traffic and block tags from firing.

#20. Satisfaction/Net Promoter Score. If you’re collecting data regarding customers’ satisfaction score or NPS, this could be used as a custom dimension in Google Analytics. See how both satisfied and unhappy users are using your website or web app. You definitely find what to improve!

#21. Demographic information, including age, gender, etc.

#22. A number of payments/purchases. 

#23. A number of sessions.

#24. Total spend. How much did this customer spend on your products/services?

#25. User preferences. Use of favorites, wishlist, or other options you may offer that allow visitors to personalize their view of your site.

Preloading the Data Layer with e-commerce data

Here’s the data that’s crucial for businesses who want to implement Google Analytics Standard or Enhanced E-commerce tracking. Also, this data might be useful for other tracking tools.

#26. Transaction ID.

#27. Transaction subtotal.

#28. Transaction Total.

#29. Store or affiliation from which this transaction occurred (e.g. Google Store).

#30. Currency code.

#31. Product ID (or SKU).

#32. Product price.

#33. Product quantity.

#34. Tax and shipping.

#35. Product name.

#36. Product category. The category to which the product belongs (e.g. Apparel). Use / as a delimiter to specify up to 5-levels of hierarchy (e.g. Apparel/Men/T-Shirts).

#37. Product brand.

#38. Product variant, e.g. black.

#39. Product position in a list or collection, e.g. 2.

#40. Coupon code associated with a product, e.g. BLACK_FRIDAY30.

#41. Promotion ID, e.g. BFCM_1234.

#42. Promotion name, e.g. Black Friday Sale.

#43. Promotion creative, e.g. black_friday_banner2.

#44. Promotion position. The position of the creative, e.g. banner_slot_1.

Other page information

#45. The number of reviews and the final score (the data related to the Product Page).

#46.The number of words in a blog post/article. This way you can see how the length of the post correlates with user behavior. You can also ask a developer to push ranges of article length. For example, short posts could be assigned to the range, called 0-500 words, while others could be 501-1000, 1001-1500 words, etc.

#47. Blog post/article author.

#48. Publication date.

#49. The number of comments. 

#50. The number of upvotes, downvotes, the final score.

#51. Article/blog post category, tags.

Tags, Triggers, Variables

I hope to add more items to this section because right now there are only two of them, one related to triggers and the other one to variables.

#52. Use Google Analytics Settings Variable. I can’t believe I have to add this item to the list but I still sometimes see others launching new projects without this variable.

#53. Use Regular Expressions in triggers instead of creating multiple triggers and add them to one tag.

Google Analytics e-commerce tracking

After a developer has preloaded the Data Layer with e-commerce data, you need to create Universal Analytics tags which would automatically fetch the data and send it to Google Analytics.

#54. Standard E-commerce Tracking – create a Universal Analytics tag (type: Transaction) which fetches the data from the Data Layer. Learn more about it in Google’s documentation.

#55. Enhanced E-commerce – Send Product Impression data with a Universal Analytics Tag (if applicable).

#56. Enhanced E-commerce – Send Product Click with a Universal Analytics Tag (if applicable).

#57. Enhanced E-commerce – Send Product Detail Impression with a Universal Analytics Tag (if applicable).

#58. Enhanced E-commerce – Send Add / Remove from the cart with a Universal Analytics Tag (if applicable).

#59. Enhanced E-commerce – Send Promotion Impressions with a Universal Analytics Tag (if applicable).

#60. Enhanced E-commerce – Send Promotion Clicks with a Universal Analytics Tag (if applicable).

#61. Enhanced E-commerce – Send Checkout data with a Universal Analytics Tag (if applicable).

#62. Enhanced E-commerce – Send Purchases with a Universal Analytics Tag (if applicable).

#63. Triple-check whether all Enhanced E-commerce data is syntactically flawless. Learn more about it.

#64. Prevent duplicate E-commerce transactions. Read more about it here.

Privacy-related items

#65. Implement the GDPR-compliant tracking consent mechanism. Read more about it here.

#66. Set the anonymizeIp field in your Google Analytics tags.

#67. Configure allowAdFeatures in order to activate Display Advertising features only if the visitor gave consent to have this Personally Identifiable Information be processed for marketing purposes.

Miscellaneous

#68. Check if Cross-Domain Tracking in Google Analytics is set up correctly: Enable Linker, set Auto Link domains, update Referral Exclusion List in Google Analytics Property. Read more about it here.

#69. Move <noscript> parts away from custom HTML tags and use Custom Image tags, instead. The only tag that works when JS is disabled in a web browser is a Custom Image tag.

#70. Found some tracking scripts online and used them in GTM? Show those scripts to developers, first. There’s always a possibility that a little script will break your website or put it at risk. Showing a script to a programmer will take less than 5 minutes and might save your ass.

=71. Use transport: beacon to improve your tracking quality (this is needed to send the data right before the redirect/closing the browser tab).

#72. Do the final test and say one last prayer before the deployment. I’m not a religious person but any measure can help now 🙂  Working with Enhanced E-commerce or iFrames? Say two prayers, then.

#73. After the deployment. Are there any JavaScript errors on the console? Use TrackJS or any other tool of your choice to check.

Google Tag Manager Checklist: Final Words

I hope you found at least some parts of this Google Tag Manager checklist useful. Make sure you bookmark the page for future use.

Did I miss anything else regarding the list? If yes, let me know in the comments as well.

Feel free to download the GTM checklist (as PDF) by entering your email address in the form below.