Whether we’re QA’ing a new implementation or troubleshooting existing tracking issues, DebugView has been a good addition to Google Analytics 4.
It adds another layer to check if we are getting the data we want and what it looks like when received in GA4.
But, like all things tech, sometimes it doesn’t work how we want it to, which can be quite frustrating, especially if we are in the middle of an important task with a tight deadline.
Now, there could be multiple reasons for the DebugView not working so we’ll look at the top 11 reasons and learn how to fix Google Analytics 4 DebugView. They are:
- Debug mode is not enabled properly
- Blocked by browser extensions or browser
- Not selecting the correct device
- GA4 filters
- Blocked by content security policy (CSP)
- Consent settings
- Server-side tagging
- Restart/update the browser
- WordPress related issues
- Clear cookies and cache
- Bugs and delays
Let’s debug the Debugview!
1. Debug mode is not enabled properly
GA4 debug mode sends certain parameters like _dbg with GA4 requests. If the debug mode parameter is not being sent, then you won’t see events flowing into the DebugView.
There are three ways to enable debug mode:
- GTM’s preview mode
- Google Analytics Debugger extension
- debug_mode parameter with events
If you’re using any of these methods, you can verify if the debug mode parameter is being sent with your requests by going to Developer tools → Network tab → Searching for dbg.
As you can see, the request URL has _dbg=1 which means it is being sent as a parameter.
If you’re using more than one method to enable the debug mode, e.g., GTM’s preview mode, and then also enabling the GA Debugger extension, then it could create a conflict.
Therefore, it’s recommended to use only one method. Generally, the preview mode works best.
2. Blocked by browser extensions or browser
Ad blockers and other privacy browser extensions like Ghostery, uBlock Origin, or Block Yourself from Analytics can block analytics, not seeing any data in your DebugView even if you can see the events being sent from GTM’s preview mode.
If you’re sure that you’re not using any such extensions, then you’d have to disable your extensions one by one and test if there’s some other extension that you’re not aware of that can be blocking GA4 or GTM.
Yes, some extensions in this category can also block GTM so the preview mode won’t work.
A quicker way would be to go into incognito mode first to test if extensions are the culprit. If they are, you can test them individually to find out which one it is so you can remove only that one.
Now, if you’re using more privacy-friendly browsers like Brave, Safari, Mozilla, etc., they could be blocking GA4, in which case you can try using the DebugView on a different browser.
3. Not selecting the correct device
This is quite a simple one yet it can happen easily. When you’re in DebugView, you can choose the Debug Device in the top left corner.
If multiple users work in your GA4 property and are testing things, it could get confusing if it says Apple or Google for different devices.
You have to make sure you’ve selected the correct one by triggering specific events while selecting the device you believe is the correct one.
If you don’t see your device in the drop-down menu, then a quick refresh can also sometimes fix that.
4. GA4 filters
Currently, there are two GA4 filters available: Internal and Developer.
The first one helps you filter out internal traffic based on IP addresses including the DebugView; whereas the second one lets you filter out the debugging traffic from the reports but still shows up in the DebugView.
While it’s out there that if one of the two filters is active then you could face issues with DebugView, there hasn’t been an exact reason for what causes this or if it’s true every time.
However, if your IP address is excluded as ‘internal traffic,’ you won’t see yourself in the DebugView.Â
You could temporarily make it inactive and then test events at the risk of having other employees’ data making their way to the reports, but this won’t be an issue if you’re using a test property.
Another solution is to use a VPN to change your IP address while testing solutions. There are free VPN browser extensions that might be quicker to use if you don’t use any specific app frequently.
5. Blocked by content security policy (CSP)
If your website’s CSP is too strict and it blocks GTM or GA4, then you won’t be able to see any data in your DebugView. You won’t be able to track much in GA if that’s the case.
You should be able to see some messages in your Developer Tools → Console tab if your CSP is blocking certain scripts from loading.
In this case, you should get in touch with your devs and request them to ensure that the CSP allows domains for GTM and GA4 to work, as you won’t be able to fix this on your own.
6. Consent settings
Consent settings and chosen options can get pretty tricky quite quickly.
Based on what type of consent you give, i.e., accepting or denying the cookies, will affect whether the DebugView will work for you or not. This happens mostly when there’s a cookie banner in place, often with a consent management platform (CMP).
The easiest way is to clear the cookies on the website and see what happens when you accept the cookies.
Do you still see data being sent to GA4? If yes, then the DebugView should work. But if that’s not the case, then you need to further investigate how your consent mode or the (CMP) is set up.
If the cookies are denied, then you won’t be able to see any data in the DebugView.
Now, it could get more complicated when you’ve implemented consent mode version 2 where cookies are denied. GA4 still tracks data, but it’s limited, and therefore, you won’t be able to see it in the DebugView.
7. Server-side tagging
If you’re using server-side tagging, the DebugView with GTM’s preview mode can be a hit-or-miss. So, you will have to manually send the debug_mode parameter with ‘true’ or ‘1’ as a value with your events.
However, make sure you remove that once you’re done debugging.
But, if you’re going into debug mode via the GA Debugger Chrome extension, it won’t work with server-side tagging because it supports requests pointed toward Google’s domains (end-point e.g. www.google-analytics.com).
On the other hand, with server-side tagging, you’d be using your private server which points to a non-Google domain (custom end-point, e.g., data.measureschool.com).
So, in either case, you could use the debug_mode parameter as long as you remove it after you’ve done your debugging otherwise all events will be sent to DebugView only.
8. Restart/update the browser
In some cases, it helps to restart or update your browser. For instance, in Chrome, you often see a button at the top right corner that says ‘Relaunch to update,’ in some cases that can make a difference as well.
As this is about Google Chrome, you’ll have to look into how updates/restarts work for your browser and follow the instructions accordingly.
9. WordPress related issues
If your website is built on WordPress, try clearing the cache. Sometimes logging out and into the admin panel can also trigger the DebugView.
Also, check for any plug-ins conflicting with your GA4 property. You may have also done some installation with a plug-in as well as via GTM, which shouldn’t have been done anyway.
10. Clear cookies and cache
Generally, this is a bit of a last resort. If other solutions haven’t worked, then clearing browser cookies and cache can help to jump-start the DebugView.
If you don’t want to clear all the browser cookies, you can do it for the website you’re working on and see if that helps.
11. Bugs and delays
Sometimes, there’s nothing wrong on our end that’s causing issues. When using different tools, there’s always a chance of facing some bugs and other delays due to many reasons.
As mentioned, GA4 has been known to have bugs since its inception and that doesn’t spare the DebugView either.
This can range from displaying prices weirdly to not showing devices until you select the drop-down and see a couple of them displaying there.
Other times, you could be sending events and they won’t display for some time, while you might be wondering if there’s something wrong with your tracking.
It has also been observed that while other events show up in DebugView, the key events (conversions) are delayed quite a bit.
These are some of the most common issues that can result in DebugView not working, but they are not all the reasons and solutions.
But as long as you are aware of what could be causing it and see if any of these might be relevant to your problem, you should be fine.
Summary
In this post, we learned 11 reasons DebugView is not working and how to fix Google Analytics 4 DebugView issues.
Which one works for you depends on what’s your situation, and depending on that you might want to work through the list to see if it gets resolved.
But as we discussed, it might not be a real issue, just some bug or delay that could be causing the DebugView to not work, so all you’d need is to have some patience and see what works.
If you do get DebugView working as expected, then it packs a lot of power to help you debug your analytics setup and look at what sort of events are being tracked, their parameters, user properties, and items as well (for e-commerce).
If you’re keen on understanding how it all works and what you can do with the DebugView, check out our post An Overview of GA4 DebugView (Google Analytics 4) which goes into depth about its features.
Have you ever faced any issues with DebugView not working? Any bugs that you have noticed? What worked for you as a solution? Let us know it all in the comments below!
