32 Google Tag Manager Debugging and Testing Tips

Google Tag Manager debugging is an art of its own. Checking the Preview and Debug mode to see if the tag was fired is just the tip of the iceberg. In fact, there are many more things/techniques you need to follow in order to be sure that everything is working properly (or just to find the reason that is causing some nasty bugs).

In this guide, I’ve collected a list of Google Tag Manager debugging and testing tips (and some tools) to help you better understand what and where you should check. Some of them are overlapping, therefore, in the end, it’s up to you which ones to use. Let’s start, shall we?

Before we continue

This list is definitely far from being complete, therefore, I ask for your input. If you see some very useful debugging technique missing, please let me know in the comments or contact me via other channels(e.g. social media, email, or contact form). Also, there’s still a high chance that I still don’t know or just forgot to include something, so any input from my audience is appreciated.

A LOT of debugging tips are covered in the Intermediate GTM course

To take your Google Tag Manager skills to the next level, I have created a very comprehensive Intermediate Google Tag Manager course that will solve many web tracking pain points you’re dealing with every day. Starting from properly understanding the possibilities of GTM and finishing with very in-depth debugging/testing module. Also, the course includes a very extensive module teaching you the implementation of Google Analytics Enhanced Ecommerce.

Let’s move to Google Tag Manager Debugging Tips

I’ve written down a bunch of tips/suggestions/ideas and then split them into categories:

• Debugging tips related to the GTM Preview and Debug mode
• Tips related to the built-in browser tools
• Google Tag Manager debugging tips related to browser extensions
• Other GTM debugging tips

Table of contents

Debugging tips related to the GTM Preview and Debug mode

• #1. If the orange box does not appear, GTM Preview console also won’t
• #2. If you share a link to the Preview and Debug mode, always try to enter the destination link too
• #3. To exit the shared Preview and Debug mode, you need to revisit the shared URL and click EXIT or delete the 3rd party cookie
• #4. Preview and debug mode may not always work and there are many causes for that
• #5. Preview mode can be minimized. It can also remain like that after a page reloaded.
• #6. Preview and Debug mode resets after the page refreshes
• #7. The left side of the Preview and Debug mode displays changes in the Data Layer
• #8. If you want to use a particular data (from the Data Layer) in a GTM tag, make sure that this data is available as a variable on that particular Data Layer event
• #9. Keep an eye on the Errors tab
• #10. Check what values were sent to a 3rd party tool by click on a tag
• #11. The Summary shows how many times each tag was fired
• #12. View trigger conditions by clicking on a tag
• #13. Preview and Debug mode does not show everything relating to firing conditions
• #14. Missing Pageview Event? The Data Layer is set incorrectly

Google Tag Manager debugging with built-in browser tools

• #15. Check the browser’s JavaScript console for errors
• #16. View the Data Layer by entering “dataLayer” in the console
• #17. “Tag Fired” ≠ data was properly sent to a 3rd party tool
• #18. Check if there are more website elements matching the same CSS Selector
• #19. google_tag_manager[‘GTM-XXXXXX’].dataLayer methods

Google Tag Manager debugging with browser extensions

• #20. Inject your Google Tag Manager container with extensions like Tag Manager Injector or dataLayer Inspector+
• #21. dataLayer inspector+
• #22. Block already existing GTM containers in order to inject your own. Fresh and clean.
• #23. Da Vinci Tools
• #24. GA Debugger
• #25. GA debug mode setting in GTM
• #26. Use Tag Assistant recordings to debug Google Analytics implementation
• #27. Non-standard Google Analytics implementation is not a problem
• #28. Google Tag Manager debugger
• #29. Use helpers/debugging plugins tailored to specific tools

Other GTM debugging tips

• #30. Don’t see the data in GA Real-time reports?  There are several possible reasons
• #31. Not every GA interaction is visible in the real-time reports
• #32. It is possible to test GTM implementation (web) on a mobile device

Part I: GTM debugging with the Preview and Debug mode

In this part, I’ll dive a bit deeper into the standard GTM Functionality.

#1. If the orange box does not appear, GTM Preview console also won’t

If you hit the Preview button in the top right corner of your GTM interface and the orange box (see below) did not appear, that’s a good indicator that the 3rd party cookie (from www.googletagmanager.com) was not stored in your browser.

This means that the Preview and Debug console will not appear either. There might be several reasons for that. For example, your browser’s privacy settings block 3rd party cookies or you’re using a more aggressive privacy-related browser extension that also blocks GTM’s 3rd party cookies.

A solution for that? Change 3rd party cookie settings to accept them, whitelist www.googletagmanager.com cookies, whitelist www.googletagmanager.com in your browser privacy extension, etc. Since there are many browsers and extensions, I leave this task (to find out) for you.

Also, this issue is one of the more popular reasons why GTM Preview and Debug mode is not working for you.

#2. If you share a link to the Preview and Debug mode, always try to enter the destination link too

There are two main reasons why you want to share your Preview and Debug mode:

• show someone how you implemented changes in the container (say, for the QA purposes)
• get help from someone to debug a particular issue for you.

The latter point is the reason why I included this “tip” in this list at all. If you want to get GTM help faster from someone (for example, in the GTM community on Facebook), do your best to provide as much information as you can. This also includes the URL of the page where the issue should be debugged.

I’ve had too many times when a person sends me a link to the P&D mode without actually entering the destination URL where I should check. I’m not a psychic to read your mind 🙂

So even though this tip is not directly related to YOUR debugging, it will make the job easier for the person who wants to help you and debug.

#3. To exit the shared Preview and Debug mode, you need to revisit the shared URL and click EXIT or delete the 3rd party cookie

If you clicked someone’s shared link of the Preview and Debug mode and keep seeing the debug console at the bottom of your browser screen even after the debugging job/task is already done, you have two options:

• Revisit the link of the shared P&D mode and click the Exit preview and debug mode.
  
• Or delete the 3rd party cookie that belongs to www.googletagmanager.com
  

#4. Preview and debug mode may not always work and there are many causes for that

There are many reasons why GTM Preview and Debug mode does not work on your (client’s) website. In fact, I’ve listed at least 15 reasons and solutions to them. The list contains (but is not limited to):

• Wrong container
• Heavy caching
• Content Security Policy (CSP)
• AdBlockers
• etc.

#5. Preview mode can be minimized. It can also remain like that after a page reloaded.

If GTM is taking too much of space in your screen, you can resize it by dragging its top border. If you want, feel free to minimize it by clicking a little icon in its top right corner.

If you refresh a page, the debug console will appear in your screen again (regardless of its previous state). Fortunately, this can be fixed with a Chrome Extension Da Vinci Tools. This handy plugin implements various enhancements in GA, GTM, Data Studio. One of them is “Remember minimized” feature that keeps the Preview and Debug console minimized even after the page was reloaded.

#6. Preview and Debug mode resets after the page refreshes

This happens because the P&D console displays what is happening in the dataLayer, which is wiped out after the page refreshes. So if you have some click or other interaction tracked in the debug console and want to see what kind of variables were available at that moment, you won’t be able to do that after the page refreshes… unless you apply one of the following techniques/tools:

1. Want to track a link? CTRL + Click (on Windows) or CMD + Click (on Mac) will help. These commands will open the link in a new tab while the data in the previous tab is still preserved.
2. After you do a click or submit a form, quickly hit the ESC button on your keyboard. Success is not guaranteed but still worth trying.
3. Even though the page refreshes, you can still preserve Data Layer’s information in your browser. This can be done by enabling “Preserve log” setting in the browser’s JavaScript console and then combining it with extensions like dataLayer Inspector+.
   Here’s how you can preserve log in Google Chrome:
   Once you do that, enable dataLayer Inspector+ by clicking its icon and then ticking the checkbox:
   
   After that, you’ll start seeing some magic in your browser’s JS console.
   Alternatively, you can use GTM Debugger or Data Layer Checker extensions that preserve data in the Data Layer without Preserve Log feature.
4. Enter a Custom Script in browser’s JavaScript Console and it will block the page from reloading (read the tip #2 here)
5. Automatically pausing the page upon the beforeunload event. By going to your browser’s developer tools, you can set the page to pause when it intends to reload. During the pause, you can inspect the Data Layer in the browser’s JavaScript console. This advanced technique is also explained in Simo Ahava’s guide (read the tip #3)
6. Implement this Simo Ahava’s solution to persist the data in the Data Layer across pages.

Personally, my favorites are tips #1 and #4.

#7. The left side of the Preview and Debug mode displays changes in the Data Layer

Click any interaction to inspect what happened in the Data Layer in that exact moment: what data was (un)available. Every dataLayer.push is visible in this stream. If the push has an event key, then that very exact key name will be visible in the stream. If there is no event  key, then the dataLayer.push will be displayed as a message.

#8. If you want to use a particular data (from the Data Layer) in a GTM tag, make sure that this data is available as a variable on that particular Data Layer event

Take a look at the screenshot below.

There are several interactions in the Data Layer:

• userInfo (custom dataLayer.push)
• Page view
• DOM Ready
• Window Loaded
• formSubmission (another custom dataLayer.push)

With the userInfo event, there was some user-related data pushed to the Data Layer, including pricingPlan. Now, if you want to pass the value of pricingPlan with the formSubmission event to a 3rd party tool, like Google Analytics or Facebook Pixel, you need to make sure that the value of the pricing plan is actually available in the Data Layer.

You can easily check that by:

1. choosing the formSubmission event in the Preview and Debug mode (because you want to fire a tag upon this event)
2. and going to the Variables tab.
   

If the variable contains some actual value (not an undefined, NaN, etc.) on that Data Layer event, you can definitely use the variable in a tag to send its value to a 3rd party tool. Keep in mind that custom data in the Data Layer is not by default available in the Variables tab of the Preview console.

Now, if the userInfo dataLayer.push occurs after the formSubmission dataLayer.push, the pricingPlan value will not be available and will not be sent to GA or anywhere else. And that is one of the most common mistakes among GTM beginners: not checking if the variable is actually available at the moment when a tag is fired).

If a variable is not available in the Variables tab at all, then go to the Data Layer tab and see if the needed data is there. If yes, either enable a proper built-in GTM variable or create a Data Layer Variable.

To sum up: if you want to use a particular data from the Data Layer in your tag, make sure that it is available there. If a particular key is pushed to the Data Layer only after a click, then it will definitely not be available with the Page View event (because the Page View happens sooner than the click).

#9. Keep an eye on the Errors tab

This feature is pretty new in GTM and isn’t used too often (at least from my experience). But if you notice any number in the tab (rather than 0), click it and see what is the cause. This tab displays if a GTM Tag Template failed to fire due to an error. Here’s a quick guide about it.

#10. Check what values were sent to a 3rd party tool by clicking on a tag

Choose an event in the Preview and Debug mode’s event stream and click the tag that fired on that event.

If needed, expand the table to see what configuration was of that particular tag and what data was sent to a 3rd party tool (like Google Analytics).

#11. The Summary shows how many times each tag was fired

This is useful if you planned a particular tag to fire only once but, in fact, it was triggered several times by multiple triggers.

P.S. You can prevent a tag from firing multiple times in its Advanced Settings. Choose Once per page.

#12. View trigger conditions by clicking on a tag

If you want to find out why a particular tag did or did not fire, choose an event in the Preview and Debug console’s event stream and click the tag that has fired (or not).

Scroll down to see all the linked firing and blocking triggers. Take a closer look at icons. If a trigger has a green check icon, that means that this trigger activated the tag. You can also see green and red icons next to every condition of tags. If the condition was met, the icon will be green.

This helps you identify possible reasons why one or another tag has fired (or not).

#13. Preview and Debug mode does not show everything related to firing conditions

There is a chance that such a situation has already happened to you once (or will happen in the future). A tag has fired even though conditions in your triggers were not met. Or the opposite, all conditions were met but the tag did not fire. Why do such things happen?

As for November 2018 (and many years before), not everything (related to tag firing conditions) is displayed in the Preview and Debug mode. I’m talking about Tag Sequencing and Tag Firing Options.

If you set a tag to fire before or after another tag (via Tag Sequencing), this will not be visible in the Preview console, under Firing Triggers section. You can only see it in the GTM UI by opening a particular tag and scrolling down to Triggering section.

Anyway, as a result, you might start thinking that your tags are firing even when they shouldn’t but that’s not true. It’s just that the Preview console does not display the Tag Sequencing (that’s a feature request right here).

Speaking of tags not firing even though they should, another setting that may prevent that is Tag Firing Options. You may have set a tag to fire only once per page load. This means that a tag (which has already fired) will not fire anymore even if all the conditions are met. That setting can be found under tag’s Advanced Options.

#14. Missing Pageview Event? The Data Layer is set incorrectly.

Every time a page loads, at least 3 Data Layer events are visible in the Preview and Debug mode:

• Page view (gtm.js)
• DOM Ready (gtm.dom)
• Window Loaded (gtm.load)

And it always should be like that. At least 3. However, sometimes the Data Layer is implemented incorrectly on a website which causes the Page view (gtm.js) event to break. This happens because a developer places the following Data Layer snippet below the Google Tag Manager container:

So whenever you are debugging Google Tag Manager implementation, keep an eye on whether all three Pageload-related events appear in the Preview and Debug mode.

A solution for this? At least ask a developer to place the Data Layer code above the GTM container. But even a better option is to use dataLayer.push instead of dataLayer=[]. Then the position of the snippet is not that important anymore.

I’ve published a guide explaining this issue so feel free to read more about it.

Part II: Google Tag Manager debugging with built-in browser tools

Making use of the standard browser functionality for developers.

#15. Check the browser’s JavaScript console for errors

Since I’m mainly using Google Chrome to work with Google Tag Manager, here’s how you can enable JS console there. In the top right corner of the browser, click three dots, then navigate to More tools > Developer tools.

A pane will appear at the bottom of the screen (or in the sidebar, this depends on your preferences). Switch to console, click Clear Console and refresh the page. If you notice any red errors, consult with your developer whether they are critical. The variety of errors is huge so don’t think I can give you some tips on how to act is the most standard cases.

If you notice that an error that is originating from gtm.js, then take a deeper look at it (because that something cause by Google Tag Manager).

One of the most common is this one:

It is not critical but, nonetheless, you can fix it by reading this guide.

#16. View the Data Layer by entering “dataLayer” in the console

Even if you don’t have the access to website’s Google Tag Manager container and cannot enable the Preview and Debug mode, you can still check what is happening in the Data Layer. This is very useful if you’re asked to quickly debug a particular issue but, for some reason, cannot get the access to the GTM container right away.

To do that, open your browser’s JavaScript console and enter dataLayer. What you’ll see is the list of all the information which was pushed into the Data Layer.

Click the triangle to expand the Data Layer and then click any other triangle to expand that particular dataLayer.push to see what’s happening.

However, it’s really important to understand that this dataLayer is not the same as the data that gets captured by Google Tag Manager’s data model. I know, this sounds confusing, but if you want to go advaced, you’ll need to do that. Simo Ahava  has posted a blog post about the GTM Data Model here. If you want to know access the exact values that Google Tag Manager sees in the Data Layer, use methods described in the tip #19.

#17. “Tag Fired” ≠ data was properly sent to a 3rd party tool

Even though a tag is displayed among “Fired” in the GTM Preview and Debug mode, this does not mean that the data was sent to another tool (e.g. Google Analytics or Facebook Pixel) as you expected.

It is pretty common among beginners to assume that if a tag has fired, the job is done here. Even if that happened, the request might end with an error (404, 502, etc.). Or maybe the request was indeed sent properly but the values of your variables were undefined.

So how can you make sure that the data reached its destination as you intended? There are several options:

• Check real-time reports if they exist in your tool of choice.
  • For example, in GA real-time reports you can debug page views, events, conversions. When your tag is fired in the Preview and Debug mode, go check the real-time reports and see if the data is actually displayed here. Keep in mind that custom dimensions, custom metrics, e-commerce data are not available there.
  • As for the Facebook Pixel, you can also check their real-time data in Facebook Analytics. Go to analytics.facebook.com, open your Pixel’s reports and in the left sidebar choose Event Debugging. This is where you can check what data was recently picked up by Facebook.
• Check the Network tab in your browser’s Developer Tools. In developer tools, go to the Network Tab to see the list of requests that your browser has made on that page. You can locate a specific type of request by using the filter feature. For example, if you’re debugging Facebook Pixel requests, enter facebook.com/tr/ to see the requests sent by Facebook Pixel. If status codes are 200, this means that everything is great. Sometimes internal redirects are possible so 307 status code is also fine, as long as you see other requests getting the 200 OK.
  Read Simo Ahava’s guide where he explains this topic more in-depth.
• Use helpers (browser extensions) tailored to debugging of particular tools/platforms. I will not dig deeper into this topic a bit later (in one of the upcoming chapters in this blog post). But when I say “helpers”, I’m talking about Facebook Pixel Helper, Twitter Pixel helper, GA Debugger, etc.

#18. Check if there are more website elements matching the same CSS Selector

If you’re actively tracking clicks and other interactions by using element IDs, CSS Classes, or Matches CSS Selector operators in GTM, you’ll find this one useful. By employing HTML element attributes and/or operator in their GTM triggers, people are often assuming that those attributes/CSS Selectors are pretty unique and apply only to those elements that they wish to track.

Well, usually that’s not how things work.

The problem with this approach is that people cannot be 100% positive that those classes, IDs, etc. are unique enough to rely on. What if you want to track clicks of one element with a CSS class btn-bt? How can you be sure that you’re not setting a trigger that will cause many false positives?

In fact, there is a decent chance that there are more elements on that page/website with a similar CSS class. So if you’re checking your analytics reports and wondering why there was a click tracked on a certain page (even though the page does not contain THAT SPECIAL ELEMENT), this tip is for you.

Let’s continue with the aforementioned example, CSS class btn-bt. In order to know the number of elements that utilize this class, open the JavaScript console in your browser’s developer tools and enter the following command:

Replace the your_css_selector with the actual CSS selector you wish to test against. In our case, the selector is “.red-block”.

Hit enter. What you’ll see is the list of all the elements on a page that use this class. In the example below, I got 2 elements. You can tell that from the number next to the NodeList and if you click the triangle next to it, you’ll see the list of all HTML elements that use that btn-bt CSS class).

To make use of this method you need to possess at least some basic knowledge of CSS selectors. Simo Ahava’s guide is very useful here.

How many elements do you see after you launch this command? Is that the result you expected? If not, then try narrowing down the CSS Selector to pick the item you are actually interested in.

The most common CSS Selectors for beginners are:

• .class
• #id
• parentElement > directChildElement
• parentElement descendant
• And if you want to dig a bit deeper, read Simo’s guide.

#19. google_tag_manager[‘GTM-XXXXXX’].dataLayer methods

If you want to access values stored in Google Tag Manager’s data model from outside GTM, you can use the google_tag_manager interface.

google_tag_manager[‘GTM-XXXX’].dataLayer.set(‘key’, ‘value’) sets the value of keyName to someValue in GTM’s data model. This is the equivalent to using dataLayer.push({‘key’: ‘value’});

google_tag_manager[‘GTM-XXXX’].dataLayer.get(‘key’) fetches the value stored in GTM’s data model for variable name key.

google_tag_manager[‘GTM-XXXX’].dataLayer.reset() clears GTM’s data model and removes all stored keys.

As for debugging, the most useful here is google_tag_manager[‘GTM-XXXX’].dataLayer.get(‘key’) because you can quickly find out what should be the correct value of your Data Layer variable (without having the need to constantly update the actual variable in the GTM UI and refresh the preview mode).

I bet that this still looks confusing to some of my readers. No worries! A bit more visual explanation of this can be found in MeasureSchool’s video (starts @1:07) and @5:07 you’ll learn about one of the ways where you can apply this in practice.

Too many Google Tag Manager debugging tips at once? No worries. Just bookmark this guide and come back at your earliest convenience.

Part III: Google Tag Manager debugging with browser extensions

A whole bunch of time-savers that will make your work much easier.

#20. Inject your Google Tag Manager container with extensions like Tag Manager Injector or dataLayer Inspector+

When you create a new Google Tag Manager container, a developer must add its code to website’s source code to make it work. But what if he/she is currently busy and can do that only after a couple of days? With injector extensions, you can emulate your GTM container on any website and then continue working/configuring GTM without any disruptions.

For sake of simplicity, I’ll demonstrate Tag Manager Injector. Install the extension from the Chrome Store and click its icon. Enter your GTM container’s ID. Click Start.

What this extension does is it injects your Google Tag Manager container on all tabs of the browser (if you want to narrow down in which tabs should the container be injected, use the Include Domains feature and enter only those hostnames to which you actually want to inject the container.

So after you enable the Preview and Debug mode, you’ll start seeing the debugging panel at the bottom of the screen. Even though the container code is not actually added by a developer to the website’s source code, you can successfully debug and configure your tags, triggers, and variables.

Once the developer actually implements the container code, your GTM configuration will be already ready.

Another situation where I use it is when someone asks for help to debug a particular issue. I just inject my own GTM container and do configurations that are needed to replicate the issue and resolve it.

Keep in mind:

• Using Tag Manager Injector, dataLayer Inspector+ or any other injecting extension will work only within the boundaries of your browser. Calm down, you are not hacking the actual website. You’re just playing in your sandbox.
• If there is already some GTM container added directly in a website and you have injected your own container, you WILL NOT see the content of the original container. I’m talking about tags, triggers, variables, their configuration. On the other hand, you will be able to see what’s in the Data Layer. But that’s it.

#21. dataLayer inspector+

AnalyticsPros have created an amazing browser extension that can be used as a Swiss army knife in Google Tag Manager debugging and testing. Not only can it inject your GTM container but there are also other goodies at your disposal.

If you want to learn more about its full capabilities, read this guide and this one.

To name a few out of many awesome (and very helpful) features:

• Visually visible requests to Google Analytics in browser’s JavaScript console.
  
• Google Analytics Duplicate hit identification. Useful if you don’t want to mess your bounce rate.
• Timing. You can tick the checkbox to see you how long it takes GTM to process a hit from the dataLayer push to the eventCallback.
  
• Validations (for example missing keys in an E-commerce object. See the screenshot below)
  
• Previously mentioned: Data in the Data Layer is preserved across multiple pages (see tip #6).
• One more useful feature became a separate tip in this blog post. Continue reading.

#22. Block already existing GTM containers in order to inject your own. Fresh and clean.

This tip is related to the aforementioned dataLayer Inspector+. I did not want it to blend with just a mention of the extension so I created it as a separate tip.

Here’s the situation. Someone asks for your help to debug an interaction with the GTM on a particular website, which already has its own Google Tag Manager container. For some reason, you cannot quickly get access to the original container so you decided to inject your own (for testing purposes).

Even though you cannot see in your Preview and Debug mode original container’s content, you’re still able the monitor what’s happening in the Data Layer and play around with the website itself.

The original container is actively using the Data Layer and keeps pushing some data that is messing around with your container. This just makes the debugging inconvenient as you’re seeing events that should not be seen in your container.

What’s the solution? You could temporarily block the original container’s script so that it would not interfere with your debugging efforts. Luckily, dataLayer Inspector+ offers a neat feature called Block & Swap Script.

Open dataLayer Inspector+ > Inspect > Advanced Options > Block & Swap Script and paste the old GTM container’s ID.

The plugin will be looking for all the scripts on a page that contain that string (your GTM Container ID) and will block them.

That way, the original container will not mess with your debugging. Again, this is happening only within the boundaries of your browser, therefore, you’re not affecting other visitors.

#23. Da Vinci Tools

Another Swiss army knife that became a default in my Google Tag Manager stack is Stéphane Hamel’s Da Vinci Tools. It’s a handy and neat Chrome extension that tweaks and adds useful enhancements to your Google Tag Manager interface (GA and Data Studio too!).

Here are my favorite features related to debugging:

• Ability to copy the data from the Data Layer tab in the GTM Preview and Debug mode. Have you noticed that, by default, it’s impossible to copy anything from the Preview mode’s Data Layer tab? Well, not anymore. Da Vinci got you covered. After you install the plugin, the Copy option will be back!
  
• Tidy GTM Preview (e.g. tag blocks are enriched with icons)
  
• Remembers if the Preview and Debug pane is minimized (and keeps it that way after the page is refreshed)
• Exit the Preview and Debug mode directly from the debug pane
  

Also, I’ve seen Stéphane mentioning somewhere that in the long run, he plans to add debugging features similar to the WASP extension, which (surprise!) was also developed by him.

#24. GA Debugger

This extension is useful if you want to dig deeper into what data was passed onto Google Analytics. Once installed and enabled, it enables GA’s debug mode that starts displaying the data in the browser’s JavaScript console (among other Developer Tools).

To enable it, simply click the extension’s icon and you’ll see the ON badge. This indicates that the GA Debug mode is enabled and you can start checking the data.

After the extension is enabled, open browser’s JavaScript console and refresh the page. You’ll start seeing all the requests that were sent to GA.

Even though the info might look a bit too technical, this is definitely worth checking out as it (more or less) clearly displays all the parameters that were passed to Google Analytics. Every GA hit (e.g. pageview, event, etc) is visible as a separate table with all the parameters and their values.

By default, browser’s console is cleared every time the page reloads. So if you want to preserve what was captured, enable Preserve Log setting:

#25. GA debug mode setting in GTM

Even though this tip should have probably been mentioned in one of the other chapters of this post, I thought that it would be more appropriate to mention this right after presenting the GA Debugger extension.

Alternatively to GA Debugger, you can also see the GA payload data in the console just by enabling the following setting in the GA Settings Variable that is being used by your Google Analytics tag.

Once enabled, it will display the very same data as it was with the GA Debugger extension.

To make this data visible only when you have enabled GTM Preview and Debug mode, enable the built-in variable called Debug Mode. It returns true if you’re currently in the Preview and Debug mode.

That variable then should be inserted into the Debug Mode field of your Google Analytics Settings Variable or GA tags.

So while you’re in the GTM preview mode, the GA debug mode will be enabled too. And when you exit the preview mode, the Debug Mode variable will return false, therefore the GA data will stop being logged in browser’s console. Nice and clean.

#26. Use Tag Assistant recordings to debug Google Analytics implementation

First things first, Google Tag Assistant is a Chrome Extension that helps you validate the tracking code on your website and troubleshoot common problems and makes the entire process much easier and faster. It enables you to record a typical user flow, it keeps track of all the hits you send, checks them for any problems, and gives you a full report of interactions. In case of any issues or potential improvements, it will let you know about them.

By default, Tag Assistant is in the “sleep mode”, meaning that it does not check anything that’s happening on a page. In order to activate it, click the blue tag icon and then Enable.

Now refresh the page. If any of Google’s products are implemented on that page, you’ll start seeing a particular number within that blue tag icon which represents the count of tags found.

A great, yet often underused feature is session recordings. Recording a flow produces a report of all hits that were sent via marketing tags. This lets you validate that a particular tracking tag on your site works as expected.

For example, if you own an e-commerce site, you could run through the pages and steps required to select an item, place the order, and submit payment. After the recording is complete, you can review all events/pageviews/etc. that were passed through and see what particular data was sent, what errors occurred, where they happened, etc.

To start recording a flow, click the Tag Assistant icon and then RECORD button.

The actual recording will start after you refresh the page. During the entire session, a red dot will be attached to the blue tag icon. To stop recording, click the icon, the red STOP RECORDING button and the summary of the session will be displayed. Click Show Full Report.

This report will give you more insights into what happened during that recording session. Two types of reports are at your service:

1. Tag Assistant Report.
2. And Google Analytics Report.

The Tag Assistant report shows all the tags that fired on all the pages you visited during the recording session. The controls in the left-hand panel let you do the following:

• Filter tags
• Switch between detailed and basic views
• Show/hide ignored requests.

The main body of the page contains Recording summary (of what happened during the session) and recorded pages. Click every page to expand its details and tags that were fired. Keep in mind that these tags are listed alphabetically (and not in their sequence).

The 2nd report (Google Analytics Report) will show an emulation of how Google Analytics will process the hits. The tab will recognize the account ID for this site and will allow you to see the full report (if you have access to that account).

In it, you’ll see multiple data points collected by Google Analytics including acquisition data, behavior data, and conversions data. If you notice some issue in the report that needs to be fixed in the GA account (say, you had to configure a Cross-domain tracking’s Referral Exclusion List in your Google Analytics account), feel free to do that.

After you’re done, just go back to the Google Tag Manager’s report and hit the Update report button in the top left corner. The plugin will check the entire recording session against your new GA Property settings and will let you know if the issue was fixed. That’s a real time saver!

#27. Non-standard Google Analytics implementation is not a problem

So you implement Google Analytics tags via Google Tag Manager, open the Tag Assistant and see that GA tag’s color is blue, not green. Click it and you’ll get a message “Non-standard implementation” under the “Where to optimize?” section.

There’s nothing to worry about. Turns out, Tag Assistant always displays GA implementation as Non-standard if it was added via GTM.

Case closed.

#28. Google Tag Manager debugger

Yet another amazing GTM-related Chrome extension, this time developed by David Vallejo. It adds an additional tab to your Chrome browser’s Developer Tools that eases your Google Tag Manager debugging process.

First of all, the extension clearly displays (in a pretty readable manner) the data that was pushed to the Data Layer and the current data that is stored there. If you want to copy the Data Layer (e.g. to send the snippet to a developer (to report a bug)), you can do with with a couple of clicks.

If Enhanced E-commerce data was sent to Google Analytics, an additional tab will activate within the interface of the plugin. It displays all the E-commerce steps completed in the exact order they occurred. Each step can be expanded and checked in greater detail. If the number of products is too overwhelming, feel free to use the search field.

And if the website (that you’re working on) tracks A LOT of interactions, it might be a good idea to filter them out and track only particular types of GA hits.

At this moment, David is actively updating/improving the extension thus I’m sure that you’ll find some new features there pretty soon. I still catch myself discovering something new (and pleasant/convenient) there.

#29. Use helpers/debugging plugins tailored to specific tools

I’m talking here about Facebook Pixel Helper, Twitter Helper, and other similar plugins tailored to specific tools. These browser extensions let you easily debug what kind of data was passed to 3rd party tools and whether that data was formatted properly.

For example, once you install the Facebook Pixel helper and load a page where the pixel is present, you’ll notice that extension’s icon has become active.

Click it to see the detailed view of what was captured and what was transferred to Facebook’s servers.

If tracking issues occur, the extension will display that in a readable manner. Once you fix the problem, refresh the preview and debug mode. then the page and revisit the plugin’s report once again to check if that helped.

Part IV: Other GTM/GA debugging tips

Everything else that I could not find a place to.

#30. Don’t see the data in GA Real-time reports?  There are several possible reasons

So you’re debugging Google Analytics implementation, checking real-time reports but, for some reason, cannot see the data coming in. Why?

• There’s a chance that you (or someone else) inserted the GA Settings Variable in the GA Tracking ID field (which you shouldn’t)
• GA filters are involved (most often IP-related filters are the ones to blame)
• You forgot to clear quick filters in real-time reports
• An opt-out extension is enabled in your browser
• Events are set to non-interaction hit: true. Such events are visible only if you switch to the “Last 30 minutes” option in your real-time event reports
• Privacy-related extensions (like Ghostery) are blocking your GA trackers or GTM
• You’re sending data to the wrong GA property
• You’re checking User ID view in GA but you’re not passing the actual User ID with events/page views to GA
• Maybe GA isn’t installed on a page at all?

I have posted an in-depth guide explaining these reasons and how to solve them.

#31. Not every GA interaction is visible in the real-time reports

Real-time reports show you the most common interactions, page views, and events. Unfortunately, if you wish to see e-commerce data, social interactions, timing hits in GA, you’ll need to wait for them to appear in our actual reports.

So if you wish to debug them beforehand, you’ll need to use browser extensions or GA debug mode to see what data was passed to GA and whether it was formatted properly. But in order to check if the data has actually reached the destination, you have no other choice rather than wait.

#32. It is possible to test GTM implementation (web) on a mobile device

If you want to check what’s happening in the Preview and Debug mode while being on a mobile device, just enable the P&D mode on your desktop/laptop, click Share Preview and copy the generated link (don’t forget to enter the Destination URL for easier access).

Send that shared preview’s link to a chat/email/whatever so that you could open it via a mobile device.

That’s it! Now you’ll see the Preview and Debug mode.

Of course, it won’t be the most pleasant experience but it still possible to work. Pro tip: consider enabling Desktop view in your mobile browser to see more of the debug console.

In order to exit the debug mode, revisit the shared preview link and click Exit.

Update: Jean (in the comments of this blog post) also suggested an alternative solution: It is possible to test GTM implementation (web) on a mobile device You can simply activate the Toggle Device Mode in Chrome Dev console or Ctrl + Shift + M (while the Console is open). I use it to check that my tags fire only on mobile.

Google Tag Manager Debugging: Final words

Whew! That was a long one! As you can see there a lot of things to know and/or try when it comes to Google Tag Manager debugging. Although some of these tips are related purely to Google Analytics, GA is the most common 3rd party tool that’s being configured within GTM. So I guess it’s fair enough.

Anyway, the key takeaway here (especially for beginners) should be that that GTM debugging consists not only of checking if a tag has fired. That’s just a beginning. You also need to make sure that:

1. The data/request was sent successfully (e.g. via Network tab or some browser extension)
2. And it is properly displayed in the 3rd party tool (e.g. Facebook Pixel, Google Analytics, etc.)

And also there are a lot of different testing/debugging tools you can choose from. So pick the ones you find the most suitable/convenient go hunt those bugs!

The list of these tips is definitely far from complete. So whenever I remember something else (that is useful) or if you have some GTM debugging tricks up your sleeve, feel free to share it in the comments and I’ll probably add it to the guide.