GA4 DebugView: Enable It, Read It and Fix It When It's Empty

GA4 DebugView is a report in Google Analytics 4 that shows every event, parameter and user property sent from a device in debug mode, almost as it happens. You open it under Admin, Data display, DebugView, and it stays empty until you turn on debug mode with Google Tag Manager Preview, the Google Analytics Debugger extension or a debug_mode parameter. Use it to confirm GA4 received the right data before you wait a day for reports.

This guide covers the three ways to enable it on a website (plus apps, server-side tagging and the Measurement Protocol), how to read the screen, a step-by-step test routine, and a layer-by-layer fix when DebugView shows “No devices available.” It also covers what most guides skip: checking that a conversion carries a value GA4 can count, checking which landing page and source it will be credited to, and why events can appear in DebugView but never in your reports.

What GA4 DebugView Is (and What It Is Not)

DebugView is a filtered, unprocessed view of incoming data. It only shows hits marked with a debug flag, and it shows them per device, so you can watch your own clicks without other visitors in the way. Google describes it as a way to troubleshoot while you install tags or step through a user’s live activity (Monitor events in DebugView).

It is easy to confuse with two other tools. Each answers a different question:

A full test uses them in order: GTM Preview proves the tag fired, DebugView proves GA4 received it, and the reports prove it was processed the way you meant. DebugView also does limited attribution, so Google recommends the Acquisition reports for source and medium.

Where to Find DebugView in GA4

Click Admin (the gear icon, bottom left), then under Data display click DebugView. Older guides and screenshots show it under a Configure menu; that menu has been folded into Admin, so if you follow a 2021 tutorial and cannot find it, this is why.

How to Enable Debug Mode for GA4 DebugView

DebugView only lists hits that carry a debug flag. In the network request that flag appears as _dbg=1 or ep.debug_mode. There are three ways to add it on a website:

Method 1: Google Tag Manager Preview mode

In your GTM workspace click Preview, enter your site’s URL and click Connect. Your site opens connected to Tag Assistant, and every GA4 hit from that browser carries the debug flag, so it shows up in DebugView with no extra setup. Keep both windows open: Tag Assistant tells you which tags fired, DebugView tells you what arrived.

Method 2: The Google Analytics Debugger Chrome extension

Install the Google Analytics Debugger extension from the Chrome Web Store, click its icon so it shows ON, and reload your page. It adds the _dbg parameter to GA4 requests and also prints detailed hit information in the JavaScript console. Turn it off when you finish: while it is on, every GA4 site you visit sees you as a debug device, which is why popular analytics blogs see dozens of strangers in their Debug Device list.

Method 3: The debug_mode parameter

Add debug_mode to the Google tag to flag every event, or to one event to flag only that one. With gtag.js:

// Every event on the page
gtag('config', 'G-XXXXXXXXXX', { 'debug_mode': true });

// One event only
gtag('event', 'generate_lead', { 'debug_mode': true });

In Google Tag Manager, add a parameter named debug_mode with the value true to your Google tag (all events) or to a single Google Analytics: GA4 Event tag (that event only).

Enable DebugView for Android and iOS apps

Apps normally batch events and upload them periodically to save battery and data, so they need debug mode to send events right away. On Android, with the device connected:

adb shell setprop debug.firebase.analytics.app com.yourcompany.yourapp

# turn it off again
adb shell setprop debug.firebase.analytics.app .none.

The setting persists until you turn it off, even across disconnects. On iOS, edit the scheme in Xcode and add -FIRDebugEnabled under Arguments Passed On Launch; -FIRDebugDisabled turns it off. The launch argument only applies when you run from Xcode, so TestFlight builds will not show in DebugView unless you build an in-app way to enable debug mode. App events appear in the same DebugView in GA4 and in the Firebase console, where error events and the firebase_error parameter help explain rejected events.

Server-side GTM and the Measurement Protocol

With server-side tagging, the browser sends GA4 hits to your own endpoint (for example a subdomain of your site). The Debugger extension only recognizes requests to Google’s domains, so it does not add the flag. Use GTM Preview or a temporary debug_mode parameter instead, and confirm in the server container’s Preview that the outgoing request to GA4 still carries _dbg. If the server tag strips it, DebugView stays empty even though reports fill up.

Events you send from your backend with the Measurement Protocol (offline purchases, CRM lead stages, refunds) need the flag inside the event’s params: "debug_mode": true plus engagement_time_msec set to a positive number. Do not confuse this with the validation server at /debug/mp/collect: it checks that your payload is structured correctly and returns validation messages, but those events never reach your property, and it does not check your API secret. Validate first, then send a flagged event to the real endpoint and watch it in DebugView.

Reading the DebugView Screen

The report has five parts, as laid out in Google’s DebugView documentation:

• Debug Device (top left). A dropdown of every device currently in debug mode. Pick yours. If teammates or extension users are also debugging, their events stay out of your stream. Web devices often have generic names, so match by the events you just triggered.
• Minutes stream (left). One circle per minute for the last 30 minutes, with the event count inside. Click a circle to load that minute into the middle column.
• Seconds stream (middle). Events from the last 60 seconds, newest at the top. Click an event to see its parameters, then a parameter to see its value. Purchase and other ecommerce events also show an Items tab. Click the white background to pause the stream when it moves too fast.
• Top Events (right). Event counts for the 30-minute window. Click one to see each time it fired and the values its parameters carried. An event firing far more often than you clicked points to a duplicate tag or a trigger loop.
• User Properties (bottom right). The current user properties for the selected device; the clock icon shows how they changed during the window.

Icon colors carry meaning. Blue icons are ordinary events, green icons with a flag are events marked as key events (formerly conversions), orange icons are user property changes, and an orange bug icon marks error events. The data keeps arriving while DebugView is closed, so you can trigger events first and look later, as long as you stay within the 30-minute window.

How to Use GA4 DebugView, Step by Step

Clicking around and watching events scroll past proves very little. This six-step routine turns a debug session into a test.

1. Write down what you expect. For each action (load a landing page, submit the demo form, click the phone number, buy), note the event name, the parameters and their values. The test sheet below is a template.
2. Turn on debug mode for your browser only. GTM Preview or the extension. Avoid a production debug_mode change.
3. Open DebugView and pick your device. Admin, Data display, DebugView. Open the Debug Device dropdown even if it shows 0.
4. Do one action at a time and inspect the event. Trigger one action, wait for it in the Seconds stream, click it and compare each parameter with your notes. Then move to the next action.
5. Check the conversion details. Key events should show the green icon. value and currency must both be there. Purchases need transaction_id and an items array where each item has item_id or item_name.
6. Turn debug mode off and confirm in reports. Close Preview or switch off the extension, check Realtime, and come back the next day to see the events in standard reports.

Verify the Conversion Value, Not Just the Event

DebugView proves an event arrived. It does not tell you the event is valid. An ecommerce purchase missing both item_id and item_name looks almost identical in the stream to a correct one, green key event flag included. The same goes for value: a lead that arrives without a usable value is a conversion you can count but cannot price.

Google’s recommended events reference sets the rules. For generate_lead and purchase, currency is required if you set value, in 3-letter ISO 4217 format, for revenue metrics to be computed accurately. For purchase, transaction_id, value, currency and items are required, and each item needs item_id or item_name. Check these in DebugView on every key event:

• The event shows the green key event icon. If a purchase or lead is blue, it fires but is not marked as a key event in Admin.
• value is a number that matches what you assigned to that action, not a string with a currency symbol in it.
• currency is present and is a valid code such as USD.
• On purchases, the Items tab exists and lists the products, and transaction_id changes between test orders.
• The next page_view after a purchase does not carry leftover ecommerce data. If it does, push { ecommerce: null } to the dataLayer before each ecommerce event.

Copyable test sheet

Fill in the first three columns before the session, the last two during it:

Check the Landing Page and Source the Conversion Will Get

The question most teams actually care about is not “did the event fire” but “will this conversion be credited to the right page and channel.” DebugView only partly answers it. Google notes that, like Realtime, it does limited attribution, so do not read source and medium from it. What you can check is the raw material attribution is built from:

• page_location on the first page_view: the full landing page URL, including any UTM parameters. If your UTMs or gclid disappear here, a redirect or a consent tool is stripping them.
• page_referrer on that same event: for an organic visit it should be the search engine; for a visit from an AI assistant it should be the assistant’s domain when the assistant passes one. An empty referrer here means the session will most likely land in Direct.
• page_location on the key event itself: tells you which page the form or checkout lived on, which is not always the landing page.

For a true end-to-end test, do one run without debug mode. If a developer traffic filter is Active, your debug session is excluded from reports by design, so it can never prove attribution. If an internal traffic filter excludes your office IP, test from a phone on mobile data. Search for your own page, click the result, convert, then check the landing page and traffic acquisition reports the next day. Our guide to organic conversion attribution explains how to read conversions by landing page once the data is in, and the SEO conversion tracking guide covers the full setup. If you would rather not re-run this test after every release, SEOConversion autocaptures form submits, tel and mailto clicks and ecommerce events with one script and reports conversions and value by organic and AI landing page.

GA4 DebugView Not Working: Diagnose It Layer by Layer

“No devices available” has many causes, but they sit at different points between your click and the report. Check the layers in order and stop at the first one that fails:

Details on the causes that trip people up most:

• Internal traffic filter. An Active internal traffic filter removes your hits before DebugView can show them, even if a developer traffic filter is also active. Switch it to Testing while you debug, or test from another network. Filter changes are not instant, so allow time before retesting.
• Blockers and privacy browsers. uBlock Origin, Ghostery, opt-out extensions and Brave block GA4 and sometimes GTM. Test in a clean Chrome profile with extensions off.
• Consent. If you declined the cookie banner, or a consent tool auto-blocks scripts, GA4 either never fires or sends limited pings that DebugView does not show. Accept analytics consent in your test session.
• Content Security Policy. The console shows a CSP error naming google-analytics.com. Your developers need to allow *.google-analytics.com and *.analytics.google.com in connect-src and img-src, since GA4 sends to regional subdomains.
• Logged into WordPress. Several site owners report that DebugView stays empty while they are logged into wp-admin, often because a plugin skips tracking for logged-in users. Log out or use a private window.
• Delays and interface bugs. Events sometimes arrive minutes late, and brand-new properties have been slow to show anything. Restarting the browser, signing out of Google Analytics and back in, or waiting until the next day have all fixed cases that no setting explained.

Events Show in DebugView but Not in Your Reports

The opposite problem is just as common: purchases appear in DebugView and Realtime, yet standard reports stay empty days later. Since DebugView proves GA4 received the data, look at what happens after collection:

• Your developer traffic filter is doing its job. When it is Active, debug events are excluded from reports permanently. A test run done entirely in debug mode will never show up. Repeat the test without debug mode.
• Custom parameters are not registered. DebugView shows every parameter you send, but reports only show custom ones after you create a custom dimension or metric for them in Admin, and only for data collected after that point.
• The event is incomplete. A purchase without currency, or with items lacking both item_id and item_name, arrives but does not populate ecommerce and revenue reports as expected.
• Not marked as a key event. The event appears in Events reports but not as a key event until you mark it in Admin.
• Processing lag. Realtime and DebugView are near instant; standard reports and Explorations are not. Judge them the next day, not the next hour.

Keep Debug Traffic Out of Your Reports

Every test session adds fake page views, leads and purchases. A developer traffic filter removes events sent in debug mode from reports while leaving them visible in DebugView. Per Google’s Filter out developer traffic instructions:

1. Go to Admin, Data filters, and click Create filter.
2. Choose Developer traffic, name the filter and keep the operation as Exclude.
3. Pick a state: Testing, Active or Inactive.

Start in Testing: matching data stays in reports, labeled with the Test data filter name dimension, so you can confirm the filter catches only what you expect. Active excludes matching data permanently; excluded data is never processed and cannot be recovered. Google says a filter can take 24 to 36 hours to apply, so do not judge it the same afternoon.

Where the Top Guides Disagree

• “The Developer Traffic filter exists by default.” One widely read guide says so. Google’s own steps create it through Create filter, Developer traffic. Check Admin, Data filters: if you do not see a developer traffic filter, you do not have one, whatever the guide says.
• What the timestamp means. Google’s documentation says each event’s timestamp is the time it was logged on the device. One guide says it is when GA4 received it. We could not settle it from a primary source beyond Google’s statement, so do not use DebugView timestamps to measure latency or event order across devices.
• Whether an internal traffic filter blocks DebugView. Google’s filter documentation does not mention DebugView. Practitioners consistently report that an Active internal traffic filter empties it, which fits Google’s statement that excluded data is never processed. Treat it as the first filter to check.

How to Use GTM Preview Mode, and Why It Sometimes Fails

Preview mode lets you browse your site as if the current GTM workspace were published. In tagmanager.google.com open the container, click Preview, enter the URL, click Connect, then return to the Tag Assistant tab and click Continue. Each click or page load appears on the left; select one to see which tags fired, which did not and why, and the values of your variables and dataLayer.

When Preview will not connect or shows no tags, check these first:

• The site loads the same container ID you are previewing, and the snippet is on the page you entered.
• Blockers, privacy extensions and Brave Shields are off; they can block the GTM script itself.
• The preview runs only in the browser that started it. A colleague on another machine needs the share link from Tag Assistant’s More actions menu.
• If the added debug parameter breaks your page or redirects, uncheck “Include debug signal in the URL” when you connect.

Once Preview shows the GA4 tag firing, DebugView should light up for the same browser. If it does not, you are at layer 2 or later in the table above. For AI assistant traffic specifically, our guide to AI conversion tracking explains why some of those visits arrive with no referrer at all, which no debugger can fix.

Frequently Asked Questions