How do you check if your Google Analytics tracking is actually working?

In short: "is Google Analytics working?" is really three separate questions: does the tag fire, does the data arrive, and is the data correct? Debug tools answer the first in two minutes and the second in ten. Almost nobody asks the third, and it is the only one that guarantees your reports aren't telling stories. A green tag has never proved correct data.

The tag is green in Tag Assistant. The realtime report shows traffic. The GTM container is published. Everything says tracking works.

And yet the revenue GA4 reports is 17% below what the back office says.

Both things are true at once. The tag fires, and the data is wrong. This is precisely the situation routine checks don't catch, because they stop one step early: they verify the plumbing, not the contents.

This article takes the three levels in order — what each one proves, what it doesn't, and when to move to the next.

The three questions hiding inside "is it working?"

When someone asks whether tracking works, they are stacking three questions of increasing difficulty:

1. Does the tag fire? Does the request leave the browser.
2. Does the data reach GA4? Does Google receive it, accept it and process it.
3. Is the data correct? Does what arrived describe what actually happened on the website.

Each level needs different tools, and critically: passing one level says nothing about the next. A tag that fires can send a purchase with no value. Data GA4 accepts cleanly can be counted twice. Which is why "the tag is green" answers the easiest of the three questions and gets presented as an answer to all three.

The line to remember: the levels are hierarchical in verification order, not in importance. The third one is what business decisions rest on, and it's the one that gets skipped.

Level 1 — check the tag fires

Four methods, fastest to most reliable:

• GTM Preview mode. Browse the site with the Tag Assistant window open and you see, tag by tag, what fired, on which event, and why. This is the starting point when GA4 is deployed through GTM.
• The browser Network tab. Filter on collect?. Every request to /g/collect is a GA4 hit leaving the browser, and its parameters are readable straight from the URL: en carries the event name, tid the stream ID.
• The Google Analytics Debugger extension. Useful when GA4 is implemented with gtag.js directly, without GTM.
• The console. Typing dataLayer returns the push history for the current page. This is the prerequisite for everything else: if the information isn't in the dataLayer, no tag can send it. If that word is new to you, start with this article.

What this level proves: the firing mechanism is wired up.

What it doesn't prove: anything at all about correctness. Tag Assistant confirms a tag fired — not that GA4 accepted and correctly processed what it contained. The green light is a plumbing test.

Level 2 — check GA4 receives the data

The tag fires. Now: what does Google do with it?

• DebugView is the reference tool. It shows your session's event stream live, event by event, with every parameter received. You need debug mode to appear in it: GTM Preview mode turns it on automatically, otherwise the Google Analytics Debugger extension or a debug_mode parameter on the config does the job.
• The Realtime report confirms non-debug traffic is arriving, which means it works for real users and not just for you.
• Standard reports only populate after 24 to 48 hours for non 360 properties. Never diagnose an outage from an empty standard report on release day.

In DebugView, the useful check is not "the event shows up". It is opening the event and reading its parameters: is value populated, does items contain products, is currency there. A purchase that appears in DebugView with an empty value is a purchase that breaks your revenue reporting, and it is perfectly green.

What this level proves: GA4 receives and processes the events.

What it doesn't prove: that it works for everyone. DebugView shows only your session, in your browser, with your consent granted and your extensions. It is a sample of one. Confirming the data actually lands in the tools — GA4, but also Meta or Segment — is a separate exercise.

Level 3 — check the data is correct (the level everyone skips)

This is where the question you actually care about lives, and no debug tool will settle it. It is settled by comparing your collection against an outside truth.

• Reconcile GA4 with your back office. Transaction count and revenue for a closed day, GA4 against back office. A 8-10% gap is normal (consent, blockers, attribution windows). A 20% gap is an incident.
• Measure fill rates. Not "add_to_cart exists" but "add_to_cart carries value 98% of the time". A parameter filled 60% of the time is a parameter broken across an entire journey.
• Compare volumes against themselves over time. A sharp drop on one event at constant traffic is almost always a regression, not a drop in activity.
• Check across environments. Another browser, a real mobile device, a session with consent refused. Partial outages surface here and nowhere else.

The back-office reconciliation is the single most important check in this article, and the most commonly missing. It is the only one comparing your measurement to something other than itself. Without it you are verifying the internal consistency of a system that can be consistently wrong.

The line to remember: a green tag proves something left the browser. Only an external reconciliation proves that something is true.

The verification table

The last three rows are the ones no debug tool will ever surface, and the ones that cost the most.

When everything looks fine and nothing is

Silent failures are this field's specialty, because they produce no error. They produce plausible numbers.

• Two GTM containers live at once. Every event counted twice. Traffic looks excellent, and it is one of the most common mistakes.
• Tags fire before consent. Data arrives, but in a legally untenable position — often with a consent model that will make it vanish from reports later anyway.
• Casing changed. add_to_cart became addToCart after a redesign: the event fires, GA4 receives it, and it feeds no existing report.
• The parameter is there but mistyped. A value sent as the string "49.90" instead of the number 49.90. The hit passes, the aggregation breaks.
• The failure hits one segment only. One browser, the mobile funnel, logged-in users. Global volume barely moves, so nobody notices.
• Internal filtering eats your test traffic. You check from an excluded IP and diagnose an outage that doesn't exist.

What they share: none of them is visible without a reference stating what should be sent. That reference is the tracking plan. Without one, you are not verifying your tracking, you are watching it.

Why this check doesn't hold over time

Everything above describes a point-in-time check. Done properly across all three levels, it takes half a day on a mid-sized e-commerce site. The problem isn't doing it once — it's that it stays valid until the next release, which often means days.

And the gap between collection breaking and somebody noticing is measurable. Our own figures put the average at two weeks, except when the regression touches revenue directly — because there, someone is looking daily. Everything else (engagement, funnel steps, the events feeding attribution) has no daily watchman and drifts quietly.

That is what MayIA° automates. LLM agents replay your journeys like a user, compare every observed event against what your tracking plan declares, and flag the gap at each deployment rather than when somebody eventually questions a number. Level 3 — the one nobody has time to redo by hand every release — becomes systematic. If you want the full manual method before automating anything, it's in how to test a data layer; and if you're comparing what the market offers, we've documented the automated data layer QA tools.

In closing

"Is Google Analytics working?" is a badly posed question, and that's what makes it dangerous: it always gets a reassuring answer. The tag fires, so it works.

Ask it in three parts instead. Does the tag fire, does the data arrive, is the data correct? The first two take fifteen minutes with Google's own tools. The third requires comparing your collection to something outside it, and it's the only one your media decisions and board reports actually depend on.

If you remember one thing: a green tag is a transport test, not a truth test.

Want to know what your collection is really reporting, without spending the half day? Have it audited — we run your critical journeys and tell you where the gaps are.

FAQ

How do I know if Google Analytics 4 is working on my site?

In three steps, not one. GTM Preview mode confirms the tag fires, DebugView confirms GA4 receives the event and its parameters, and a reconciliation against your back office confirms the numbers are right. The first two take fifteen minutes; the third is the only one that proves anything about data quality.

Why is my tag green in Tag Assistant when my data is wrong?

Because Tag Assistant verifies transport, not contents. It confirms a tag fired, not that the values sent were correct or that GA4 processed them as intended. A purchase with no value, an event double counted by a second GTM container, or a parameter sent as text instead of a number all show a green tag.

How long does it take for data to appear in GA4?

DebugView and the Realtime report are immediate. Standard reports only populate after 24 to 48 hours. Never diagnose an outage from an empty standard report on release day: check in DebugView, which answers straight away.

Why doesn't DebugView show my events?

Usually because debug mode isn't active: DebugView only shows sessions in debug mode. GTM Preview mode enables it automatically, otherwise you need the Google Analytics Debugger extension or a debug_mode parameter on the config. Also check you aren't browsing from an IP excluded by an internal traffic filter.

What gap between GA4 and my back office is normal?

Between 8 and 10% on transactions and revenue, caused by refused consent, script blockers and attribution windows. Past 20%, treat it as a collection incident and find the cause. This reconciliation is the most important check available and the most commonly missing.

How often should I check my GA4 tracking?

At every release, because a check is only valid until the next deployment. Our own figures show a regression takes two weeks on average to be noticed, except when it touches revenue directly. Past a few releases a month, redoing the check by hand every time stops being realistic and automation becomes the only way to keep up.