How would you set a control band on weekly revenue to decide which weeks to investigate?

## What a control band is for A control band converts the endless argument 'is this week unusual?' into a rule agreed in advance. You draw a centre line for what the metric normally does and two limits around it, and you commit ahead of time that weeks inside the limits are not investigated while weeks outside are. The value is as much organisational as statistical: the threshold is chosen before anyone has a stake in the answer. ## Choosing the baseline The band inherits everything from the weeks used to build it. Include an incident week or Black Friday and the estimated spread balloons, the limits widen, and the chart stops detecting the very regressions it was built for — the classic way a monitoring chart quietly dies. So curate: take a run of weeks you can defend as normal, remove the ones you know were exceptional, and keep a written note of what you removed and why. Long enough to be stable, recent enough to reflect the current business: 20-50 weeks is a common compromise. ## Estimating the spread The naive approach — the standard deviation of the weekly revenue levels — is usually wrong for a growing business. If revenue climbs steadily, the level's standard deviation mostly measures the growth, not the week-to-week noise, so limits built on it are far too wide. The better estimate uses the differences between consecutive weeks: take the absolute change from each week to the next across the baseline and summarise those. This is the moving-range idea behind individuals charts, and it isolates short-run variation because a slow trend contributes little to any single one-step difference. In practice, many teams sidestep the trend entirely by banding the week-over-week percent change instead of the level: the quantity being charted is then roughly stationary even while the business grows. ## Choosing the multiplier The multiplier k in 'centre plus or minus k spreads' encodes a false-alarm budget. For a stable process whose weekly variation is roughly normal: - k = 3 leaves about 0.27% of points outside, roughly one in 370. Across 52 weeks that is about 0.14 false alarms per year. - k = 2 leaves about 4.6% outside, roughly one in 22. Across 52 weeks that is about 2.4 false alarms per year. The classic choice of three comes from wanting alarms to be rare enough that people still take them seriously. Tighten it only if a missed regression is far more expensive than a wasted investigation, and be honest about the arithmetic when you do. Two caveats matter. The percentages above assume approximate normality — for a heavy-tailed metric such as revenue with a few dominant accounts, the true tail is fatter and normal-based limits fire more often than the theory says, so it is often better to set limits from empirical quantiles of the historical weekly changes. And these numbers describe a stable process; the moment the process shifts, the point of the chart is precisely that it fires. ## Trend, seasonality and calendar A fixed centre line on a growing metric drifts out of the band and turns every week into an alarm. Options: band the percent change, recompute the centre on a rolling window, or band the difference between actual and expected level. Repeating calendar structure — weeks that are always high, always low — needs either a like-for-like comparison against the same week in previous years or explicit modelling, which is its own topic. Known one-off calendar events should simply be annotated and exempted in advance; a holiday week is not an anomaly, it is a Tuesday for the calendar. ## Reading more than single points Bands are not only about individual excursions. A run of several consecutive weeks on the same side of the centre line, or a steady march in one direction, is evidence of a shifted process even while every point is technically inside the limits — because under a stable process, points should scatter on both sides at random. Formal machinery for detecting a shifted level is its own subject; at the level of a monitoring chart, the practical rule is that a persistent one-sided run deserves a look. ## Operating the band Backtest before you deploy: run the proposed limits over the last two years and count how many weeks would have fired, and check which of the historically known incidents it would have caught. That converts a guess about k into an observed workload. Then keep the band honest — recompute periodically, record what each alarm turned out to be, and widen or tighten based on the actual hit rate rather than on the first arithmetic you did. A band nobody trusts is worse than no band, because the alarm still costs attention while carrying no information.