Guide 13 · Debugging · GA4 + Tag Manager
Your ad blocker is eating the GA4 requests: test with it off
Ad blockers stop the collect request before it leaves the browser, so Tag Assistant, the network tab, and GA4 all stay empty at once. The test is simple: turn it off and count again.
After the steps below, the same action sends collect requests with the blocker off and none with it on, and the difference is a blocker, not a tag fault.
Download the check: the debugging check (JSON) (MD5 8424f0070221e6fb64f1cfe3d0f2a4d2, 425 bytes). It lists the checkpoints from this guide and the worked check, with the figures recomputed. The file was built for this guide and validated structurally — it was not exported from a live container or a live property.
What you need
- The browser with the blocker on. The browser you normally test in, with the blocker running as your visitors run it.
- The same browser with the blocker off for your site. Most blockers let you pause on one site; use that, so the rest of your browsing stays blocked.
- developer tools, network tab. Filtered for collect, so you can count the requests in each state.
- One repeatable action. A page load or a click you can do exactly the same way twice, once per state.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Collect requests with the blocker on | 0 |
| Collect requests with the blocker off | 5 |
| Events done in each state | 5 |
| Requests lost to the blocker | 5 |
Five actions were done with the blocker on and 5 with it off. With the blocker on, 0 collect requests appeared; with it off, 5 appeared — 5 minus 0 is 5 requests the blocker removed. Every request that should have been sent, 5 of 5, was stopped in the browser before it left.
- Count requests with the blocker on. Open your site, open developer tools on the network tab, filter for collect, and do the test action five times. Write down how many collect requests appear. In the worked check the answer was 0.
- Pause the blocker for your site only. Click the blocker icon and pause it on this site. Do not turn it off everywhere, and do not test in a browser profile that never had a blocker — you want to know what your normal setup does, not what a clean profile does.
- Count the same actions again. Reload the page, do the same five actions, and count the collect requests again. In the worked check the answer was 5. If the count jumps from 0 to 5, the blocker was the whole problem.
- Check Tag Assistant agrees. With the blocker off, start Preview and repeat the action. The tag should now sit under Tags Fired and the event should reach DebugView. If the tag still does not fire with the blocker off, the blocker was hiding a second problem, not causing the only one.
- Decide what the blocker means for your data. Visitors who run blockers will not be counted, and there is no tag fix for that — the request never leaves their browser. What the count tells you is how much of your missing data is blocker-shaped: if your own tests fail only with the blocker on, your tag is fine and your test setup was the fault.
Dead ends
DEAD END — TESTING ONLY IN THE BLOCKED BROWSER. If every test you run happens in a browser with a blocker, every test fails the same way and the tag looks permanently broken. Run the same test once with the blocker off before you change any tag.
DEAD END — THE BLOCKER HIDES THE NETWORK TAB TOO. A blocked request does not appear as a failed request in the network tab; it simply never appears. An empty filtered log is the fingerprint of a blocker, not of a tag that never fired — check the blocker before you check the trigger.
DEAD END — FIXING THE TAG SO BLOCKED VISITORS COUNT. No tag change makes a blocker send the request. Renaming the tag, moving it, or adding a second tag does not get past a blocker that stops google-analytics.com requests. Accept the loss, and fix the test setup instead.
End state
Two counts, side by side: requests with the blocker on, and requests with it off. If the numbers differ, the blocker is the cause and the tag is sound. If they are the same, the blocker is cleared as a suspect and the hunt moves to the tag, the trigger, or consent.
Sources
- Analytics Help — Confirm that you are collecting data — Realtime and DebugView as the reports that confirm collection — an empty Realtime with a blocker on is not proof the tag is broken
- Analytics Help — Monitor events in DebugView — Events not visible in debug mode when client-side privacy controls are implemented
Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. What was run: the blocker counts, recomputed — 5 actions in each state, 0 requests with the blocker on and 5 with it off, so 5 minus 0 is 5 requests lost to the blocker. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.