Back to notes

October 17, 2026 · 5 min read

DebugView Is Not Optional, It's the Job

I've watched implementations ship without a single DebugView session. Every one of them had an event firing wrong in production within a week.

GA4Debugging

I took over a GTM container from another consultant last year and found twelve custom events, each carefully named, each with parameters mapped out in a spreadsheet nobody had updated in months. Four of the twelve fired with the wrong parameter types. One fired twice on every page load. None of this showed up in the GA4 reports for weeks, because aggregated reports are extremely good at hiding exactly this kind of problem.

The previous consultant never opened DebugView. I know because the duplicate-fire bug was the kind of thing you catch in about four seconds of watching the event stream live — it's not subtle once you're looking at raw events instead of a report that's already been rolled up, deduplicated by GA4's own processing, and smoothed into something that looks fine.

Reports lie by omission, DebugView doesn't

A standard GA4 report tells you an event happened a certain number of times. It does not tell you that the event fired with a null value for a required parameter, or that it fired on the wrong page, or that your ecommerce purchase event sent an item array with the price field as a string instead of a number — which GA4 will often silently coerce or drop rather than error on. You find these problems by watching the actual payload leave the browser in real time, which is exactly what DebugView is for and exactly what most people skip because it feels like an extra step instead of the actual verification step.

A report shows you what GA4 decided to keep. DebugView shows you what you actually sent. Those are not the same thing, and the gap between them is where every bad tracking decision gets made.

What I actually check in every DebugView pass

  • Every parameter on every event, checked against the measurement plan, not just that the event name fired.
  • Event order — does the add_to_cart fire before or after the cart actually updates in the UI.
  • Duplicate fires on single-page-app route changes, the single most common bug I find.
  • Parameter data types, especially numbers arriving as strings from a poorly typed data layer push.

This takes fifteen minutes per major user flow. It is not optional polish at the end of an implementation — it is the implementation. Shipping tagging work without a DebugView pass is like shipping code without running it once, and I treat it with exactly that level of non-negotiability on every project.