Checking GA4 Tracking: DebugView, Tag Assistant and Realtime

Google's own guidance is to use two built-in reports for this. Its confirm that you're collecting data page says that "many of your reports and explorations can take 24-48 hours to process data," and points to the Realtime and DebugView reports to check sooner. Tag Assistant is the third tool. It shows what the tags on a page actually do. This guide uses Google Analytics Help, Tag Assistant Help and the Firebase documentation, checked on 7 November 2026.

Three tools, three jobs

• Tag Assistant runs in your own browser. It shows which Google tags load on a page, which events they send and what data goes with them.
• DebugView is a report inside GA4. It shows the events GA4 receives from one device that has debug mode turned on, with every parameter, a few seconds after they happen.
• Realtime is a GA4 report too, but it covers everyone on the site or app in the last 30 minutes, not only your test device.

Google sums up the difference in a table on the same page. Realtime "displays user activity during the past 30 minutes" and anyone with access to the property can view it. DebugView is "usually used by web or app developers" and lets you pick one device with the Debug Device menu. In practice you use Tag Assistant to see that the tag works, DebugView to see that each event and parameter arrives correctly, and Realtime as a quick check that real visits are coming in.

If you use Google Tag Manager, its preview mode opens the same Tag Assistant window. Our Google Tag Manager guide covers preview and publishing, so this page does not repeat it.

Tag Assistant: is the tag firing?

Google's Tag Assistant help page calls it "a troubleshooting tool that helps you verify the implementation and functionality of tags on your website." To connect it:

1. Open Google Tag Assistant at tagassistant.google.com.
2. Click Add domain.
3. Enter the page address, starting with https:// or http://.
4. Click Connect. Your site opens in a new window with a debug session attached.

As you click through the site, Tag Assistant lists the tags it finds and the events they send. Google notes that "debug information is not visible to your regular website visitors." When you connect, Tag Assistant adds a debug parameter (_dbg) to the address, and Google says this parameter "helps you view events in other debugging surfaces, such as Google Analytics' DebugView." So connecting Tag Assistant is also the simplest way to put your own browser into debug mode.

Google recommends installing the Tag Assistant Chrome extension. It adds features such as finding a Google tag inside an iframe and following pop-ups or new tabs opened from the page.

If the debug window will not connect, Google lists these causes, among others:

• The page you entered does not have the Google tag on it.
• The debug parameter changes how the page behaves. You can untick Include debug signal in the URL for that domain.
• The tag loads after Tag Assistant tries to connect. Click Retry.
• The page is an AMP page, which Tag Assistant does not support.
• Several redirects stop the debug window from loading.
• An ad blocker or a consent tool blocks the Google tag. Turn off the blocker for the pages you test, and set up your consent tool to work with Google's consent API.

Turning on debug mode

DebugView only shows events sent with debug mode on. Google's DebugView help page gives two choices for websites, and advises that "when troubleshooting your tag installation, it's best to enable debug mode for your personal device."

For your own browser

Use Tag Assistant or Tag Manager preview mode. Nothing on the site changes.

For every visitor (code)

With the Google tag (gtag.js), add a debug_mode parameter. On the config command it applies to all events on the page:

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

On a single event it applies only to that event: gtag('event', 'xyz', { 'debug_mode':true });. In Tag Manager you set debug_mode to true in the Google tag (all events) or in one Google Analytics event tag. Events sent from a server work too: our GA4 Measurement Protocol guide shows the parameters Google asks for.

Be careful with this option. Google says that to turn debug mode off you must remove the parameter: "setting the parameter to false doesn't disable debug mode." A debug_mode line left in the live site keeps every visit in debug mode.

For mobile apps (Firebase)

The Firebase DebugView documentation explains why apps need this. Normally "events logged by your app are batched together over the period of approximately one hour and uploaded together." Debug mode uploads them "with a minimal delay" from your test device:

• iOS: add the launch argument -FIRDebugEnabled in your Xcode scheme. It stays on until you pass -FIRDebugDisabled.
• Android: run adb shell setprop debug.firebase.analytics.app PACKAGE_NAME. It stays on until you run adb shell setprop debug.firebase.analytics.app .none.

Our mobile app analytics guide covers what to measure in an app in the first place.

Reading DebugView

In GA4, go to Admin, then under Data display click DebugView. Use your site or app and the events appear as they are triggered. The report has three columns, as Google describes them:

• Seconds stream (middle): events logged in the last 60 seconds, newest at the top. Click an event to see its parameters.
• Minutes stream (left): one circle for each of the last 30 minutes, with the number of events received in that minute. Click a circle to load that minute into the Seconds stream.
• Top Events and Current User Properties (right): the most frequent events in the 30-minute period and the latest user property values for the selected device.

If several people are testing, pick your own device from the Debug Device menu at the top left. Google says this lets "multiple developers focus on their own instrumentation and validation efforts without impacting one another."

What to check: the event name is spelled exactly as planned, each parameter is there with a sensible value (a form name, a price, a currency code), events fire once and not twice, and key events such as a form submission appear when the action really completes. For apps, the Firebase page adds that error events, and events with a firebase_error parameter, also appear here. For the error parameter you need to click the event, because there is no special marker in the stream.

Two limits to keep in mind:

• Consent. Google states that "events are not visible in debug mode if you have implemented privacy controls on the client-side, or if you've implemented consent mode and users have not given consent for Analytics cookies." If your cookie banner is set to deny by default, accept analytics cookies in your test browser first. Our cookie consent guide explains how consent mode works.
• Attribution. DebugView, like Realtime, "performs limited attribution analysis to ensure responsive reporting." Do not judge where traffic came from here. Google recommends the Acquisition reports for that.

The Realtime report

Open Reports, then Realtime. Google's Realtime report page lists its cards, including active users in the last 5 and 30 minutes, active users by first user source, views by page title or screen name, event count by event name and key events by event name. View user snapshot shows the data for a single user.

Realtime is useful to confirm that tracking works for everyone, for example straight after a site launch, and to watch the effect of a campaign or post on the day. A few points from Google's page explain numbers that look odd:

• New users, and returning users not yet processed, are left out of the Active users count.
• The Active users by First user source card only shows users who have already been through normal processing, so brand-new visitors are missing from it.
• Cards may group rows into (other) and show at most 700 rows on desktop.
• App data is batched, so it can arrive a few minutes late.
• Google calls Realtime "a best effort service": short delays can happen.
• An empty report may simply mean "there are no active users."

If you cannot find Realtime in the menu, Google notes that it may have been removed from your default navigation. Editors can add it back.

When no data shows up

Google's troubleshoot tag setup page names four reasons: the Google tag is not installed, it is installed incorrectly, the site has had no traffic, or the data is not processed yet. The installation mistakes it lists:

• Snippet in the wrong place or missing from pages. The Google tag belongs right after the opening <head> tag, on every page. GA4 only collects data from pages that have it. For Tag Manager, the first snippet goes as high in the head as possible and the second right after the opening <body> tag.
• Wrong ID. The Measurement ID under Admin, Data Streams, your web stream, Stream details must match the ID in your tag. Check that you are in the right account and property.
• Extra spaces or changed quotes. Copy the snippet straight from Analytics into a code editor, not through a word processor.
• Tag Manager not finished. The Google tag needs a trigger (usually page load), and the changes must be published. Google says unpublished changes mean "you won't see data in Google Analytics."
• Both the Google tag and Tag Manager installed. Use one or the other. Google warns that both together can cause overcounting.

On timing, the same page says that after a first install you may need to "wait up to 24 hours" before data appears even in Realtime. For a site that is already live, click around and wait about a minute. On small sites, standard reports may also apply thresholds that hide some rows to protect user identity.

Debug traffic and your reports

Test events sent in debug mode are normal data unless you filter them. The Firebase page notes that debug events "are included in your daily BigQuery export by default" if you have the BigQuery export turned on. Google's filter out developer traffic page explains the fix: a developer traffic data filter keeps debug-mode activity out of your reports "so developers can continue to use DebugView to troubleshoot issues."

Setting up that filter, and the separate filter for office or staff IP addresses, is covered step by step in our GA4 internal traffic guide. One point to keep in mind: an active Exclude filter removes data for good, so test it in Testing state first.

A test routine after every change

1. Write down which events and parameters the change should send.
2. Accept analytics cookies in a test browser, or your events will not show.
3. Connect Tag Assistant (or Tag Manager preview) to the page.
4. Do the action: submit the form, click the phone link, add to cart.
5. In Tag Assistant, check that the right tag fired once.
6. In DebugView, choose your device and check the event name and each parameter.
7. After publishing, check Realtime for events from real visitors.
8. A day or two later, check that the event appears in the standard reports and, if it is a key event, in Google Ads.
9. Remove any debug_mode code you added for testing.

New to GA4? Start with our GA4 basics guide, then come back here to test your setup.

Frequently asked questions

Why is GA4 DebugView not showing any events?

Debug mode is probably not on for your device, or consent is blocking Analytics. Connect Tag Assistant or Tag Manager preview to the page, accept analytics cookies in that browser, and pick your device in the Debug Device menu. Ad blockers can also stop the Google tag.

How do I turn on debug mode in GA4?

For your own browser, connect Google Tag Assistant or Tag Manager preview mode to the site. For every visitor, add debug_mode: true to the Google tag config or to single events. For apps, use -FIRDebugEnabled in Xcode or the adb setprop command on Android.

How do I turn debug mode off?

Remove the debug_mode parameter or field. Google says setting it to false does not disable debug mode.

What is the difference between DebugView and Realtime?

Realtime shows all users in the last 30 minutes and anyone with access can view it. DebugView shows the detailed events from devices in debug mode, one device at a time, and is mostly used by developers while setting up tracking.

How long does GA4 take to show data?

Google says many reports and explorations take 24 to 48 hours to process. Realtime and DebugView show data within seconds to minutes, although after a first install Google says it can take up to 24 hours before data appears even in Realtime.

Does debug traffic count in my reports?

Yes, unless you filter it. Debug events are normal data and are included in a BigQuery export. A developer traffic data filter keeps them out of reports while DebugView keeps working.

Want your GA4 events checked or set up properly? See our services or email [email protected].