GA4 DebugView: How to Turn On Debug Mode and Test Events

GA4 DebugView is a report inside Google Analytics 4 that shows, event by event, what a single device in debug mode is sending to your property, so you can check tracking before it reaches real reports. You open it from Admin, under Data display, and it only shows devices where debug mode is switched on through Tag Assistant, Google Tag Manager preview, or the debug_mode parameter.

This guide explains where DebugView lives, the ways to turn debug mode on, why the report is sometimes empty, how to check events, parameters and user properties before you publish, whether debug traffic ends up in your standard reports, and how DebugView compares with the Realtime report and GTM Preview. Google moves menu items now and then, so the paths below follow Google's current help documentation and may look slightly different in your property.

What is DebugView in GA4 and where is it?

DebugView is a live, per-device stream of the events GA4 receives from a browser or app that has debug mode enabled. Google's help page places it under Admin, then Data display, then DebugView. It does not show all users. It shows only devices flagged for debugging, which is what makes it useful: you can follow your own test session without the noise of everyone else on the site.

The report has a few parts, as Google describes them:

• Seconds stream: the events logged in the last 60 seconds, so you see an event appear seconds after you trigger it.
• Minutes stream: one circle per minute for the last 30 minutes, each showing that minute's event count. Clicking a circle loads that minute's events into the seconds stream.
• Top events: the events logged most often during the 30-minute period.
• Current user properties: the latest user property values for the selected device.
• Debug device selector: in the upper left, labelled DEBUG DEVICE. If several devices are in debug mode, such as a colleague testing at the same time, you choose one here.

Clicking an individual event opens its parameters, which is where most of the real checking happens.

How do you turn on debug mode?

Google's documentation lists two groups of methods: ones that put only your own device into debug mode, and ones that turn it on in the tag configuration itself.

Your own device: Tag Assistant or Tag Manager preview

The quickest route is Google Tag Assistant at tagassistant.google.com, or the Preview button in Google Tag Manager, which opens Tag Assistant. When you connect your site, Tag Assistant adds a parameter to the page URL, and GA4 treats hits from that session as debug traffic. This is the safest option for everyday testing, because nothing changes in the live tag and only your browser session is affected.

The debug_mode parameter in gtag.js

If you tag the site with gtag.js, Google's help says to add debug_mode: true to the config command to monitor all events, or to individual event commands to monitor only those events. This is useful on a staging site or for a short test, but anything you add to the config applies to every visitor who loads that code, so it should not stay on a production site.

The debug_mode parameter in Google Tag Manager

In GTM, Google's help says to set debug_mode to true in the Google tag for all events, or in a Google Analytics: GA4 Event tag for specific events. Again, this affects everyone who triggers that tag once the container is published, so it belongs in a test workspace or a staging environment.

Turning it off

Google points out a detail that catches people: to disable debug mode you remove the debug_mode parameter. Setting it to false does not turn debug mode off. If a site keeps sending debug traffic after someone "switched it off", this is the first thing to check.

Apps and the Chrome extension

For Android and iOS apps, Google sends you to the Firebase documentation, since app debug mode is enabled through the Firebase SDK rather than through a web tag. You may also come across the Google Analytics Debugger extension for Chrome in older guides. It is a browser-side way to flag your session, but Google's current DebugView help page lists Tag Assistant, GTM preview and debug_mode as the methods, so those are the ones to rely on.

Why is DebugView empty or showing no devices?

An empty DebugView usually has a simple cause. Work through these in order:

1. Debug mode is not actually on. Check that Tag Assistant shows a connected session, or that the debug_mode parameter is present in the tag that fired.
2. You are looking at the wrong property. The measurement ID in the tag has to match the property where you opened DebugView. A site with several properties, or a staging property, is easy to mix up.
3. Consent has not been given. Google's help notes that events will not appear if you use consent mode and the user has not consented to Analytics cookies. When testing, accept analytics cookies in your own banner first.
4. Client-side privacy controls. Google states that events are not visible in debug mode if you have implemented privacy controls on the client side.
5. The wrong device is selected. If more than one device is in debug mode, use the DEBUG DEVICE selector to pick yours.
6. A browser extension blocks the request. Ad and tracking blockers can stop the GA4 request from leaving the browser, so test in a clean browser profile.
7. You looked too early. Give the stream a short time after the first event, then trigger another action on the page.

If Tag Assistant shows the GA4 tag firing but DebugView still shows nothing, the consent and privacy-control points above are the most likely explanation, since the tag can fire and still be prevented from sending the event.

How do you verify events, parameters and user properties before publishing?

The point of DebugView is to catch tracking problems before they turn into months of wrong data. A practical test run for a new event or a GTM change looks like this:

1. Make the change in a GTM workspace without publishing, then click Preview to start a Tag Assistant session on your site.
2. Open DebugView in a second tab and select your device.
3. Perform the action you want to track, for example submitting a form or adding a product to the cart.
4. Find the event in the seconds stream and click it. Check that the event name is spelled exactly as planned, since GA4 event names are case sensitive.
5. Open the parameters and check each value: the right page, the right item IDs, a value and currency on ecommerce events, and no empty or "undefined" values.
6. Check the Current user properties panel if your setup sets user properties, such as a customer type or logged-in state.
7. If the event is a key event in GA4, confirm that it is flagged as one in the stream.
8. Repeat for edge cases: a failed form submission should not fire the success event, and a page reload should not send a second purchase.
9. Only then publish the GTM container, and check that debug_mode is not left on the live tag.

Hypothetical example: you add a generate_lead event to a contact form. In DebugView you see it fire, but the form_name parameter is empty because the trigger reads a field that does not exist on the thank-you page. Fixing that before publishing costs a few minutes. Discovering it in a monthly report means the parameter is missing for every lead in that period, because GA4 does not rewrite past data. The scenario is illustrative, not taken from a real account.

Does debug traffic count in standard reports?

Google's DebugView help page does not say that debug events are left out of standard reports. What it does say is that you should filter developer traffic so debug data does not affect report results. The tool for that is a data filter.

According to Google's help on developer traffic filters, you go to Admin, then Data collection and modification, then Data filters, click Create Filter and choose Developer Traffic. You need the Editor role on the property. A filter has three states:

• Testing: matching data is tagged rather than removed, and shows up in the "Test data filter name" dimension in reports and explorations, so you can check what the filter would catch.
• Active: the filter applies to incoming data, and the effect is permanent.
• Inactive: the filter is not evaluated.

Google also notes that a property can have up to 10 data filters, that filters do not change historical data, that excluded data is never processed and is not available in Google Analytics or BigQuery afterwards, and that a filter can take 24 to 36 hours to take effect. Because an active filter is permanent, run it in Testing first and confirm it catches only what you expect.

One more point from the DebugView help page: attribution in DebugView is limited, so use the Acquisition reports when you need accurate source and medium data.

DebugView vs Realtime report vs GTM Preview: what each is for

These three tools overlap, and each answers a different question.

In practice they are used in sequence. GTM Preview tells you whether the tag fired. DebugView tells you whether GA4 received the right event with the right parameters. Realtime tells you, after you publish, that real visitors are generating that event. Google's help on the Realtime report notes that it covers the last 30 minutes, while DebugView can show activity over longer periods for devices in debug mode.

What this means in the Thai market

Thai websites raise a few specific debugging points. Many sites run both Thai and English versions, sometimes under /th/ paths or separate subdomains, so test events on both language versions rather than assuming one setup covers both. Thai text in parameter values, such as page titles or product names, should be checked in DebugView to make sure it arrives as readable text and not as broken characters, because reports and audiences built on those values depend on it. Thailand's Personal Data Protection Act also makes consent banners common on Thai sites, which connects directly to the consent point above: if testers forget to accept analytics cookies, DebugView will look empty even when the tag is fine. Finally, many Thai businesses take leads through LINE or phone calls rather than forms, so plan and test the click events for those buttons, since they are often the main conversion.

GA4 DebugView FAQ

Where do I find DebugView in GA4?

Go to Admin, then under Data display click DebugView, according to Google's help documentation. It only shows devices that have debug mode enabled.

How do I turn off debug mode in GA4?

Remove the debug_mode parameter from your gtag.js or Google Tag Manager setup, because Google states that setting it to false does not disable debug mode. For Tag Assistant sessions, close the session.

Why does DebugView show no events when my tag is firing?

The most common reasons are consent mode without analytics consent, client-side privacy controls, the wrong property or device being selected, or a browser extension blocking the request. Google's help names consent and client-side privacy controls as reasons events will not appear.

Is debug traffic removed from GA4 reports automatically?

Google's DebugView help does not say so, and it recommends filtering developer traffic instead. Create a Developer Traffic data filter under Admin, Data collection and modification, Data filters, and test it before you activate it.

Should I use DebugView or GTM Preview?

Use both: GTM Preview shows whether a tag fired and why, while DebugView shows what GA4 actually received. Checking only one can miss problems in the other half of the setup.

Getting your GA4 tracking right

DebugView turns tracking from guesswork into something you can check line by line before it reaches your reports. If your property needs a cleaner event plan, a consent-aware setup or a full audit of what is being collected, the GA4 setup and migration service covers implementation and QA. Accurate GA4 events also feed the conversions used by Google Ads campaign management, and a technical SEO audit can include a review of how tracking and consent tags load on your pages.