Anomaly detection for business metrics, explained

Daily revenue dropped 30% yesterday. Is that a problem, or a normal day after a holiday weekend? Anomaly detection is the discipline of telling those two apart consistently, instead of by whoever happens to look at the chart.

This post explains the common methods in plain terms, shows the arithmetic, and covers the part most guides skip: how many false alarms each method will produce, because that decides whether anyone keeps paying attention.

An anomaly is relative to what you expected

An anomaly is a value far from what you expected, not any value that happens to be high or low. A 40% drop in orders on Christmas Day is expected for most B2B businesses. The same drop on an ordinary Wednesday is not.

So every method below is really two parts: a way to estimate "expected", and a rule for how far from expected counts as unusual. Most of the quality comes from the first part.

Method 1: fixed thresholds

Set a floor and a ceiling and flag anything outside them. "Alert if daily revenue is below $35,000 or above $75,000."

Good for: metrics that should be stable by design, such as a payment success rate or an error rate.

Weak for: anything with growth or a weekly pattern. A growing business drifts past its ceiling, and every Saturday looks like a crisis if the floor was set from weekdays. Thresholds also need someone to update them by hand.

Method 2: z-scores against recent history

Take a window of recent values, compute the mean and standard deviation, and measure how far today is from the mean in standard deviations:

z = (today's value - mean) / standard deviation

Worked example: daily orders over the last 60 days average 200 with a standard deviation of 15. Today there were 150 orders.

z = (150 - 200) / 15 = -3.3

That is well outside the usual range. With a threshold of 2 or 2.5 it gets flagged.

If values are roughly normally distributed, the share of ordinary days that cross each threshold by chance is:

Use a rolling window (for example the last 60 or 90 days) so the baseline follows the business as it grows.

Method 3: seasonal baselines

Most business metrics have a weekly pattern, and many have a yearly one. Comparing Monday's orders with an average that includes Saturdays produces false alarms every week.

The fix is to compare like with like:

• Daily data: compare each day with the same weekday over the last 8 to 12 weeks.
• Monthly data: compare with the same month in previous years, or remove the seasonal pattern first and look at what is left.

Example: Tuesdays over the last 10 weeks averaged 240 orders with a standard deviation of 12. Today, a Tuesday, had 200. Against the all-days average of 200 it looks normal (z = 0). Against other Tuesdays it is z = (200 - 240) / 12 = -3.3. The seasonal baseline caught a real drop the plain average hid.

Method 4: IQR fences

Standard deviations are pulled around by the outliers you are trying to find. The interquartile range (IQR) is barely affected by a few extreme values:

• Q1 = 25th percentile, Q3 = 75th percentile, IQR = Q3 - Q1
• Lower fence = Q1 - 1.5 x IQR, upper fence = Q3 + 1.5 x IQR
• Anything outside the fences is flagged

Example: Q1 = 180 orders, Q3 = 220, so IQR = 40. Fences are 180 - 60 = 120 and 220 + 60 = 280. A day with 110 orders is outside; a day with 150 is not.

IQR fences suit skewed data such as order values or ticket counts, where a few very large values are normal.

Method 5: residuals from a trend or forecast

For a growing or seasonal metric, fit the trend and seasonal pattern first, then run the z-score or IQR check on what is left over (the residuals). A value is unusual if it is far from what the trend and season predicted, not far from a flat average. This is how most forecasting tools flag anomalies.

Machine learning methods such as isolation forests or autoencoders go further and look at many metrics together, for example a day where revenue, traffic and conversion rate are each normal but their combination is not. They are worth it when you monitor hundreds of related metrics. For a small business with ten key numbers, the methods above are easier to explain and easier to trust.

The false alarm arithmetic

This is where monitoring setups usually fail. Say you check 20 metrics once a day with a 2-standard-deviation rule:

20 x 4.6% = about 0.9 false alarms a day, nearly one every day even when nothing is wrong.

At 3 standard deviations: 20 x 0.3% = 0.06 a day, or roughly one false alarm every two to three weeks.

People stop reading alerts that are usually wrong, and then they miss the real one. Ways to keep the rate down:

1. Use seasonal baselines before anything else. They remove the most common false alarms.
2. Require persistence for noisy metrics: flag only when two consecutive periods are unusual.
3. Use two levels: a warning at around 2.5 and a critical level at 3 or more, sent to different people.
4. Suppress known events: a sale, a launch, a public holiday.
5. Review monthly: if most alerts turned out to be nothing, raise the threshold or fix the baseline.

What to do when something is flagged

An anomaly is a question, not an answer. A useful first pass:

1. Check the data first. Did a sync fail, did a tracking tag break, did a file arrive half empty? A surprising number of anomalies are data problems. The guide to spotting data quality issues has a checklist.
2. Compare with the same day last week and last year.
3. Break the number down by channel, product or region to see where the change sits.
4. Check what changed on your side: prices, a deployment, a campaign that ended.

How clariBI flags anomalies

In clariBI, anomaly detection is part of forecasting, which is on the Starter, Professional and Enterprise plans. When a forecast runs on a metric, clariBI:

• removes the seasonal pattern it detected and a linear trend, then computes z-scores on what is left, flagging points 2 or more standard deviations out;
• separately applies an IQR fence (1.5 x IQR) to the raw values;
• flags a point if either check fires, and labels it mild, moderate (2.5 or more) or severe (4 or more);
• marks changepoints, the dates where the trend's slope changed, with the rate before and after.

This is statistics code, not a language model. The model only writes the short summary. Forecasts re-run on the schedule you set (monthly by default) or on demand.

Two honest limits. clariBI does not send an alert the moment a metric crosses a line; anomalies show up in the forecast result, so pair a forecast with a schedule you actually look at. And an anomaly next to another metric that moved at the same time does not prove one caused the other; the help article on AI limitations says more about that.

For the investigation step, Ask clariBI answers questions such as "Compare orders this week with the same week last month, by channel" on the Trial and on Starter and above. For the patterns underneath (trend, seasonality, one-off spikes) see time series patterns in business data.

A next step you can do today: pick your five most important daily metrics, compute a same-weekday baseline for each over the last ten weeks, and count how many days in that period would have crossed 2.5 standard deviations. If the answer is more than a handful, fix the baseline before you set up any alert.