Data and reporting
See the number move before the month-end report does
Conversion rate slips on the 4th. The month-end report shows it on the 3rd of the following month, and by then nobody remembers what changed. Watching daily is not hard. Watching daily without becoming background noise is the hard part, and it is entirely a question of where the threshold sits. An alert that fires most mornings gets muted within a fortnight, and a muted alert is worse than no alert — it leaves everyone believing something is watching.
- Triggers
- Two
- Runs
- Daily, band reviewed quarterly
- Stack
- 3 tools
- Durable execution
- Not required
The flow
The top track accumulates the history that defines normal. The bottom track re-derives the band from that history, compares yesterday against it, and stays silent unless the move persists.
Every morning
n8n schedule
Pull yesterday's figures
n8n · Make
Append to the history table
Sheets · Airtable
Every quarter, reset the band
Manual
Compute the normal band
n8n · Make
Outside the band, two days running?
n8n IF
One line: what moved, how far
Slack · WhatsApp
Stay quiet
—
Step by step
- 01
Every morning
n8n scheduleOnce a day, after the platforms have settled overnight. Polling hourly does not detect anything sooner; it only multiplies the chances of reacting to a figure that is still being written.
- 02
Pull yesterday's figures
n8n · MakeConversion rate and CPM, per account, one value each. Watching thirty metrics produces an alert almost every day by arithmetic alone, before anything is actually wrong.
- 03
Append to the history table
Sheets · AirtableOne row per metric per day, kept indefinitely. The history is not an archive here — it is the input that decides what counts as unusual, so a watch with three weeks of history has almost nothing to compare against.
- 04
Every quarter, reset the band
ManualThe second trigger, and the one that keeps this usable. A business that has genuinely changed — new channel, new price — has a new normal, and a band computed against the old one fires forever. Re-fitting it is a decision, so it stays on a human.
- 05
Compute the normal band
n8n · MakeTake the same weekday across the trailing weeks, and set the band from how much that figure already bounces around — the common convention is three standard deviations either side of its mean. Do not pick a round percentage. A metric that swings 20% week to week will trip a 10% rule constantly, and a steady one will hide a real 8% move behind it.
- 06
Outside the band, two days running?
n8n IFThe second day is the part that makes the difference. A single point outside the band is expected from time to time even when nothing has changed; requiring persistence removes most of that at the cost of one day's delay, which is a trade worth making against a month.
- 07
One line: what moved, how far
Slack · WhatsAppThe metric, yesterday's value, the band it left, and how long it has been out. Say nothing about why — this detects change, not cause. Attaching a guessed explanation is how an alert stops being trusted, because the guess is wrong often enough to discredit the detection that was right.
What the data will not tell you
The first sets how firm yesterday's number is. The next two are why the threshold is derived rather than chosen, and why the same figure on a Monday and a Saturday are not the same figure.
Meta's ad insights "refresh every 15 minutes and do not change after 28 days of being reported". Yesterday's figure is therefore provisional — an alert fired on it is being fired on a number that has not finished settling, which is one more argument for requiring a second day before anyone is told.
Meta Marketing API — Insights best practicesThere is no correct threshold in the abstract; it is derived from the spread of the process itself. "It is an acceptable practice to base the control limits upon a multiple of the standard deviation. Usually this multiple is 3." And limits set at a given probability come with a stated false-alarm rate — at 0.001 limits, "the probability of a point falling above the upper limit would be one out of a thousand" when nothing is actually wrong. Tightening the band buys earlier detection and pays for it in false alarms, which is the trade that decides whether the alert survives.
NIST/SEMATECH e-Handbook — What are control charts?Data taken over time "may have an internal structure (such as autocorrelation, trend or seasonal variation) that should be accounted for". A band fitted across all days at once will treat every weekend as an anomaly and miss a genuine weekday move, which is why the comparison is against the same weekday rather than against the last thirty days flat.
NIST/SEMATECH e-Handbook — Introduction to time series analysisSheets allows 300 read and 300 write requests per minute per project, and 60 per minute per user per project; the quotas refill every minute and there is no daily cap on top of them. Re-reading the full history on every run is well inside that; reading it once per metric per account is how you leave it.
Google Sheets API — Usage limits
When this is not worth building
Three cases where the upkeep costs more than the late discovery.
You have less than a few months of daily history. The band is computed from that history, so with a short run the watch either fires at everything or at nothing, and both outcomes teach people to ignore it.
The daily volume is small enough that ordinary randomness moves the rate by a third. At that size almost every day is unusual, and no threshold separates a real change from an ordinary Tuesday.
Nobody can act on the morning it fires. Detecting a move three weeks earlier than the month-end report is only worth the upkeep if somebody is in a position to look that day; otherwise you have built a faster way of learning the same thing at the same time.