How to Debug GA4 Events: DebugView and Tag Assistant.

GA4 events go missing in silence. There is no error message, no alert, no red badge in the interface. You set up a purchase event, you deploy the tag, and nothing shows up in reports. Or it shows up but the parameters are wrong. Or it fires three times per transaction instead of once. The product does not tell you which of those things happened — you have to go find out.

Two tools exist for exactly this: GA4 DebugView and Google Tag Assistant. DebugView is built into GA4 itself and shows you events arriving in real time. Tag Assistant is a Chrome extension that intercepts the raw network request before it reaches Google and shows you the full payload — event name, parameters, consent state — as it left the browser. Together they cover the complete debug stack: Tag Assistant tells you what fired, DebugView tells you what arrived. When those two pictures disagree, the gap between them is your bug.

GA4 DebugView

How to enable DebugView

DebugView activates when GA4 sees the debug_mode signal on incoming events. There are two ways to send it.

The first is via GTM. Add the query parameter ?gtm_debug=x to any URL on your site. This opens the GTM Preview panel and simultaneously activates DebugView for all events fired during that session. Any parameter value works — the presence of the key is what matters. This is the most practical method when your GA4 tag lives in GTM, because you get both debuggers open at the same time.

The second is via gtag directly. Add this call anywhere in your page before GA4 fires events:

gtag('set', {'debug_mode': true});

This is the method for sites using the gtag snippet directly without GTM. Remove it before deploying to production — debug_mode: true events appear in DebugView but are excluded from standard reports, so a production page with this flag set will produce invisible event data.

The third method handles both automatically: the GA4 Debugger Chrome extension (available in the Chrome Web Store) adds debug_mode to every event fired from your browser session and opens DebugView in the GA4 interface. If you debug GA4 regularly, this is the lowest-friction option.

Reading the DebugView timeline

DebugView shows a horizontal timeline. Each dot on the timeline represents one event. The dots appear in real time as events arrive — there is no page refresh required, and there is no processing delay. When an event fires in the browser, it appears in DebugView within a few seconds.

Click any event on the timeline and the right panel populates with its full payload: every parameter that arrived, its value, and whether it was recognized by GA4. The left panel shows the sequence — the order of events from the start of the session, which tells you whether a page_view fired before your custom events, or whether your add_to_cart came through before the required view_item.

Events marked with a star are key events — events you have marked as conversions in your GA4 configuration. This is a useful sanity check: if your purchase event appears in DebugView without a star, it means the event is arriving but has not been marked as a key event in your GA4 property settings.

What DebugView catches and what it misses

DebugView shows you everything GA4 received. That makes it reliable for a specific set of problems: events that are not firing at all (they simply do not appear on the timeline), events with wrong names (you see the actual name GA4 received, not what you intended to send), parameters that arrived empty or with the wrong value, and events that were blocked by consent settings (these appear greyed out in the timeline rather than missing entirely — GA4 received a ping but the event was not recorded because analytics storage was denied).

What DebugView does not do: it does not replace standard reports, and the absence of an event in standard reports is not a signal that DebugView can help with. DebugView is real-time. Standard reports process with a 24–72 hour delay and apply additional logic — data filters, attribution modeling, thresholding. An event that appears correctly in DebugView may still be absent from a standard report for 48 hours, may be filtered by an active data filter, or may be suppressed by Google Signals thresholding. DebugView also does not show you attribution — it shows you that an event arrived, not how GA4 will credit it.

Filtering DebugView to your device

At the top of DebugView there is a device selector dropdown. When multiple people on your team have debug sessions open simultaneously — which happens constantly in agency and in-house analytics teams — DebugView shows all of their events interleaved on the same timeline. The dropdown lets you filter to a specific device session so you are only seeing your own events.

Your device appears in the list by its client ID or device identifier. If the timeline looks chaotic — events firing rapidly and seemingly at random — switching to your specific device in the dropdown is the first thing to do. This is not a bug; it is DebugView behaving correctly by showing all active debug sessions.

Google Tag Assistant

What Tag Assistant does differently

DebugView shows you what GA4 received. Tag Assistant shows you what left the browser. These are not the same thing, and the difference matters for a specific class of bug.

Every GA4 event is sent as an HTTP request to https://www.google-analytics.com/g/collect. The request carries all the event parameters as URL-encoded query string values. Tag Assistant intercepts that request, decodes it, and presents it as a structured table before Google's servers process it. This means you can see exactly what parameters were included — and crucially, whether their values were populated at the moment the tag fired.

This is where Tag Assistant's advantage over DebugView becomes concrete. DebugView can show you that a parameter arrived as empty. Tag Assistant can show you that the parameter was empty because the data layer variable had not been pushed yet when the tag fired — because the sequence of the GTM preview shows the tag firing on gtm.click before the dataLayer.push that should have populated the value. The gap between what fired and what arrived is where timing bugs and consent blocking live.

Installing and using Tag Assistant

Install the Google Tag Assistant Companion extension from the Chrome Web Store. Once installed, navigate to your site and click the Tag Assistant icon in your browser toolbar. Click Start Debugging, then click Connect. Tag Assistant opens a new tab with the recording interface — this recording tab is where you will do your inspection.

Go back to your original browser tab and trigger the event you want to test: click the button, submit the form, complete the purchase. Then switch to the Tag Assistant recording tab. In the left panel, you will see every page and event in your session. Click into a specific event to see the tags that fired and their full payloads in the right panel.

The Tags panel is where the useful information lives. Each tag that fired is listed with its tag name from GTM and a summary of its status. Click a tag to expand it and see the complete event payload as it was sent to Google.

Reading the event payload in Tag Assistant

The payload table in Tag Assistant decodes the raw query string parameters from the network request. A few parameters are worth knowing by name.

en is the event name. This is what GA4 will record — not what your GTM tag is named, but the literal value of the event name field. If this says Purchase (title case) instead of purchase (lowercase), GA4 will record a different event than your key event definition expects.

tid is the measurement ID. This must match the property you are auditing. A mismatch here means the event is being sent to a different GA4 property entirely — it will not appear in DebugView for the property you are looking at.

Event parameters are prefixed with ep. — for example, ep.transaction_id or ep.currency. User properties are prefixed with up.. If a parameter you expected to be populated shows up as empty or absent in Tag Assistant, the issue is upstream of GA4 — the data layer did not have the value when the tag fired.

The gcs parameter shows the consent state at the moment the hit was sent. G111 means both analytics_storage and ad_storage were granted.

Debugging consent mode with Tag Assistant

Consent Mode debugging is one of Tag Assistant's most practical uses. When a user has not accepted analytics cookies, GA4 still receives a hit — it fires as a cookieless ping that contributes to modeled conversions. This is correct behavior, but it looks like a bug if you are not expecting it.

In Tag Assistant, you can trigger the same event before and after accepting the consent banner and compare the gcs parameter between the two hits. Before consent: gcs=G100 — analytics storage denied, ad storage denied. After consent: gcs=G111 — both granted. If you see gcs=G111 before consent, your consent mode implementation is not default-denying correctly.

In DebugView, consent-denied events appear greyed out. This is the same signal from the GA4 side: the event arrived but was recorded as a cookieless ping. Both views together confirm that consent mode is behaving correctly end-to-end.

A Practical Debug Workflow

The most efficient approach is to run both tools simultaneously and work from the browser outward. Here is the sequence that covers most GA4 debugging scenarios.

1. Open Tag Assistant on your site and start a recording session. In a separate window or tab, open GA4 and navigate to Configure → DebugView. Both should be visible without switching tabs, if possible.
2. Trigger the action you want to test. Click the button, complete the form, add the product to the cart. For purchase events, use a test transaction if your environment supports it — or use a staging environment where transactions are free.
3. Check Tag Assistant first. Did the request fire? What is the event name in en? Does the measurement ID in tid match your GA4 property? Are the expected parameters populated under ep.*? This step isolates whether the problem is in the tag configuration or downstream.
4. Check DebugView. Did the event arrive? Does the parameter set in DebugView match what Tag Assistant showed? Discrepancies here are rare but usually indicate a network-level issue or a server-side tag stripping parameters.
5. If Tag Assistant shows the request firing but DebugView does not show the event: first check the measurement ID mismatch — the event went to a different property. Second, check whether DebugView is filtered to the wrong device session. Third, wait 30 seconds and refresh — there is a small propagation delay even in real-time mode.
6. If DebugView shows the event correctly but standard reports do not: this is almost always a processing delay. Standard reports take 24–72 hours to fully process. If the event is still missing after 48 hours, check whether a data filter is excluding it — go to Admin → Data Filters and look for any active filters that might match the event.
7. If neither tool shows the event: the tag is not firing. Switch to the GTM Preview panel and check whether your trigger condition is being met. Look at whether the event that should fire the trigger is appearing in the GTM event list. Check that the tag is not paused.

Common Debugging Scenarios

"My event fires in Tag Assistant but not in GA4"

Check the measurement ID first. Open the event in Tag Assistant and look at the tid parameter — it will show something like G-XXXXXXXXXX. Open GA4 and go to Admin → Data Streams and confirm the measurement ID matches. A mismatch means the event is being sent to a different property — possibly a dev property, a staging property, or a property that was retired and never cleaned up from the GTM container.

If the measurement ID matches, check the DebugView device selector. If you are testing on a device that is not selected in the dropdown, your events will not appear. Switch to "All" first, then find your device in the list.

"Event shows in DebugView but not in standard reports"

Wait. Standard reports in GA4 take 24–72 hours to fully process. DebugView data is real-time and excluded from standard reports — it is a testing view, not the production data pipeline. If an event shows correctly in DebugView, it has been received by GA4 and will appear in reports after processing.

If the event is still missing after 48 hours, check your data filters. Go to Admin → Data Filters and look for any filter marked as Active. A common case is an internal traffic filter that is accidentally matching test traffic — or a production filter that has an overly broad exclusion rule. You can temporarily switch a filter to Testing mode (which tags matching traffic without excluding it) to see whether a filter is the cause.

"Parameters show in Tag Assistant but are empty in GA4"

This is almost always a data layer timing issue. The GTM tag is firing on the right trigger, but the data layer push that populates the parameter values is happening after the tag fires — so the tag reads empty variables and sends empty values to GA4.

To confirm: in GTM Preview, look at the sequence of events. Find the GTM event that fires your tag (for example, gtm.click) and check whether the data layer variables you need are already populated at that point. If they are not, you need to either push the values before the click event fires or change the trigger to fire after the data layer push.

"My purchase event fires 3 times"

Duplicate tag firing. The most common cause is two separate tag configurations that both fire on the checkout success page: a GTM tag AND a hardcoded gtag snippet in the site's source, or two separate GTM tags for the same event that were created by different team members at different times and never consolidated.

In Tag Assistant, look for multiple network requests to google-analytics.com/g/collect with en=purchase in the payload on the same page. If you see three requests, there are three things sending the event. Check the page source for a hardcoded gtag snippet and check GTM for multiple purchase tags. Pause any duplicate tags, publish the container, and verify that exactly one request fires per transaction.

FAQ

What is GA4 DebugView?

GA4 DebugView is a real-time event monitoring interface built into the GA4 property interface. It shows events arriving from debug-enabled sessions as they happen, with their full parameter payloads. It is accessible at Configure → DebugView in any GA4 property and is excluded from standard reports — events visible in DebugView do not affect your production data.

How do I enable GA4 DebugView?

Three methods work. First: add ?gtm_debug=x to any URL on your site — this activates GTM Preview and sends debug signals to GA4 simultaneously. Second: call gtag('set', {'debug_mode': true}) on your page before any GA4 events fire — used for sites without GTM. Third: install the GA4 Debugger Chrome extension, which activates debug mode automatically for your browser session.

What is Google Tag Assistant?

Google Tag Assistant is a Chrome extension that intercepts the raw network requests from Google tags (GA4, GTM, Google Ads) before they reach Google's servers and shows you their decoded payloads. Unlike DebugView, which shows what GA4 received, Tag Assistant shows what the browser sent — making it useful for debugging missing parameters, consent state issues, and measurement ID mismatches.

Can Tag Assistant see consent-blocked events?

Yes. When Consent Mode is active and analytics_storage is denied, GA4 still sends a cookieless ping to Google's servers. Tag Assistant captures this request and shows the gcs parameter as G100, indicating denied consent. This lets you verify that consent mode is default-denying correctly and that the cookieless ping fires as expected even before the user accepts the banner.

Why does my event appear in DebugView but not in reports?

Processing delay is the most common reason. Standard GA4 reports take 24–72 hours to fully process event data. DebugView is real-time and separate from the standard reporting pipeline. If an event appears correctly in DebugView, it has reached GA4's servers successfully. Wait 48 hours before investigating further. If it is still missing after that, check for active data filters in Admin → Data Filters that might be excluding the event.

How do I debug a GA4 event in GTM?

Open GTM Preview by clicking Preview in the GTM interface, which opens Tag Assistant connected to your site. Trigger the event on your site — the GTM Preview panel shows every GTM event in sequence. Click any event in the left panel to see which tags fired, which variables were resolved, and what values they held at that moment. For GA4-specific parameter debugging, also check DebugView in your GA4 property to see the event as it arrived.

What does the gcs parameter mean in Tag Assistant?

The gcs parameter encodes the Consent Mode state at the time the hit was sent. The value is a string where each digit indicates a storage type: G111 means analytics storage granted and ad storage granted. G100 means analytics storage denied and ad storage denied — the hit is a cookieless ping. If your consent banner is working correctly, pre-consent hits will show G100 and post-consent hits will show G111.

How long does DebugView data stay visible?

DebugView shows the last 30 minutes of debug-mode events from active debug sessions. It is not a historical log — events older than 30 minutes scroll off the timeline. For historical debugging, standard GA4 reports and Explorations are the right tools. DebugView is designed for real-time verification during active implementation and testing, not for reviewing what happened hours or days ago.