Google Tag Manager Checklist – 75 Steps to Prepare a Website

Updated: August 21st, 2025

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 GA4 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 that contains 75 things you should keep in mind before, during, and after the GTM setup is launched.

Keep in mind that this checklist is not as comprehensive as the one I offer in my intermediate/advanced Google Tag Manager course (which is getting close to 200 items), but it’s still a good starting point for those who want to improve their setup.

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

• Planning
• Preparing the website and installing 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
• Server-side tagging
• 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, and 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 action, 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 installing 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 that 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 used to work at a startup called Omnisend. We offer an email marketing platform that 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 in which vendors were the most popular among website visitors and asked a developer to add a 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 the 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 the 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 the GTM code in the website’s <head>. Learn more about how to properly install the Google Tag Manager.

#10. Check if the Google Tag Manager code is added to all pages. For this task, you should use a web crawler, for example, Screaming Frog, a solution that 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 the Preview and Debug mode to verify your setup.

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 highly recommended to prefix the dataLayer with window. As a result, all snippets should use window.dataLayer. This will help you avoid conflicts with any locally scoped variables that use the same name.

#15. It’s better to use push (window.dataLayer.push), even when the page loads. You might find older resources saying that 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>

However, the recommended approach should be different. Never use the syntax that 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>

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 the 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 that 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. Tax

#28. Transaction Total (value).

#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. 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/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. You can learn more about promotion tracking here.

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

#43. Creative name, e.g., black_friday_banner2.

#44. Creative slot. The position of the creative, e.g,. header_banner.

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.  You can learn more here.

#48. Publication date.

#49. The number of comments. 

#50. The number of upvotes, downvotes, or 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. You can learn more about this variable here.

#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 GA4 event tags that will automatically fetch the data and send it to Google Analytics.

#54. purchase event. Learn more about it in Google’s documentation.

#55. view_item_list event.

#56. select_item event (if applicable).

#57. view_item event (if applicable).

#58. Send add_to_cart event (if applicable).

#59. Send view_promotion event (if applicable).

#60. select_promotion event (if applicable).

#61. begin_checkout, add_shipping_info, add_payment_info events (if applicable).

#62. add_to_wishlist is optional (in my opinion). I personally don’t track it because GA4 interface does not offer built-in metrics for that.

#63. Triple-check whether all ecommerce events strictly follow Google’s documentation/syntax. Learn more about it.

Privacy-related items

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

#65. Implement consent mode.

Server-side tagging

#66. Map a custom subdomain (e.g., abc.yourdomain.com). Ideally, use the same-origin setup (yourdomain.com/abc). Try avoiding words obviously related to analytics or tracking in your domain (e.g., “analytics“, “sgtm“, etc.). Less obvious options are better (e.g., at.yourdomain.com).

#67. Your custom subdomain must not be used by anything else. It should be dedicated only to your server-side GTM setup.

#68. Update Google Analytics tags to send data to your custom subdomain (e.g., with server_container_url parameter)

#69. Proxy your Google Tag Manager (gtm.js) and Google Tag (gtag.js) libraries through your own custom domain. Instead of loading it from googletagmanager.com, load it from abc.yourdomain.com/dsaoabsdu.js (or something like that).

#70. Use a custom loader that modifies the request URLs (including parameters). Some browser extensions look not just at the domain of the request but also at the URL parameters (also known as query parameters). So, instead of using yourdomain.com/xyz/?collect=v2&tid=G-1234567890…, your URLs should look like this: yourdomain.com/xyz/kbsd9ab3d8bja3d8b3d...

#71. Event deduplication. If you are sending events to platforms like Facebook Conversions API or TikTok Events API (and you’re using both client-side pixels and server-side tagging to send the same events), then implement event IDs. It means that the event from the FB pixel and the event sent via SGTM must have the same IDs. Then the ad platform will be able to deduplicate it.

Miscellaneous

#72. 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. Or, technically, you can skip the noscript part altogether. It’s not very useful these days.

#73. 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.

#74. 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.

#75. After the deployment. Are there any JavaScript errors in the console? Use TrackJS or any similar tool to check.

Google Tag Manager Checklist: Final Words

This checklist should give you a good head start working with Google Tag Manager. Follow it, and your setup will easily be among the top 20% of setups worldwide (of course, I don’t have any official statistics to back this claim, but I have dealt with numerous setups and websites, and they were in poor condition before I started fixing them).

However, if you are looking for a much more comprehensive list (with links to resources, etc.), then take a look at my intermediate/advanced Google Tag Manager course. It contains a checklist with more than 160 items.

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