DebugView is a report in Google Analytics 4 that shows, almost as they happen, the events sent from a device you have put into debug mode. It lets you test tracking before you rely on it, by watching each page view, click or purchase arrive with all its details attached.
How DebugView works
GA4 only lists a device in DebugView when the events it sends carry a debug flag. There are three common ways to add one. Opening your site through Google Tag Manager’s preview mode does it automatically for that browser session. The Google Analytics Debugger extension for Chrome does the same for any site you visit while it is switched on. Or a developer can add a debug_mode parameter to the tag itself, which is handy on a staging site.
At the time of writing (October 2026), DebugView sits in GA4 under Admin, then Data display. It shows a timeline of events from the selected device, newest first, alongside a count of events over the last half hour. Click any event to see its event parameters, such as the page address, the form ID or the order value, along with any user properties set at that moment. If several people are testing at once, a device selector lets you choose whose events to watch.
DebugView is not the same as the Realtime report, which summarises everyone on the site over the last 30 minutes. DebugView shows one device in full detail.
Why it matters
Most broken tracking was never tested properly when it went live. A form sends a key event every time the button is clicked, even when validation fails; a purchase event goes out with its value as text rather than a number; a thank-you page records two page views. None of this shows in standard reports, which take hours to process and only display totals. DebugView shows each event exactly as sent, so faults are caught before they distort a month of Google Ads bidding.
For a UK site with a cookie banner, it is also part of how you check that consent works as intended. Run one test after rejecting analytics cookies and another after accepting them, and confirm that what reaches GA4 in each case matches what your banner and cookie policy promise.
Common mistakes
- Seeing nothing and assuming the tags are broken, when an ad blocker or privacy browser is stopping the requests, or the cookie banner has not been accepted.
- Leaving debug_mode hard-coded in the live tag. Every visitor then appears as a debug device, and if a developer traffic data filter is active their events can be excluded from your reports.
- Watching the wrong device while colleagues test at the same time.
- Checking only that an event arrives, not that its parameters are right. A purchase with the wrong currency or no transaction ID passes a quick glance but fails in reports.
- Testing on a desktop browser only, when most paid traffic arrives on mobile.
How to act on it
Before you test, write a short list of the events that matter to the business: the enquiry form, clicks on the phone number, the booking or the purchase. Open the site through Tag Manager preview, complete each action as a customer would, and check in DebugView that each event fires once, with the parameters you expect, and is marked as a key event where it should be. Use Tag Assistant alongside it, because it shows why a tag did or did not fire.
Repeat the test after any site update, theme change or new plugin, since those are the moments tracking tends to break. My guide on how to check your conversion tracking works walks through the whole process. Testing is also my first step when I take on monthly PPC management, because bidding can only be as good as the conversions it learns from.