Home / GA4 debugger

The GA4 debugger that shows the request

GA4 has DebugView. It shows what Google Analytics received, for a property you own, once debug mode is on. Everything before that point is where the bugs live.

DebugView is a report. It renders events after GA4 has ingested and processed them, for a property you have access to, and only while the session is flagged for debugging. That makes it the right tool for one question — did GA4 accept this — and the wrong tool for the question people usually have, which is what the browser actually sent.

Tag Master reads /g/collect directly. Every parameter, in the order it went out, on any page, with no debug mode and no property access.

What DebugView cannot show you

• The request before GA4 touched it. Parameters that exceed a limit, custom dimensions that were never registered, values that were truncated — GA4 drops them quietly and DebugView shows you what survived. It does not show you what was sent and discarded.
• Anything without debug mode. DebugView needs the session flagged, which means an extension, GTM preview or debug_mode: true. That flag changes how the page behaves, and it is not how your real traffic is measured.
• Properties you do not own. No competitor, no client before the contract, no quick look at a site you are about to inherit.
• Everything else on the page. A GA4-shaped bug is often a Meta or TikTok problem wearing the same trousers — a shared dataLayer key, a consent gate hitting both.

What you see instead

The decoded hit: the event name, the event parameters split into their string and numeric forms, the client and session identifiers, the page location and referrer as sent, the consent signal riding along with it, and the sequence number that tells you whether a hit was the first of its batch.

Ecommerce items, unpacked

GA4 packs the item array into a compressed positional form — pr1, pr2, each a run of two-letter keys. It is readable, technically, and nobody reads it. The panel unpacks each item back into its fields so a missing item ID or a quantity of zero is visible at a glance instead of being decoded by hand.

This is where most ecommerce reporting problems turn out to be: not a tag that failed to fire, but a tag that fired with an item array assembled from a dataLayer that was one page behind. The longer comparison with DebugView works through what each one is good for.

Consent, on every hit

Under Consent Mode a denied hit still goes out; it goes out flagged. The distinction between "no hit" and "a hit that told Google not to use it for advertising" is invisible in DebugView and decisive when someone asks why conversions dropped. Each request carries its consent state, and it is read alongside the default-then-update sequence rather than on its own.

Where DebugView still wins

Anything about what GA4 did after receiving the hit. Whether the event was attributed to the right session, whether a user property stuck, whether an audience matched, whether GA4 accepted a custom dimension you have registered — that all happens on Google's side, and no browser extension can see it. Send the hit, then confirm it landed. The two halves are different tools.

Questions

Can I debug GA4 without DebugView?

Yes, for everything up to the point GA4 receives the hit. Reading the /g/collect request shows the event name, parameters, identifiers and consent signal as the browser sent them, with no debug mode and no property access.

Do I need debug_mode or the GA Debugger extension?

No. Those exist to flag a session so DebugView will display it. Reading the network needs neither, which also means the page behaves exactly as it does for real traffic.

Does it decode ecommerce items?

Yes. GA4 sends items in a compressed positional form and the panel unpacks each one back into its fields, so a missing item ID or a zero quantity is visible without decoding it by hand.

Does it show the Consent Mode state of each hit?

Yes. Every request carries its consent signal, shown next to the default-then-update sequence — which is how you tell a denied hit apart from a hit that never happened.

Does it replace DebugView?

No, and it is not meant to. DebugView is the only view of what GA4 did after receiving the hit: session attribution, user properties, audiences. This shows what the browser sent. Most debugging needs both, in that order.

Guides

The longer form, on the parts that catch people out.

• Debugging GA4 when DebugView shows nothing — Why the debug stream stays empty, what a /g/collect request actually contains, and how to check GA4 on production without switching debug mode on.
• Debugging Consent Mode V2: gcs, gcd and the violations nobody catches — Read consent parameters straight from the hits, tell a default apart from an update, and find the vendors that fire regardless of what the banner says.
• How to debug server-side GTM — Why proxied hits vanish from most debuggers, the four signals that reveal an sGTM setup, and how to connect a server preview session.
• When GA4 says the traffic came from somewhere else — Campaign parameters go missing between the click and the hit more often than anyone checks. Six places they disappear, and how to read the hit itself.
• Google Tag Gateway: checking that it actually works — Tag Gateway serves Google's scripts from your own domain. What changes on the wire, how it differs from server-side GTM, and the four ways it quietly half-works.
• Test Events for TikTok, Snap, UET and five more — Everyone knows about DebugView and Tag Assistant. Every other platform has the same thing, switched on by a cookie almost nobody documents — here is the full list.

The other two: GTM debugger, dataLayer inspector