How to Use the Google Analytics Debugger to Verify GA4 Events

A Google Analytics debugger is any tool that shows you the raw hits leaving your site and the events arriving in Google Analytics 4, in real time, so you can prove an event fired with the right parameters before you trust the reports. In practice that means three things used together: the GA4 DebugView report, the Google Analytics Debugger Chrome extension (or the debug_mode parameter it sets for you), and Google Tag Assistant. This guide walks through each one, shows how to enable debug traffic on gtag.js and Google Tag Manager, and lists the reasons events go missing.

Standard GA4 reports lag by hours and aggregate everything, which makes them useless for answering “did my purchase event actually send value and currency?” The debug workflow answers that question instantly for a single device, which is your device. Below is the order I follow on every new implementation: enable debug traffic, watch DebugView, confirm parameters, then check consent state and tag firing in Tag Assistant if something is absent.

Option 1: The Google Analytics Debugger Chrome extension

The extension is published by Google and does two things. It forces every gtag.js hit on the page to include debug_mode, which routes the hit into DebugView, and it prints a verbose log of each hit in the browser console. There is no configuration.

1. Open the Chrome Web Store, search for “Google Analytics Debugger” and add it. Confirm the publisher is Google before installing.
2. Click the extension icon in the toolbar. It shows “ON” when active. Reload the page you want to test.
3. Open DevTools with F12, switch to the Console tab, and filter for “gtag” or “collect”. Each hit is expanded into a readable block listing the measurement ID, event name and every parameter.
4. In GA4, go to Admin, then DebugView under Data display. Pick your device from the debug device selector at the top left. Events appear on a timeline in the center column.

Option 2: The debug_mode parameter without an extension

If you cannot install extensions (locked corporate Chrome, testing on Safari, a colleague who needs to reproduce something) you can pass debug_mode yourself. With gtag.js, set it in the config call or on an individual event:

<!-- Every event from this page goes to DebugView -->
gtag('config', 'G-XXXXXXXXXX', { 'debug_mode': true });

<!-- Or a single event only -->
gtag('event', 'newsletter_signup', {
  'method': 'footer_form',
  'debug_mode': true
});

Remove the flag before you ship. A stray debug_mode on every production pageview means DebugView fills with real users, which makes the tool useless for you. In Google Tag Manager the equivalent is a debug_mode row under Configuration settings on the Google tag, but since that applies to all visitors most people rely on Preview mode instead, which sends debug traffic for the previewing browser only.

Reading DebugView properly

DebugView has three columns: a minute by minute count on the left, the seconds stream in the center (pageviews in blue, other events in green, key events flagged, errors in red), and the current user properties on the right. Click any event to expand it. You get a Parameters tab and, for ecommerce events, an Items tab. What you are checking, in order:

• The event name matches what you expect, including case. Purchase and purchase are different events and only the lowercase one is a recommended event with built in reporting.
• Custom parameters are present with sensible values. A parameter that shows as undefined or {{DLV - order value}} means the GTM variable did not resolve.
• Automatically collected parameters like page_location, session_id and engagement_time_msec are there. If session_id is missing on a custom event, the event was sent before the config command ran.
• The event count per minute is not doubling. Two of every event usually means two GA4 tags or both gtag.js and GTM are installed, which our guide on tracking two websites with Google Analytics also covers from the cross domain angle.

Google Tag Assistant and GTM Preview

Tag Assistant (tagassistant.google.com) is the other half of the debugger toolkit. It attaches to your page through a debug session and shows the dataLayer, which tags fired on which triggers, and the exact values variables held at the moment a tag fired. It is the fastest way to find out why an event never left the browser at all, which DebugView cannot tell you because nothing arrived.

1. In GTM click Preview at the top right, enter your URL, and Connect. A new tab opens with a Tag Assistant badge in the corner.
2. In the Tag Assistant window, the left pane lists every dataLayer push as an event line: Container Loaded, DOM Ready, Window Loaded, then your custom events such as add_to_cart.
3. Click an event line, then the Tags tab. Tags are split into Tags Fired and Tags Not Fired. Click a tag that did not fire and scroll to the trigger section: green checks and red crosses show which condition failed.
4. Switch to the Variables tab to see what each variable evaluated to at that moment, and the Data Layer tab for the raw object.

If you installed analytics through a plugin, for example following our walkthrough on adding Google Analytics to WordPress, Tag Assistant is where you discover that the plugin and your theme both inject a tag.

gtag.js versus GTM: where to look for each problem

Debugging consent mode

Since consent mode v2 became the default for EU traffic, the most common “event missing” cause on new sites is consent, not code. When analytics_storage is denied, gtag either sends cookieless pings (if url_passthrough and modeling are set up) or, in basic mode, sends nothing. DebugView shows nothing either way for your browser until you accept the banner.

In Tag Assistant, click any event and open the Consent tab. It lists each consent type with its default and update state. A tag stuck on “Not fired” with a note about consent requirements is waiting for a signal that never came. Check the order in the Data Layer tab: the consent default push must be the first thing in the container, and the update must arrive after the user clicks accept.

// Must run before any config or event
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});

// After the visitor accepts
gtag('consent', 'update', { 'analytics_storage': 'granted' });

Google documents the full consent mode behavior on the Tag Platform consent guide. Read the section on the difference between basic and advanced implementation before you decide whether missing events are expected.

Verifying a custom event end to end

Here is the sequence for a custom event such as a lead form submission, the kind of setup described in our guides on setting up events in Google Analytics and tracking a custom event.

1. Push the event to the dataLayer with the parameters you want, using a plain object with a distinct event name.
2. In Tag Assistant confirm the push appears and your GA4 Event tag is under Tags Fired.
3. In DebugView confirm the event arrives with the same parameters and that session_id is present.
4. In Admin, Custom definitions, create a custom dimension with the exact parameter name. In Admin, Key events, mark the event if it is a conversion.
5. Wait a day, then confirm in Explore that the dimension populates. If it does not, the parameter name in step 4 does not match the one you saw in step 3.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'generate_lead',
  form_id: 'contact_footer',
  lead_type: 'quote_request',
  value: 50,
  currency: 'USD'
});

Troubleshooting

The debug device selector is empty. Either the extension is off, the page is served from a domain the tag does not run on (a staging domain blocked by a hostname trigger), or an ad blocker is dropping requests to google-analytics.com. Open the Network tab, filter on “collect”, and look for requests. No requests means the tag never sent; a request with status blocked means an extension is interfering. Test in an incognito window with only the debugger extension enabled.

Events show in the console log but not in DebugView. Check the measurement ID in the log against the property you have open. Agencies and multi brand sites often have several G IDs and the event is landing in a sibling property. Also check that the hit contains _dbg=1 in its query string; if it does not, debug_mode is not being applied.

Parameters appear as the literal variable name. A value like {{DLV - value}} or [object Object] means GTM did not resolve the variable, usually because the dataLayer key is nested and the variable uses the wrong path, or because the tag fires on a trigger that occurs before the push.

Everything works in Preview but not after publishing. The container version was never published, or a workspace with the change is different from the one you published. Check Versions in GTM and compare with the container ID loaded on the live page.

Frequently asked questions

Does the Google Analytics Debugger extension work with GA4?

Yes. The current version of the extension sets debug_mode on gtag.js hits so they appear in GA4 DebugView, and it logs each hit to the console. It also still handles the older Universal Analytics library on sites that have not migrated, but those hits go nowhere since UA stopped processing data.

Is there a DebugView on mobile apps?

Yes, the same DebugView report works for Firebase SDK traffic. On Android you enable it with an adb command, adb shell setprop debug.firebase.analytics.app your.package.name, and on iOS you add the -FIRDebugEnabled launch argument in Xcode. Events from the device then stream into the report exactly as web events do.

Why does DebugView show an event but the standard report does not?

Standard reports are processed on a delay that can reach 24 to 48 hours, and custom parameters only appear once you register them as custom dimensions. DebugView reads the raw stream before processing. If the event is still missing after two days, check for data filters, event modifications or a key event definition that renamed it.

Can I use Tag Assistant without Google Tag Manager?

Yes. Go to tagassistant.google.com, add your site URL, and it connects to any page running gtag.js. You see which Google tags loaded, which measurement IDs they send to, and the hits generated. You lose the trigger and variable views because those only exist for GTM containers.

Does debug traffic count in my reports?

It does. Events sent with debug_mode are stored like any other event and show up in Realtime and standard reports. If you send test purchases regularly, use a separate test property, define an internal traffic filter for your IP, or use the traffic_type parameter with a data filter set to exclude.

The bottom line

Treat the three tools as layers. Tag Assistant proves the tag fired and shows the values it had. The Google Analytics Debugger extension, or a manual debug_mode, proves the hit left the browser with those values. DebugView proves Google received it and parsed the parameters. Any missing event can be located to one of those layers in a couple of minutes once you know which report to open.

Do this check every time you add or edit a tag, before you publish, and keep the extension off when you are not testing. Most GA4 data quality problems that take weeks to spot in reports would have been visible in DebugView in the first ten seconds.

About this article: GeekBlog covers U.S. technology news, AI, phones, smartwatches and gaming. Every story is written and checked under our Editorial Policy. Spotted a mistake or have a story tip? Contact our editors.