In a delivered tracking audit, one GA4 property reported roughly 526,000 conversions in 90 days. Real revenue behind those conversions: $0. The team had marked session_start and user_engagement as key events, and the actual purchase tag had never fired at all, across all eight Google Ads conversion actions reading zero for the entire window.
Nothing about that property looked broken from a volume standpoint. Sessions were steady. The "conversions" metric was large and growing. Any GA4 tracking alerts built on anomaly detection, which watches whether a number moves outside its predicted range, would have found nothing to flag, because the number never moved outside its range. It was just measuring the wrong thing, on schedule, for three months.
That is the gap most guides to GA4 tracking alerts skip past: they explain how to turn anomaly detection on, not what it structurally cannot see.
What GA4's native alerting actually watches
GA4 ships a real, free alerting feature called Custom Insights, under the Insights card on the Home page. Google's documentation on GA4 anomaly detection describes the mechanism plainly: the system uses historical data to predict what a metric should look like at the current point in time, and flags the datapoint as an anomaly if the actual value falls outside the credible interval that prediction produces. Google's overview of Analytics Insights adds the two flavors, automated insights the system surfaces on its own and custom insights you configure yourself, with up to 50 per property.
Setup takes a few minutes: pick a metric (sessions, revenue, event count, conversions), a segment if you want one narrower than "all users," a condition like "Has Anomaly" or a fixed threshold, and a notification schedule. It is a genuinely useful feature, and most ecommerce GA4 properties we see have never turned it on.
The failure mode volume alerts cannot see
Anomaly detection is a statement about one number moving relative to its own history. It has no opinion on whether the number represents something true.
That is exactly the shape of the telehealth property's failure. Event count and conversion count were both internally consistent and trending normally, because session_start and user_engagement fire on nearly every visit. GA4 had no way to know those events were standing in for a purchase that never happened, because nothing in the anomaly model checks what a key event actually represents, only whether its count behaves like it usually does.
The same blind spot shows up in smaller, more common versions on ordinary ecommerce setups:
- A purchase tag that keeps firing the expected number of times per day, but with a
valueparameter stuck at zero after a variable misconfiguration, so conversion count looks fine while reported revenue quietly goes to nothing. - A GTM container update that fires the purchase event from two destinations, doubling the count without changing the shape of the trend enough to register as an anomaly against a volatile baseline.
- A currency or item-data error that corrupts the purchase value on a subset of orders, invisible to any alert watching total revenue if the error is small relative to overall volume.
None of these trip a volume-based alert, because none of them are a volume problem. They are a value-integrity problem, and GA4's anomaly detection was never built to check that a key event's data is correct, only that its frequency matches a historical pattern.
The same field note carries a second lesson on this point. The same engagement that found the dead purchase tag also found a complete measurement plan sitting unused in the GTM container, 42 dataLayer variables and 13 funnel triggers built out for a 14-screen intake flow, with 10 of those 13 triggers orphaned and no GA4 event tag ever attached to them. The infrastructure for correct tracking existed. Nothing about GA4's reports, anomaly detection included, could tell anyone that the triggers it depended on had quietly stopped connecting to anything.
Closing the gap without buying another tool
The fix is not a more sophisticated anomaly detector. It is a second, different kind of check layered on top of the first one, the same reconciliation discipline that catches a GA4 and Shopify revenue mismatch: pull the store platform's own order export for a fixed window, and compare its revenue total and order count directly against what GA4 reports for the same window and the same key event.
A gap that stays small and explainable over time is healthy. A gap that opens suddenly, or one your team has never checked because "the conversion count looks fine," is the exact failure the telehealth property had for 90 days before anyone looked at revenue instead of count.
Run that reconciliation on a schedule, not just when something feels off. Monthly is a reasonable floor for a stable store; immediately after any checkout, consent banner, or GTM container change is non-negotiable, because that is when a value-level break gets introduced without ever showing up as an anomaly.
What to actually set up
Treat GA4 tracking alerts as two layers, not one:
- Volume layer (automated): Custom Insights on revenue, purchase event count, and sessions, set to "Has Anomaly" with daily email notifications. This catches the loud breaks: a tag that stops firing, a redirect that kills a funnel, a consent default blocking everything.
- Value layer (scheduled, manual): a recurring reconciliation of GA4 revenue and order count against the store platform's real order export, at minimum monthly and always after any tracking-adjacent change.
Neither layer replaces the other. A store running only the volume layer is protected against the dramatic failures and exposed to the quiet ones, which, as the telehealth case shows, can run for months while every dashboard looks calm.
Write both layers down as an owned task with a cadence, not a one-time setup step. The volume layer needs someone to actually read the email when an anomaly alert fires rather than archiving it; the value layer needs a calendar reminder and the store platform's export format decided in advance, so the monthly check takes minutes instead of becoming a research project every time. A team that treats this as "we have alerts configured" without assigning who checks the reconciliation number is functionally back to having no alerts at all for the failure mode that matters most.
If the reconciliation step turns up a gap you cannot explain, that is the point where a tracking audit earns its cost, finding exactly which tag, trigger, or variable produced it rather than guessing from the outside. And if what you actually want is someone checking both layers on a schedule so this never becomes a quarterly surprise, that ongoing tracking health work is what our Growth Partner retainer is built to carry, instead of a one-time setup that nobody revisits until a number looks wrong.
