An Alert Without a Why Is Just Noise

Every unexplained alert is an invoice

The problem with metric alerting is rarely too few alerts. The problem is that almost every alert stops at what happened, and an alert that stops at what happened is an unassigned task. Someone still has to open the warehouse, slice the metric six ways, rule out a tracking break, and come back with a story. The alert did not do the work. It transferred the work, along with a small dose of adrenaline, to whoever happened to read the channel first.

Think of each unexplained alert as an invoice for 30 to 90 minutes of a human's attention. Most marketing teams run an alerting setup that issues dozens of those invoices a week, then wonder why the data team has no time for anything else.

The alert fatigue spiral

Static thresholds start the spiral. Someone configures "alert if daily revenue drops below 45,000" on a metric that runs 30 percent lower on weekends than weekdays. The alert fires every quiet Sunday. It fires the day after every promo ends. By week three the Slack channel holds 60 unread alerts and someone has muted it, reasonably, because everything it ever said was fine.

Month two: a theme update silently breaks the checkout tracking. Reported revenue drops for real. The alert fires, correctly, for once, into a muted channel, and scrolls past between two false alarms. The break surfaces four days later when finance reconciles against the payment provider.

The postmortem then makes it worse. Either the thresholds get tightened, which produces more noise, or they get loosened, which trades the noise for blindness. Site reliability engineers named this pattern pager fatigue years ago and wrote runbooks against it. Marketing analytics is currently rediscovering it from scratch.

One housekeeping rule is worth adopting immediately, whatever your tooling: an alert that has fired ten times without anyone reacting gets deleted, not tuned. Deleting it is honest. The muted version was already deleted in everyone's head.

What a useful alert needs

Four things separate an alert someone acts on from one that gets muted.

A learned rhythm instead of a static line

Marketing metrics have seasonality on several frequencies at once: weekday patterns, monthly cycles, promo effects, and the slow drift of the business itself. A Sunday at 32,000 is normal. A Tuesday at 32,000 is a fire. Anomaly detection against the metric's own learned rhythm can express "unusual for this metric at this time"; a static threshold cannot say that sentence at all.

The rhythm also needs to know about planned events. A promo launch looks exactly like an anomaly to a model that has never seen your promo calendar, so the calendar belongs in the system. Expected lifts are context, and a good alert on promo day says "in line with the last three promos" rather than crying wolf.

The first diagnostic pass already done

When a blended metric moves, the first human hour always goes to decomposition. ROAS is a ratio, so it hides its own cause: did spend rise or revenue fall? If revenue, was it traffic or conversion? Which channel, which campaign, which geo? This work is mechanical. Break the change down by dimension and by the metric's own components, rank the contributions, and report the largest. A machine does that in seconds, and it should have done it before the notification was sent.

Routing to whoever owns the metric

An alert everyone receives is an alert nobody owns. A retention anomaly belongs with the lifecycle team, a ROAS drop with performance, a tracking break with whoever owns the tag setup. The mapping can be a plain three-column table, metric, owner, channel, as long as it exists and the alerting consults it. Broadcast channels exist so that alerts can be ignored collectively.

A way to keep asking

The alert is the start of an investigation, and the notification should behave like it. "Has this campaign done this before?" and "what changed yesterday?" are the natural next questions. If answering them means opening a different tool and reconstructing all the context by hand, the alert was a dead end with good intentions.

The same event, two alerts

Same underlying event, two write-ups. The bad version is the one most teams have today:

Revenue alert: yesterday 41,200 EUR, below threshold of 45,000 EUR.

Three people ask in the thread whether this is bad. Someone checks if it is the weekend effect. The analyst drops their morning to pull channel splits, campaign splits, and a CPM series, and comes back after lunch: paid social, one campaign. Total cost, roughly four person-hours across the team, for one alert. Multiply by every threshold in the workspace and this routine consumes a meaningful share of the company's analytics capacity.

The good version describes the same day:

Revenue came in 14 percent below its expected range for a Tuesday in June. The gap traces to paid social: CPM rose 22 percent while conversion rate held steady, isolated to one prospecting campaign that re-entered learning after an edit yesterday at 09:40. Search, email, and organic are within their normal ranges.

Nothing about the second alert requires judgment. Every sentence in it is the output of a mechanical decomposition. What remains for the human is the actual decision, revert the edit or wait out the learning phase, and that is the one part a machine should leave alone.

Explaining a change requires joined data underneath

One architecture point gets missed when teams shop for alerting tools. A system subscribed to a single revenue time series can detect a deviation, but it can decompose nothing, because decomposition needs the joins: orders to sessions, sessions to spend, spend to campaigns. If the alerting layer sits on top of one metric feed, "why" stays out of reach no matter how good the anomaly model is.

The joins also need agreed definitions. When Shopify, GA4, and Meta each report a different revenue number, which they do, an alert on any one of them inherits that disagreement; we wrote up the mechanics in Why Shopify, GA4 and Meta All Report Different Revenue. And a diagnosis phrased in terms of platform-reported ROAS starts from a number that is itself questionable, which is a separate argument: Platform ROAS Is Fiction.

So the alert quality problem turns out to be a data architecture problem. Modeled, joined warehouse data with one definition layer on top serves the dashboards, the alerts, and the follow-up investigation from the same source. The alert should compute ROAS exactly the way the dashboard and the analyst compute it, which is a semantic layer job, and it is what makes the diagnosis in the notification trustworthy enough to act on without re-checking. Monitoring and investigation are one continuum, a point we make from the dashboard side in Your Dashboards Are Answering Last Quarter's Questions.

Where Verity fits

Verity's Automations follow this principle: watches run on metrics defined in the semantic layer, over joined models in your own BigQuery, so a notification carries its context instead of just its number. And because Data Chat sits on the same layer, the follow-up question picks up where the alert left off rather than starting the investigation from zero.