Automated GA4 anomaly detection

Broken analytics tracking has no error state. When a payment API fails, something throws, someone gets paged, and a dashboard turns red. When a purchase tag stops firing, GA4 reports a smaller number — and a smaller number is completely indistinguishable from a quiet week until someone looks closely enough to be suspicious.

That is why the median time-to-detection for a tracking break is measured in days rather than minutes. Anomaly detection closes the gap by making the absence of data an event in itself.

What a detector actually compares

A detector watches one metric on one property. On each run it pulls the most recent complete period from the GA4 Data API and compares it against a baseline built from the preceding periods. If the percentage change exceeds your threshold, in the direction you care about, it sends an email. Otherwise it stays silent.

That silence is the design goal. An alerting system that emails you every day is one you stop reading within a fortnight, and a threshold set too tight is worse than no alerting at all — it teaches the team to ignore the channel that will eventually carry the real failure.

Which metrics are worth a detector

Key events / conversions

The highest-signal detector you can create. Conversion tags are the most fragile part of any implementation, because they depend on specific page structures and specific user paths that change often. A 25 percent drop threshold catches real breakage without firing on a slow Sunday.

Revenue

Worth watching separately from purchase count, because they break differently. Purchases holding steady while revenue collapses usually means value or currency stopped being sent, not that customers changed behaviour.

Sessions

The blunt instrument, and the one that catches catastrophic failures — a container removed during a deploy, a consent banner change that blocks everything. Use a wider threshold here, around 30 to 40 percent, since sessions swing naturally with campaigns.

Spikes, not just drops

A doubling of sessions overnight is rarely good news. It is usually a duplicated GA4 configuration tag, a bot wave, or a page_view firing on every route change in a single-page app. Enable spike detection on sessions and you will catch the duplicate-tag class of bug the same day it ships.

Setting thresholds you will actually keep

• Look at the last 90 days of the metric first, and note the biggest legitimate day-over-day swing. Set the threshold above that.
• Start loose and tighten. A detector that has never fired teaches you nothing about whether it works; one that fires weekly gets muted.
• Use weekly cadence for metrics with strong weekday and weekend patterns, so you compare like with like.
• Give high-traffic properties tighter thresholds than low-traffic ones — noise scales inversely with volume, and a 40 percent swing on 200 sessions a day means nothing.
• Alert the person who can act, not the whole team. An alert with no clear owner is a notification, not a process.

Anomaly detection versus tag monitoring

These two solve the same problem from opposite ends, and mature setups run both.

The difference in practice is diagnosis. An anomaly alert tells you conversions fell 66 percent — true, urgent, and unhelpful about the cause. A tag debugger monitor tells you the purchase event stopped carrying transaction_id on the checkout page, with a screenshot. Anomaly detection is broad and cheap; monitoring is narrow and specific.

What an alert cannot tell you

When an alert lands, resist the urge to conclude tracking is broken. A conversion drop has three plausible causes and only one of them is your tags: the tracking broke, the site broke, or the business genuinely had a bad day. Work through them in that order — check whether the journey still fires with the tag debugger, then check whether the page still works at all, then check whether ad spend was paused.