GA4 debug view is the only place in Google Analytics 4 where you see individual events arriving in real time, with every parameter attached, for a single device you control. Standard reports take 24 to 48 hours to process. Realtime shows aggregates. DebugView shows the actual event stream — which is why every tracking problem should be diagnosed there first.
It is also the tool people give up on fastest, because enabling it is not obvious and an empty timeline gives you no clue why.
Where DebugView lives
It sits in the Admin section, under Data display → DebugView. In some interface versions it appears directly in the left navigation near Realtime. You need Analyst-level access or above to open it.
The screen has three columns. The far left is a device selector — DebugView only shows devices currently in debug mode, and if more than one is active you choose between them. The middle column is a minute-by-minute timeline of the last 30 minutes. The right column is a live-scrolling stream of the current session’s events. Click any event to expand its parameters and user properties.
Three ways to enable GA4 debug mode
The Chrome extension
Install Google’s official Google Analytics Debugger extension and toggle it on for the tab you are testing. This is the fastest route for checking a live production site as a normal visitor would see it, and it requires no changes to your site or container. It works per-tab, so remember to switch it off afterwards or your own visits keep appearing.
Google Tag Manager preview mode
Entering GTM’s preview mode automatically puts the session into debug mode for any GA4 tags in that container. This is the right choice when you are testing tags you are actively building, because you get GTM’s own debug panel showing trigger evaluation alongside GA4’s showing what actually arrived. Between the two you can see whether a tag failed to fire or fired and sent the wrong parameters.
The debug_mode parameter in code
Send debug_mode: true as a parameter on your config or event calls in gtag.js, or set a Debug Mode field on the GA4 configuration in GTM. Useful for staging environments where you want debug on permanently. Never ship it to production — debug-mode events are excluded from standard reports, so a site-wide debug flag silently stops your analytics from counting anything.
Reading the event timeline
The stream shows events in the order they arrived, newest at the bottom. A few things to look for:
- Event count per action. One page load should produce exactly one
page_view. Two means you have a duplicate installation — the gtag snippet hard-coded in your theme plus a Google Tag firing in GTM on the same measurement ID. That single fault doubles views, forces every session to qualify as engaged, and collapses your bounce rate. - Parameter values. Click an event and check that
page_location,value,currency,transaction_idor whatever matters is populated and correctly typed. An event that fires with an undefined value still counts and still leaves your reports hollow. - Key event markers. Events you have marked as key events are indicated in the stream, so you can confirm the marking took effect.
- User properties. The top of the right column shows the current user properties for the debug device — the fastest way to confirm a custom user-scoped dimension is being set.
Walk a full journey deliberately: load a page, scroll to the bottom, click an outbound link, submit a form, complete a conversion. Every enhanced measurement event should appear exactly once. If scroll fires twice, you have a legacy GTM scroll tag competing with GA4’s automatic collection — enhanced measurement already handles scrolls at 90% depth, outbound clicks, site search, video engagement, file downloads and form interactions, and rebuilding those manually is the most common double-tracking mistake in GA4.
GA4 DebugView not working: what to check
An empty device selector is the usual complaint. Work through these in order.
Debug mode is not actually on. The extension toggle is per-tab and resets. GTM preview mode opens a separate tab that must be the one you are browsing in. Confirm before anything else.
An ad blocker or privacy extension is blocking the request. uBlock Origin, Brave’s shields, Firefox’s enhanced tracking protection and most VPN-bundled blockers stop requests to googletagmanager.com outright. Test in a clean browser profile with no extensions.
The consent banner has not been accepted. With consent mode implemented, analytics requests are withheld or sent in cookieless form until consent is granted. If your banner defaults to denied, nothing meaningful arrives until you click accept.
You are looking at the wrong property or stream. Multi-property setups make this easy. Check the measurement ID actually firing on the page against the property you have open.
An internal traffic filter is set to Active with an Exclude action. If your IP is excluded, your events are dropped before they reach DebugView. Set the filter to Testing while you debug.
The tag is not on the page at all. View source and search for your G- ID. Obvious, and it is the answer more often than anyone likes.
A different device is selected. If several people are debugging, the selector may be showing someone else’s stream. Pick yours.
What DebugView cannot tell you
It shows collection, not reporting. An event arriving perfectly in DebugView can still be absent from a standard report for entirely legitimate reasons, and confusing the two wastes hours.
Processing delay is the first. Standard reports take 24 to 48 hours to fully settle, so an event you fired an hour ago being missing from Reports is expected behaviour.
Data thresholding is the second. When Google Signals is enabled and a segment is small enough that individuals could be identified, GA4 withholds rows entirely. You will see a small icon near the report title. Widening the date range or switching reporting identity to Device-based usually restores the data.
And attribution is the third. DebugView shows the event; it does not show which channel will eventually be credited. GA4 defaults to data-driven attribution, last-click is a setting rather than the default, and switching models recalculates historical reports retroactively.
Building DebugView into a routine
Treat it as a release gate rather than an emergency tool. Before any template or checkout deployment goes live, run the same scripted journey in debug mode on staging, and record what fires. After deployment, run it again on production. Ten minutes of this catches the regressions that otherwise surface six weeks later as an unexplained conversion drop.
Also use it whenever you inherit a property. A ten-minute debug walk of the site tells you more about data quality than a day of reading reports, because reports look plausible whether or not the underlying collection is sane.
The half of the picture GA4 does not have
Once collection is verified, remember what GA4 fundamentally cannot see. It knows what happened after the click and nothing about the search result that produced it — no query, no impressions, no average position. Organic Search in GA4 is a channel bucket. If organic sessions fall while your tracking is provably clean, the cause is upstream and Search Console holds it.
SEO Rocket connects Google Search Console and GA4 and treats them as ground truth for your own site’s performance, showing real clicks and sessions next to third-party index estimates with every source clearly labelled, so a traffic change can be traced to a position change rather than debated. Third-party position and volume data are modelled estimates; your own Google data is not. SEO Rocket does not replace GA4, build custom GA4 reports, or implement or debug tracking code on your site — DebugView is still where you prove the tag is right.
A five-minute debug walk
Open a clean browser profile, enable the debugger extension, and load your homepage. Confirm one page_view. Scroll to the bottom and confirm one scroll. Click an external link and confirm one click. Trigger your primary conversion and confirm one key event with populated parameters. If all four are clean, your data is trustworthy enough to argue with. If any fires twice, fix that before you report another number.
