GA4 Anomaly Detection: Catching Breakages Before Your Client Does

The worst conversation in analytics goes like this. A client asks why conversions are down 40% this month. You look. Conversions are not down — the purchase tag stopped firing on the 8th, and it is now the 3rd of the following month. Twenty-six days of ecommerce data are gone, they are not recoverable, and the last month of reporting was wrong in a way that people made decisions on.

Every part of that is preventable. The tag broke on the 8th and the data was visibly abnormal on the 9th. Nothing was watching.

The detection gap

Analytics fails silently by design. A tag that stops firing does not throw an error. GTM does not alert. GA4 does not alert. The data simply stops, and the report shows a smaller number, which looks exactly like a business result.

The gap between failure and discovery is set entirely by your reporting cadence. Weekly reporting means an average of three and a half days. Monthly means around fifteen days, and up to thirty. And that assumes someone reads the report carefully enough to distinguish a tracking break from a soft month — which, if the drop is 15% rather than 90%, they often will not.

Closing the gap needs something that looks at the data every day and says something when it is wrong.

What to actually monitor

Monitoring everything produces noise, and noisy alerts get muted within two weeks. Pick metrics where a sharp change is almost always a defect.

Sessions or users, total. The broadest signal. A large drop means the property is not receiving data — configuration tag broken, container unpublished, snippet removed in a deploy.

Key events, individually. This is the highest-value monitor and the one most often missing. Each key event should be watched on its own. purchase dropping to zero while page_view is healthy is unambiguous: the site is fine, the tag is broken. Aggregate conversion monitoring hides this — one dead event among six is a 17% dip that looks like a slow week.

Revenue. Watch it separately from purchase count. Revenue falling while purchase count holds means value is broken, not the tag.

Traffic by channel. Organic collapsing while direct spikes is the classic signature of a broken referrer or a botched cross-domain change. Total sessions would be unchanged.

Events by name, for the ones that matter. Form submissions, sign-ups, add-to-cart. Anything a business decision depends on.

Spikes, not just drops. A tag that starts firing twice doubles an event. This is harder to notice than a drop because everyone is pleased, and it corrupts data just as thoroughly.

Thresholds that do not produce noise

The tension is real: sensitive enough to catch a genuine break, tolerant enough that a normal Monday does not fire an alert. An alert people ignore is worse than no alert, because it creates the belief that something is watching.

Set thresholds from the metric's own variance, not from a round number. A site with 100,000 sessions a day has stable traffic and a 20% drop is a genuine anomaly. A site with 300 sessions a day routinely swings 40% between weekdays. The same percentage threshold cannot serve both.

Compare like-for-like periods. Day-over-day comparison fires every Saturday on a B2B site. Compare against the same day last week — that removes weekly seasonality, which is by far the largest source of false positives.

Set the floor generously at first. Start at a threshold that only catches obvious breaks — 50% on a key metric. Tighten it once you have seen a month of real variance. Starting tight and loosening after a week of noise means nobody trusts it by the time it is tuned.

Mind the data-freshness lag. GA4 data is not final for 24–48 hours. Alerting on today's partial data produces a drop alert every morning. Compare complete days.

Separate business seasonality from defects. Black Friday, a campaign launch, a site outage — all produce anomalies that are not tracking failures. Annotate them, and expect a manual triage step; the goal is a signal worth investigating, not a signal that is always correct.

Routing and response

Alerts go to the people who can fix them. A tracking break is an engineering problem. Sending it only to the marketing lead adds a relay hop while data is being lost.

One alert, not one per metric. Six alerts for one broken container is six people asking each other what happened. A digest that says "these four metrics are anomalous" reads as one incident.

The alert should carry enough to triage without logging in. Which property, which metric, expected versus actual, the comparison window. Enough for someone to judge severity from their phone.

Then have a response path. An alert nobody knows what to do with becomes an alert nobody reads:

1. Is it real? Check the metric in GA4. Partial data and reporting lag account for a fair share of first alerts.
2. Is it collection or business? If sessions are flat and one event went to zero, it is collection. If everything dropped proportionally, look at the site.
3. When did it start? Find the exact day. Then find what shipped that day.
4. Reproduce it. Walk the journey with a live capture running. This is where a statistical alert hands off to actual debugging.

The two layers, and why you need both

Statistical monitoring watches the output. It catches anything that moves the numbers, including failures nobody predicted — which is its real strength. Its weaknesses are that it needs enough volume to be reliable, it is inherently a day or more behind, and it cannot tell you why.

Synthetic monitoring watches the behaviour. A recorded journey replayed on a schedule in a real browser, asserting that specific events fire with specific parameters. It catches a break within minutes, it works regardless of traffic volume, and it tells you exactly which step failed. Its weakness is that it only checks what you thought to assert.

These are complementary, and the failures they miss are different:

• A checkout break on one payment method you did not record: statistical catches it, synthetic misses it.
• A break on a low-traffic but high-value journey: synthetic catches it in minutes, statistical never reaches significance.
• A parameter that starts arriving as a string instead of a number: synthetic catches it if you asserted the type; statistical catches it only when revenue reads zero.
• A consent banner change that blocks all tags for EEA visitors: statistical catches the regional drop; synthetic catches it only if you replay from that region.

Run both. Synthetic gives you speed and specificity, statistical gives you coverage.

How Tagfire helps

GA4 Anomaly Detector is the statistical layer. Set up detectors per property on the metrics that matter — sessions, key events individually, revenue, channel traffic — with your own thresholds and comparison windows. Choose whether they run daily or weekly and at what hour, nominate the recipients, and you get an email when a metric moves past its threshold. Multiple properties are supported from one place, which is the difference between "we monitor the main site" and "we monitor every client account."

It also connects to the debugging side: when a detector fires, an AI explanation of the anomaly is available in-app, drawing on the property's actual configuration and recent audit findings rather than generic advice.

Tag Debugger is the synthetic layer. Record a journey once — the clicks, the form fills, the navigation — attach expectations to it (purchase must fire, with value greater than 0 and currency equal to GBP), and group several recordings into a monitor for one site. The monitor runs on your schedule: each journey is replayed headlessly in a real Chromium browser, the captured hits are checked against the expectations, a full-page screenshot is taken and pixel-diffed against an accepted baseline, and any failure sends one digest email to all recipients. A run that fails tells you which recording, which step, and which assertion.

Replays send a distinctive user agent, so the synthetic traffic can be filtered out of the GA4 property it hits — which matters when the site belongs to a client.

GA4 Audit is the third leg: monitoring tells you when something changed, the audit tells you what is wrong right now. Run it when an alert fires and you often have your answer before you open a browser.

The anomaly detector requires a Pro plan; the audit and debugger are free. See the documentation for detector setup and journeys and monitors for the synthetic side.