Updated: January 3rd, 2022
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.
Video tutorial
Some of the debugging tips that I will cover in this blog post are also explained in my Youtube video (see below).
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
+ Show 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. If you want to get a quick introduction to the preview mode, watch this video:
#1. Orange banner is no more
If you are reading/watching a Google Tag Manager tutorial that mentions the orange banner, that tutorial is an old one.
Prior to October of 2020, every time you enable the GTM preview mode, an orange banner appeared in the interface of your container. Due to changes in the landscape of web tracking (and the limitations of 3rd-party cookies), GTM preview mode was rebuilt from the ground up. The way it works changed as well.
And one of the noticeable changes is that the orange banner is now gone.
So if the GTM tutorial says that it is necessary for the orange banner to appear, that is no longer true.
If you want to learn more about the preview mode, read this.
#2. Want to share preview and debug mode? Always include the destination URL and select GTM container
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.
In order to share the preview mode with someone, first, you need to enable the preview mode yourself and then in the top right corner, click three dots > Share.
Then a popup will appear where you will have to:
Enter the link of the website where the preview mode should be enabled
Select which container to enable (if there are multiple GTM Containers or GTAGs). IMPORTANT: you must select the GTM container in the dropdown
Copy the link and share it with someone you wish
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. Sometimes you need to do more to exit the preview mode
Even though you have quit the preview mode, you still might see this widget at the bottom of your website:
There are several reasons for that (for example, the first party cookie was not deleted properly or you have enabled the GA Debugger extension). In this blog post, I share several tips on what to do in such a situation.
#4. Preview and debug mode may not always work and there are many causes for that
There are many reasons why the GTM Preview and Debug mode does not work on your (client’s) website. In fact, I’ve listed a bunch of reasons and solutions to them. The list contains (but is not limited to):
Wrong container
AdBlockers
etc.
#5. 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.
#6. Some events in the preview mode are displayed differently as they really are
When it comes to standard events (like link clicks, youtube video events, etc.), they are displayed in a more user-friendly manner. Instead of seeing a technical “gtm.click” event, you see the “Click”.
But even though this is a bit friendlier, it is also a bit more misleading. Here are some of the events (with their real technical names) that are displayed differently on the left side of the preview mode:
gtm.click = Click
gtm.linkClick = Link Click
gtm.video = Youtube Video
gtm.triggerGroup = Trigger Group
Container Loaded = gtm.js
DOM Ready = gtm.dom
Window Loaded = gtm.load, etc.
#7. Enhance preview mode with Tag Assistant Companion or Tag Assistant (legacy)
If you want, you can improve the Preview mode by installing a browser extension called Tag Assistant Companion. This is especially useful if you hate when your website (during the debug) is opened in a new window (at least this is what happens on Google Chrome).
With the extension installed, your website will be opened in a new tab (instead of a window) when you enable the preview mode. This means that you can use things like mobile debugging again.
Also, you will be able to debug multiple tabs at the same time.
Furthermore, you will notice some shapes/emojis appear in the event timeline and in the Preview mode’s badge (on your website). These are added to help you quickly distinguish which window is currently being debugged.
In my video (at the beginning of this tutorial), I also showed that you can see those shapes/emojis in the Page Title. Unfortunately, that feature was quickly removed after the launch due to multiple complaints from users (this feature polluted reports that contained Page Title).
#8. Want to debug iframes? Tag Assistant Companion will also help
iFrame debugging with the preview mode is not as straightforward as you might think. Tag Assistant companion can also help in this case. Learn more here.
#9. Debugging multiple domains of the same user journey? Enable preview mode for every domain separately
If you are working with multiple domains (that are part of the same customer journey) and those domains are using the same Google Tag Manager container, you will need to enable the preview mode on both domains.
First, open tagassistant.google.com (or just click the Preview button in the GTM Interface) and enter the domain of the 2nd website. Complete all the necessary steps to enable the preview mode.
Then (also on tagassistant.google.com) click the X icon in the top left corner + select Keep the domain XXXXX enabled for debugging. Click Close Debugger. That way, you’ll keep the 2nd website in the preview mode.
Then press either the Preview button in the GTM interface OR Add domain button in tagassistant.google.com and add the domain of the 1st website. Complete all the necessary steps until website 1 is opened in a new tab or window.
What we have done here is that we set the _TAG_ASSISTANT=X first-party cookie on both domains (and this is needed for the preview mode to work). That’s why you can now navigate between both domains in the preview mode and you’ll see all the events/data coming from both websites.
#10. 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:
choosing the formSubmission event in the Preview and Debug mode (because you want to fire a tag upon this event)
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).
#11. 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.
#12. 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). By default, you might just see the variable names.
But if you switch to “Values”, you will see the output of each variable (which is much more informative):
#13. 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.
VERY IMPORTANT: Do not debug individual tags while having a Summary selected above the event timeline. This is an incorrect way to do. Always, select the event in the event stream first and only then click the tag to debug.
#14. 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).
When you do that, you will see:
The data that was sent
Firing triggers (and which conditions were met)
Blocking triggers
Take a closer look at the icons. If a trigger has a green check icon, that means that this trigger activated the tag.
This helps you identify possible reasons why one or another tag has fired (or not).
#15. 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?
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.
Learn more about the reasons why your tags might not fire (and which ones are not displayed in the preview mode).
#16. Missing Pageview Event? Not seeing any events in the preview mode at all?
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 that 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:
<script>
dataLayer = [];
</script>
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.
#17. 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 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:
404 not found for GET: GET http://www.googletagmanager.com/gtm.js?id=GTM-XXXXX
It is not critical but, nonetheless, you can fix it by reading this guide.
#18. 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 access to the GTM container right away.
To do that, open your browser’s JavaScript console and enter the 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 advanced, 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 to the exact values that Google Tag Manager sees in the Data Layer, use methods described in tip #19.
#19. “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 or some debugview 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 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.
#20. 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:
document.querySelectorAll(“your_css_selector”)
Replace the your_css_selector with the actual CSS selector you wish to test against. In our case, the selector is “.red-block”.
document.querySelectorAll(“.btn-bt”)
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.
I also explain this tip here:
#21. 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.
#22. Inject your Google Tag Manager container with extensions like dataLayer Inspector+
When you create a new Google Tag Manager container, a developer must add its code to the 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.
One of those extensions is dataLayer Inspector+
When you temporarily inject your container, you can already configure your setup. And when a developer finally actually installs your container to the website’s source code, your container setup will be ready.
#23. Even more cool features of 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 the 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.
#24. 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’s 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.
#25. 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 the 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, the browser’s console is cleared every time the page reloads. So if you want to preserve what was captured, enable the Preserve Log setting:
#26. 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.
#27. 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 ease 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 a couple of clicks.
If Enhanced E-commerce data were 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.
#28. Use helpers/debugging plugins tailored to specific tools
I’m talking here about Facebook Pixel Helper, Twitter Pixel 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 the 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.
#29. 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.
#30. Not every GA interaction is visible in the real-time reports (applies to GA3)
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.
#31. 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 a 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:
The data/request was sent successfully (e.g. via Network tab or some browser extension)
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.
The post 31 Google Tag Manager Debugging and Testing Tips appeared first on Analytics Mania.
Read MoreAnalytics Mania
