DebugView and Realtime as QA, and where they lie

DebugView answers a developer's question: did this specific event, from this specific device, carry the parameters I intended. Google's guidance on monitoring events in DebugView describes the layout, a seconds stream covering the last 60 seconds, a minutes stream covering the last 30 minutes, and a top events panel, with a device selector so several developers can work without interfering with each other.

Realtime answers an operator's question: is anything happening right now. Google's Realtime report documentation lists its uses as checking whether a one-day promotion is driving traffic, monitoring the effect of a post, and verifying that the measurement code is working.

The important difference is who is visible. DebugView shows only devices in debug mode, meaning you and whoever else turned it on. Realtime shows everyone, which is why it is the better answer to whether a deployment reached real users.

Getting into debug mode is the part people fumble. Google documents enabling it for yourself through Tag Assistant or preview mode, and enabling it for everyone by setting debug_mode to true in the configuration. It also notes that setting the parameter to false does not disable debug mode; you have to remove it.

The attribution row is the one that produces confident wrong answers. Google says the same thing about both tools: each performs limited attribution analysis to ensure responsive reporting, and recommends referring to the Acquisition reports for the most accurate attribution information.

So a source or medium seen in Realtime is not a claim about how that conversion will be credited. People check Realtime after a campaign launch, see a source that looks wrong, and escalate. The correct next step is to wait for the acquisition reports.

The delivery row is worth quoting because it is unusually candid. Google describes Realtime as a best effort service, prioritising timely delivery but not guaranteeing it, operating without a formal service level objective. Occasional delays are within its normal operating range.

This is the failure that wastes the most time, because it looks exactly like a broken tag. Google states directly that events are not visible in debug mode if you have implemented client-side privacy controls, or if you have implemented consent mode and users have not given consent for Analytics cookies.

Follow that through. A developer testing with the banner dismissed by refusal sees nothing, concludes the tag is broken, and spends an afternoon debugging a container that is behaving exactly as designed.

The inverse is worse and quieter. A developer who always accepts the banner never observes the consent-denied path at all, so a tag that misbehaves under refusal ships and nobody sees it until the reports look thin.

The rule that follows is short: test both consent states deliberately, every time, and know which one you are in. The implementation details that decide what happens in each state are in what consent mode v2 actually changes.

Neither shows registration. An event can be perfect in DebugView, with every parameter present and correctly typed, and still produce an empty report because the parameter was never registered as a custom dimension. Registration is a separate act, and Google documents data appearing 24 to 48 hours after both the data has been sent and the custom dimension has been created. It is covered in custom dimensions, scope and the retroactivity trap.

Neither shows the collection limits being enforced. A parameter value over 100 characters, an event name over 40, a 26th parameter on an event: these are dropped at collection under Google’s event collection limits, and the tool shows you what arrived rather than what you sent. The full list is in the GA4 limits you will hit.

Neither shows conditional failure. Your session is one device, one browser, one consent state, one variant of the form. The whole point of the recurring defects in the GA4 events that break without telling you is that they only occur on paths you are not currently walking.

And neither shows duplication reliably, because two identical events a few hundred milliseconds apart in a seconds stream read as one entry unless you are looking for it. Duplication is easier to find in the export than in a live view.

Use DebugView while building a single tag, with the specific question written down first. Not is the tag working, but does add_to_cart carry item_id, quantity, price and currency, with quantity reflecting what I selected. A named expectation turns watching into testing.

Use Realtime immediately after a deploy, for one purpose: confirming that real users, not just you, are producing the event. If Realtime shows the event and DebugView showed it too, the tag reached production. That is the whole claim, and it is a useful one.

Then stop, because the useful life of both tools ends there. What comes next is a check on the data that arrived over a period, against an expectation you wrote down, on a schedule. That is the argument in automated QA for tracking, and it is the only thing that catches a form variant going dark in March.

Filter yourself out afterwards. Google's DebugView guidance closes by recommending you filter out traffic while debug mode is on so debugging data does not affect report data, using the developer traffic filter described in filtering internal traffic without deleting real data.

The pattern that works is three layers, and the live tools are only the first. Layer one is DebugView during the build. Layer two is a walk of every conversion path end to end, in both consent states, on mobile and desktop, as a new and a returning visitor.

Layer three is assertion on the arrived data: event volumes within a band, required parameters present, no unexpected event names, no duplicate transaction identifiers. That layer runs weekly, forever, and it is the only one that survives a busy quarter.

The distinction between the layers is what people miss. The first two are about whether the tag was built correctly. The third is about whether it is still working, which is a different question with a different answer every month.

Write the expectation down before any of them. An event list with acceptance criteria per row turns QA from an opinion into a check somebody else can run, which is the case made in acceptance criteria for analytics work.

That is also the right shape for the engagement itself. Verification, not deployment, is the deliverable, which is why GA4 and Tag Manager implementation should be scoped around proving the paths rather than shipping the container.