Analytics
Fix broken GA4 tracking with DebugView
GA4 DebugView is how I prove a purchase event exists before I argue about a report. I am a Gold Coast web developer with 18 years on live storefronts. When conversion dies after a theme release, I do not start in the monetisation overview. I start with a tagged browser, Tag Assistant, and DebugView watching purchase land with items, value and transaction_id. In 2026 that loop is still the fastest way to find duplicate tags, missing items and blocked consent.
Google's DebugView help covers how to enable the debug stream. This note is the production sequence I use on Shopify Plus, custom Shopify, WooCommerce and Magento. It pairs with GA4 ecommerce events that match real revenue and with Google tag and Tag Manager unification when the container itself is the mess.
DebugView is not a daily dashboard. It is a surgical tool. If you leave debug mode on for the company, you will pollute real-time and you will think you are clever until sampling jokes stop being funny.
What GA4 DebugView is for
GA4 DebugView is for watching events from a device that is in debug mode, in order, with parameters expanded. You see page_view, consent-related noise if you send it, view_item, add_to_cart, begin_checkout and purchase as they happen. You do not see yesterday's users. You see you, or a colleague on a staging order.
That is the point. Reports lag, they aggregate, they hide parameter typos. DebugView will show item_id as undefined. It will show two purchase events two seconds apart. It will show nothing at all if the hit never left the browser.
You enable debug with the GTM preview, with the Google Analytics Debugger extension, with debug_mode in the config, or with a debug query parameter depending on how the tag is installed. I prefer GTM preview because I also see whether the trigger fired. If the site uses only gtag in the theme, the extension or a query flag has to do.
Tag Assistant (the tag diagnostics product, not the old Chrome plugin name people still use) tells you whether Consent Mode defaulted and updated, and whether Google tags loaded. DebugView tells you whether GA4 accepted the event into the debug device stream. I use both. Assistant without DebugView is how you miss a malformed ecommerce object that still "fired." DebugView without Assistant is how you miss a consent deny.
On Offporter the Shopify Plus storefront is editorial: chapters, dark mode, a layout that has to hold on a phone. Tracking still has to fire on the real templates, not on a leftover Dawn cart. On Brigade Overland a Woo to Shopify migration means old GTM triggers that listen for Woo body classes will silently die. DebugView on the new checkout is the migration test, not an optional extra.
How to use GA4 DebugView on a live purchase
GA4 DebugView on a live purchase works when you isolate one order and one browser profile.
I use a clean profile or Incognito with the debugger allowed. I exclude my IP in GA4 if I do not want the order in reports, but I still need the debug stream, so I do not block the hit at the network. I accept consent the way a customer would on one pass, and I reject on a second pass.
I navigate like a customer: landing page, collection, PDP, add to cart, checkout, pay with a real test gateway. Wallets included. If Shop Pay or Apple Pay skips the thank-you template you instrumented, DebugView will show the gap. That is the most expensive gap in 2026 stores.
On purchase I expand every parameter. transaction_id must match the order name in admin. value must match the definition you wrote down. currency must be AUD or USD as the store charges, not a leftover. items must list the SKUs in the basket with quantities. Tax and shipping should be present if you claim they are.
I watch for page_view storms on single-page checkouts. Some themes fire a virtual page for every step with a new location and no ecommerce. That is acceptable if begin_checkout and purchase still exist. It is not acceptable if each step also fires purchase.
I compare GTM's dataLayer panel to DebugView. If the dataLayer has items and DebugView does not, the GA4 event tag is mapping the wrong object. If both are empty, the theme never pushed. Visual tagging might have guessed a button and missed the price. That is why I want a theme-owned dataLayer.
Consent reject pass: I expect no ads storage and limited or no analytics depending on setup. If purchase still appears with full client identifiers, your consent mapping is theatre. If nothing appears and you thought Advanced Consent Mode would send a cookieless ping, confirm that mode is actually on.
After the order, I wait for the standard reports. Debug success and report failure means a filter, a reporting identity delay, or you looked at the wrong property. Debug failure and report success means you were not in debug mode and you are reading someone else's purchase. Do not mix those lessons.
I keep a second DebugView pass on the first collection page and the first PDP, not only on thank-you. A store can purchase-tag perfectly and still have a dead funnel because view_item never fires on the Horizon or Hyva template you actually shipped. Merchandisers will then ask why product reports are empty while revenue looks fine. That is still a DebugView job. Expand items on view_item and confirm item_id is the SKU, not a handle or a numeric entity id that Magento will not reuse in the feed.
Production checklist for DebugView, Tag Assistant and purchase
A tracking fix is done when this list passes on staging and on production with a $1 or discounted test SKU.
- Confirm the measurement ID in the page source matches the GA4 property you have DebugView open on. Agencies leave old IDs in themes. I do not name agencies. I still find the IDs.
- GTM preview connected to the same container version you think you published.
- Consent default visible before Google tags.
view_itemon PDP with item_id.add_to_carton a successful add, including ajax carts.begin_checkouton the first checkout screen or wallet start.- One
purchaseon thank-you, with items. - Reload thank-you: zero extra
purchase. - Tag Assistant: no duplicate gtag config for the same ID.
- Repeat on Safari iOS if the audience is fashion or anywhere Safari share is high.
Document the order number in the ticket. Future you will not remember which test was clean.
What breaks when DebugView looks empty
Empty DebugView usually means debug mode is off, you are in the wrong property, an ad blocker is on, or a CSP / consent tool blocked the collect request. Check the network tab for google-analytics.com/g/collect or the region-specific collect URL. No request, no DebugView.
Empty ecommerce parameters mean the event fired as a custom event without the ecommerce payload. GTM might send purchase as a name while the items sit in an unmapped variable.
Events in GTM preview but not in DebugView can mean the GA4 tag has a firing condition that failed (consent, a hostname filter, a trigger that requires a dataLayer event you renamed).
Too many events: a loop of view_item on image zoom, or a React strict-mode double mount on a headless storefront. Headless teams are surprised. I am not. Debounce or gate on a real product id change.
Server-side GTM can show in DebugView if you forward debug flags. If you strip them, you will think client is broken when the server ate the hit. Check the sGTM preview as well.
Time drift: DebugView devices expire. You have to keep the session alive. People walk away, come back, and think tracking died.
Another empty-looking stream is a hostname filter in the GA4 config tag. Staging works in preview because you tested on the live hostname by accident, or production is empty because the tag only allows www and the ads URL is the apex. DebugView will show events on the host you actually loaded. The config tag will drop them before they become reports. Read the tag's destination and the debug device name together. If the device never appears, you are not in debug mode. If the device appears and events vanish from reports, you have a filter, a data retention view, or a different property in the next tab.
How to measure a fix after DebugView is green
Green DebugView is necessary, not sufficient. Compare 48-72 hours of purchase counts to gateway orders after the publish. Watch for a step change at the deploy timestamp. If you fixed duplicates, GA4 revenue should fall toward the gateway. That fall is a success. Warn finance before they think the site broke.
Mark the GTM version and the theme release in a changelog. Tracking regressions love to hide in "just a banner app."
I do not use DebugView to quote conversion rate. I use it to make conversion rate possible. The Brigade Overland Shopify theme and Offporter Shopify Plus cases are storefront proof. The analytics proof is a purchase payload that matches the order.
Related work on this site
Offporter is Shopify Plus with a chapter model and dark mode. Debug the actual templates, including mobile. Brigade Overland is a WooCommerce to Shopify move with a custom theme. Old triggers will not find new markup. For the event schema you should see in DebugView, read GA4 ecommerce events. For container-level duplication, read Google tag and Tag Manager unification in 2026.
FAQ
Why is GA4 DebugView not showing my events?
Usually debug mode is not on, the property ID does not match, or the collect request is blocked. Confirm GTM preview or the debugger extension, then watch the network tab. GA4 DebugView cannot display a hit that never left the device.
Can GA4 DebugView replace Tag Assistant?
No. Tag Assistant shows tag load and consent. GA4 DebugView shows the event as GA4 parsed it. You want both on a broken purchase.
Does GA4 DebugView work with server-side tagging?
Yes if the debug flag is forwarded and you know which preview to open. If the server strips debug, you will only see production processing. That is a setup choice, not a GA4 bug.
Will GA4 DebugView include other users on the site?
Not in the debug device column if they are not in debug mode. Do not confuse DebugView with realtime. Realtime is everyone. DebugView is the tagged device.
Keep reading
Contact if you want this kind of work on a live store.