Data volume anomaly detection on a business with one peak a year

Somebody set a rule years ago that alerts when the registration table takes fewer than 1,000 rows in a day. It made sense at the time, because the show was three weeks out and 1,000 a day was quiet. Now it fires every day from May to November, and the January version of the same rule fires never, including the week the feed from the paid search landing page broke and cost 900 registrations before anyone noticed.

Data volume anomaly detection is worth building properly on an events business because the naive version is worse than nothing. It teaches people to ignore the channel during the eight months when it cries wolf, and then it is silent during the four when it matters.

Why does a flat row count threshold fail here?

Because the quantity being tested moves by an order of magnitude on a schedule everybody in the business already knows.

Daily registration volume on a large annual show might sit in the low hundreds nine months out, climb through the campaign, and reach several thousand a day in the final fortnight. Badge scan volume goes from zero to tens of thousands an hour and back to zero inside four days. Exhibitor contract rows cluster around the space draw and then nearly stop.

A single threshold has to be either low enough to stay quiet in the trough or high enough to catch a problem at the peak, and no number is both. What teams do instead is set it for the peak, live with the noise, and eventually mute it, which is how the outage above went unseen for four days.

The variable that explains almost all of the movement is days to show open. Index on that and the problem becomes tractable, because the same day of the same phase of a prior edition is a genuinely comparable observation.

Build the expected range from prior editions

Take the metric you want to watch, which for registration is rows created per day, and align every edition on days before show open rather than on calendar date.

Suppose you are 45 days out from the 2026 edition and you hold three prior editions. At their own day 45 they recorded 512, 604 and 578 registrations. The mean is 512 plus 604 plus 578, which is 1,694, divided by 3, giving 564.67.

Now the spread. The deviations from that mean are minus 52.67, plus 39.33 and plus 13.33. Squaring them gives 2,773.8, 1,547.1 and 177.8, which sum to 4,498.7. Dividing by 2, which is the count less one, gives 2,249.35, and the square root of that is 47.43. So the standard deviation of those three observations is 47.4 registrations.

A two standard deviation band around the mean runs from 564.67 minus 94.86 to 564.67 plus 94.86, which is 469.8 to 659.5. Today's count is 402. That sits below the band, and it is worth an alert.

Every step of that is arithmetic somebody can check on the back of an envelope, which matters more than it sounds. A volume alert that nobody can reconstruct gets argued with, and an alert that gets argued with gets muted.

How many standard deviations should fire the alert?

Two is the number people reach for, and the reason to think about it rather than inherit it is that your sample is tiny.

The convention comes from statistical process control. The NIST and SEMATECH engineering statistics handbook sets out the standard practice: "Usually this multiple is 3 and thus the limits are called 3-sigma limits", and it explains that "For normal distributions, therefore, the 3 sigma limits are the practical equivalent of 0.001 probability limits". The handbook is equally clear that the choice depends on how much risk the people running the programme are willing to take, and that non-normal data changes the false alarm rate substantially. It gives a worked case where the risk of exceeding the upper limit by chance rises from 0.001 to 0.009 on Poisson distributed data.

Two things follow for an events business. Manufacturing control charts are built on hundreds of observations, and yours are built on three or five, so the standard deviation you computed above is itself an estimate with a wide interval around it. Treating 47.4 as a known quantity overstates what you have. And daily registration counts are counts, so they are closer to Poisson than to normal, which pushes the real false alarm rate above the textbook figure.

The practical response is to widen the band, prefer a warning over a page, and where you have fewer than five editions to use the minimum and maximum of prior editions with a margin rather than a computed sigma. Say in the alert that the band came from three observations. It is a smaller claim and it is the true one.

Scale for a show that is growing

Raw counts compare badly across editions when the show itself has changed size, and most shows have.

The fix is to normalise each prior edition by its own final registration total before averaging. If the 2023 edition finished at 14,200 registrations, its day 45 figure of 512 becomes 3.61 per cent of final. Do the same for the other editions, average the percentages, then multiply by your current forecast of this edition's final total to get an expected count in rows. That converts an absolute comparison into a shape comparison, which is what you actually meant.

The catch is that this makes the band depend on a forecast, and a wrong forecast moves the whole band. Forecasting the curve is a method in its own right and belongs to cluster O, so the pragmatic compromise for a monitoring check is to normalise by the count at a fixed reference point instead, such as registrations at day 90, which is known rather than predicted.

Volume is one of the five pillars of data observability that Barr Moses of Monte Carlo set out in December 2020, listed third after freshness and distribution and before schema and lineage. Her framing is worth keeping in mind: volume speaks to the completeness of the tables and the health of the sources, and a table that suddenly holds a fraction of what it held is a signal on its own terms. On an events business the phrase "suddenly holds a fraction" needs the calendar attached before it means anything.

Make the alert carry its own evidence

An alert that says volume is anomalous starts an investigation. An alert that carries the comparison ends one.

Put six things in the message: the table, the event and edition, the days to show open, today's count, the expected band, and the counts from each prior edition at the same index. Whoever reads it can then see in one glance whether the band is sensible, and the most common outcome of a well built volume alert is somebody replying that the 2024 edition had a promotional email on day 45 and should be excluded from the comparison. That reply is the system working.

One formatting habit pays for itself. Show the prior edition counts as a list in the message, so 512, 604 and 578 sit beside today's 402 without anybody opening a query tool. Most volume alerts are read on a phone by somebody walking between halls, and a number they can compare in their head is the only one they will act on.

Keep a record of which alerts led to action. A check that has fired eleven times and produced one action is calibrated wrong, and the fix is usually the band rather than the metric. This connects directly to detecting the case where zero rows is the correct answer, which K20 handles, because a zero is the extreme end of the same problem and needs its own gate.

Where this stops

The index is only as good as the calendar behind it, and calendars move.

A show that shifts from March to May has a campaign of a different length, and its prior editions at day 45 were in a different part of the year with different competing events and different holidays. The index will happily compare them and produce a band that means nothing. Any show with a date change needs its prior editions inspected by a person before they are used as a baseline, and a launch edition has no baseline at all, which is a genuine gap this method cannot fill.

There is a second and more subtle failure. Volume checks see the total and miss the composition. A day that hits 570 registrations exactly inside the band, made up entirely of one channel because two others stopped reporting, passes cleanly. Catching that needs the same test applied per source, which multiplies your alert count and is the point at which most teams should apply it to the two or three sources that matter rather than to all of them. Removing seasonality with a decomposition instead of an index is a different route to the same goal and K19's subject, and both belong in the quality layer of the unified data record rather than in a dashboard nobody opens.

Start this week by pulling daily registration counts for your last three editions of one show, aligning them on days to show open, and plotting them on one chart. The width of the spread between editions at each point is your band, drawn by eye, and it will tell you immediately whether a computed sigma is worth the effort on your data.