Debug View

DebugView is the Google Analytics 4 tool that shows events streaming from your device in real time, with every parameter laid bare. It is where you confirm a purchase event actually fires with the right transaction_id, where you spot a typo in a data layer push, and where you verify a conversion registers before you trust it in production reports. This guide explains DebugView in GA4 end to end: what it is, how it differs from the Realtime report, three ways to enable debug mode, the workflows that catch the most bugs, and the limitations every operator hits at some point.

What Is DebugView in GA4?

DebugView (sometimes written “debug view”) is a dedicated GA4 report that displays events from devices with debug mode turned on. Open it under Admin → DebugView, or via the Configure menu on older GA4 layouts. Each event arrives within roughly 60 seconds of firing and appears with its full parameter set, user properties, and item arrays — none of which you can see in standard reports until the next day.

DebugView only works for devices that have explicitly opted into debug mode. Your live traffic does not show up here. That isolation is the point: it lets you test changes against real GA4 ingestion without polluting production data or waiting for the standard 24- to 48-hour processing window.

DebugView vs Realtime Report — The Distinction That Matters

Marketers confuse these two reports constantly. They are not the same. Realtime aggregates everyone visiting the site right now; DebugView shows only your debug-enabled session with full parameter detail. Standard reports come a day later but include modeled metrics, attribution, and cohorts. Pick the right tool for the job.

If you need to verify a purchase event includes value, currency, and items, only DebugView shows you that. Realtime confirms the event hit the server. Standard reports tell you whether the event drove revenue.

How to Enable Debug Mode in GA4 — 3 Methods

Debug mode is the switch that puts a device on DebugView’s list. There are three reliable ways to flip it. Pick the one that matches your access and what you’re testing.

Method 1: Chrome Tag Assistant Companion

The simplest path for marketers. Install the official Tag Assistant Companion Chrome extension, then open tagassistant.google.com. Click Add domain, paste your URL, and Tag Assistant opens a debug session in a new tab. Every event from that tab streams into DebugView. No code changes, no GTM access required.

This is what I reach for when I’m auditing a site I didn’t build — the client’s stack might be Tealium, Segment, gtag.js, or a custom backend. Tag Assistant doesn’t care; it works with any GA4 implementation.

Method 2: GTM Preview Mode

If you’re editing a Google Tag Manager container, Preview is built for this. From your GTM workspace click Preview top-right, enter the URL, and Tag Assistant opens with debug mode auto-enabled. This is the path to use when you’ve drafted new tags and need to verify them before hitting Submit. GTM’s Preview pane shows tag firing on the left; DebugView shows the resulting GA4 events on the right. Use both panes together — they answer different questions.

Method 3: debug_mode Parameter

For developers and server-side setups, set debug_mode: true directly on the GA4 config. With gtag.js:

gtag('config', 'G-XXXXXXXXXX', {
  debug_mode: true
});

Or push it from a data layer on a debug-flagged page. For server-side hits via the Measurement Protocol, use the /debug/mp/collect endpoint instead — it returns validation errors as JSON without affecting your production stream. This method is the only way to debug app traffic, server containers, and CI test runs where Chrome extensions don’t apply.

Never ship debug_mode: true to production. Every event will be flagged as a debug event and may be excluded from reports depending on your GA4 settings. Use a feature flag or environment variable.

Reading the DebugView Stream

DebugView’s main canvas has three columns. The center column lists events in chronological order, newest at the top. Click any event to expand parameters in the right pane. The left pane shows a session timeline — a vertical strip of bubbles, each one an event, sized by parameter count.

What to look at when you click an event:

• Event parameters — every key you sent. If value is missing on a purchase, you’ve found the bug.
• User properties — what’s attached to the user, not the event. Login state, plan tier, audience flags.
• Items array — for ecommerce events, expand items to inspect each product’s item_id, price, and quantity.

The “seconds ago” timestamp updates live. If you fired an event 90 seconds ago and it still hasn’t appeared, your event isn’t reaching GA4 — check the network tab for the collect request first, then suspect a tag firing condition.

Filtering Events in DebugView

The left rail lets you filter the stream by event name. Click a chip to isolate, say, page_view and purchase while hiding the noisy scroll and user_engagement events. This is essential when a page generates dozens of events and you only care about one. You can also click a parameter inside an expanded event to filter to events containing that parameter — useful for tracking down a single offending transaction_id.

DebugView does not support free-text search across event names. If you need that level of filtering, export to BigQuery with the GA4 link and query the events_intraday_ tables.

Common DebugView Workflows That Catch Bugs

Three scenarios cover most debugging sessions. Each maps to a recurring class of GA4 events bug I’ve seen across implementations.

1. Verifying a purchase event after deployment. Enable Tag Assistant. Run a test transaction with a coupon code you’ll recognize, like QA-DEBUG. In DebugView, expand the purchase event and confirm transaction_id, value, currency, and the full items array. If value is zero, your data layer is sending strings instead of numbers — JavaScript silently coerces them, but GA4 attributes the revenue as zero.
2. Diagnosing a parameter mismatch. A custom dimension reports “(not set)” in standard reports. Open DebugView, fire the event, click into it. If the parameter you registered as a custom dimension isn’t on the event payload, your tag is missing the parameter mapping. If it’s present but the value is wrong, your data layer is to blame.
3. Confirming a conversion fires once. Mark an event as a key event, then test the trigger flow. In DebugView, count occurrences. Double conversions usually mean the trigger fires on both the form submit and the thank-you page data stream. Once you see two events for one user action, fix the trigger condition before more revenue inflates.

Limitations You Will Hit

DebugView is purpose-built for QA, which means it has tight constraints by design. Knowing them up front saves frustration.

• 60-minute retention. Events drop out of DebugView after about an hour. You cannot replay yesterday’s debug session — the data is gone from this view (it persists in standard reports if your debug events weren’t filtered).
• One device at a time per debug session. You can debug from multiple devices, but DebugView lists each as a separate device in the dropdown. If your team is testing in parallel, coordinate which device label is whose.
• ~60-second latency. Not instant. Events take up to a minute to appear, and during high-load periods that can stretch.
• Debug-enabled traffic may pollute reports. Some GA4 setups automatically exclude debug events from standard reports; others don’t. Check your Internal Traffic and Developer Traffic filters before assuming debug data is segregated.
• No historical search. DebugView is a live tail, not a query interface. For historical event-level inspection, use BigQuery export.

Alternative Debugging Tools

DebugView is the primary tool, but it’s not the only one. For complete coverage of a tracking implementation, layer in a few others.

I keep DevTools and DebugView open side-by-side for any non-trivial implementation. The Network tab catches issues at the transport layer (consent blocking, ad blockers, CSP errors); DebugView catches issues at the payload layer (wrong parameters, missing items). Together they cover most failure modes.

Frequently Asked Questions

Related Terms

• Event — the unit of data DebugView shows
• Data Layer — where the parameters DebugView displays originate
• Measurement Protocol — the server-side equivalent with its own /debug endpoint
• Data Stream — debug mode toggles per-stream
• Conversion — the highest-stakes event to verify in DebugView
• Purchase Event — the canonical use case for DebugView in ecommerce
• Real-Time Data — the aggregate view DebugView complements
• Tag Management — where Preview mode lives and feeds DebugView

Bottom Line

DebugView is the only place in GA4 where you can confirm an event fires with the exact parameters you intended, in near-real-time, before that event ever shows up in a report your boss reads. Use Tag Assistant for live sites, GTM Preview when editing containers, and the debug_mode parameter for everything else. Combine it with the Network tab for transport-layer issues and BigQuery for cross-user investigations. The 60-minute retention and per-device scope are limitations, not bugs — DebugView is a QA tool, not a monitoring dashboard.