Home / Guides

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.

Published 10 August 2026

DebugView is the tool Google gives you for this, and when it works it is the right answer: it shows what GA4 received, after processing, in the property you are looking at. The trouble is how many ways it can show nothing at all while the site is sending events perfectly well.

What DebugView can and cannot show

DebugView is a view of one debug-enabled device, on one property, after Google has accepted the data. That framing explains both its value and its limits.

• It confirms the event arrived. Nothing on the browser side can tell you that.
• It shows only GA4. Meta, TikTok, LinkedIn, Criteo and everything else on the page are invisible.
• It needs debug mode, which makes it a staging tool. You cannot point it at a live checkout you do not control, or at a client site, without changing that site first.
• It shows what was received, not what was sent. When those differ — a parameter dropped for being too long, an event renamed by a server container — DebugView shows the second and hides the first.

Why the stream stays empty

Roughly in order of how often it turns out to be the cause:

1. Debug mode is not actually on. GTM Preview sets it, the GA Debugger extension sets it, and a debug_mode parameter on the config sets it. Nothing else does, and a Preview session expiring in another tab turns it back off without saying so.
2. You are looking at the wrong property. The page sends to one measurement ID and DebugView is open on another. Common wherever a staging and a production property both exist.
3. Consent Mode is denying storage. Hits still leave as cookieless pings, but the device identification DebugView relies on is weaker and the device can fail to appear in the picker at all.
4. Something stopped the request. A content blocker, a corporate proxy, or a Content Security Policy that does not allow www.google-analytics.com. The tag ran; nothing left.
5. A server container in the middle. On server-side GTM with a misconfigured client, hits reach your own endpoint and stop there, which looks exactly like the tag never firing.

The first three you can rule out from Google's own interfaces. The last two you cannot — they happen before GA4 ever sees anything, which is precisely where a request-level view is the only witness.

Reading a /g/collect request

Every GA4 event is a request to /g/collect, and the whole event is in the query string. Once you can read it, you no longer need debug mode to know what was sent:

• tid — the measurement ID. Check this first when data lands in the wrong property.
• en — the event name, exactly as GA4 will store it.
• ep.<name> is a string event parameter, epn.<name> a numeric one. A value that should be a number arriving as ep.value is a real and common bug.
• up.<name> and upn.<name> — user properties.
• cid — the client ID, sid the session ID. A cid that changes between two pages is one person being counted as two.
• _p and _s — a page-load identifier and the hit counter within that page load. _s is how you spot a hit that never arrived: the sequence has a gap.
• dl, dr, dt — location, referrer, title.
• _et — engagement time in milliseconds.
• gcs and gcd — the consent state at the moment of the hit.
• _dbg — debug mode is on. Its absence is the fastest answer to "why is DebugView empty".
• cu and pr1, pr2… — currency and the ecommerce items, each item packed into one parameter carrying id, nm, pr, qt and the rest. Counting the pr parameters is how you find out a three-item cart shipped one.

Why the order looks wrong

GA4 does not send one request per event. Events fired close together are batched, and a batch goes out as a POST with one event per line in the body instead of a GET. On page unload the transport switches to sendBeacon. So the request timeline and the event timeline are not the same thing: a purchase can appear in the network log after a page view that happened later.

This is why matching events to their cause by arrival time gives the wrong answer, and why it has to be done by event name and payload instead.

The failure DebugView cannot show you

The most expensive GA4 bugs are not missing events. They are events that arrive looking healthy and carry the wrong payload. The dataLayer pushed three items and 1648.25 TRY; the tag sent one item and no currency. DebugView shows you the one item and it looks fine, because DebugView has no idea what the page intended.

Finding that class of bug needs both halves side by side: what the site pushed, and what actually left the browser. That comparison is the reason this extension exists.

A routine that works on production

1. Open the panel and reload. Every GA4 hit appears whether or not debug mode is on.
2. Check tid on the first hit. The wrong property is the cheapest bug to find and the easiest to overlook.
3. Walk the funnel. Watch _s increment without gaps and cid stay constant.
4. On the conversion, compare the push against the hit: item count, value, currency, transaction ID.
5. If a hit is missing, establish whether the tag fired at all. A tag that never ran and a request that was blocked look identical in a report and completely different here.

When DebugView is still the right tool

Use it when the question is whether Google accepted the data. If hits leave the browser correctly and the reports still disagree, the problem is on Google's side of the line — an internal traffic filter, a data stream misconfiguration, a reporting identity setting — and no browser tool can see any of that. The two views answer different questions, and a stubborn problem usually needs both.

Related guides

• Meta Pixel and CAPI: why purchases are counted twice
• How to debug GTM without Preview mode
• Test Events for TikTok, Snap, UET and five more