Anomaly Detection
Anomaly Detection automatically monitors AI Models, Signals, and Audiences for unusual day-to-day behaviour and surfaces anything that looks off.
It is a monitoring surface, not a configuration tool, nothing about how models, signals, or audiences run is changed here. It's a place to notice a problem early, confirm it against real history, jump straight to the affected item, and mark it as reviewed.
| Cadence | Daily, one automated run per day |
| Areas watched | Models · Signals · Audience |
| Anomaly types | Anomalous Increase · Anomalous Decrease · Missing Data · Error |
| Severity levels | Critical · Important · Informational |
How detection works
One shared set of rules is applied identically to Models, Signals, and Audience, only the underlying metric being measured changes.
Every model output, signal, and audience push has its own history. Rather than comparing today to "the usual day," BPP compares today to the same day of the week over recent weeks, most business processes naturally rise and fall by weekday, so comparing a Tuesday only to other Tuesdays removes that noise.
The baseline
For each individual model, signal, or audience, the expected value for a given day is the average of that same weekday over the previous occurrences. A Tuesday's expected value is the average of the last Tuesdays, not the last calendar days, and not an all-time average.
What counts as an anomaly
Today's actual value is checked against that baseline two ways at once:
- How far off, in percentage terms the gap between today's value and the baseline.
- How unusual, statistically whether today's value falls outside the normal spread of past values for that same weekday, not just whether the number is "big."
A day is flagged as an anomaly if either check trips: the value is 80% or more away from baseline in either direction, or it's statistically unusual enough to be considered a significant deviation (roughly, more extreme than what's seen in 95% of normal weeks). Only one of the two needs to fire, a huge swing that's still statistically "normal" for a volatile item is caught by the percentage rule, and a comparatively small swing on an otherwise very stable item is caught by the statistical rule.
The missing-data exception
If nothing arrives for an item on a given day, the anomaly detection doesn't wait for the percentage or statistical checks; it flags this immediately, and always at the highest severity, Critical.
What gets watched
| Area | What's measured |
|---|---|
| Models | Rows produced by an AI model's output table, each day |
| Signals | Signals sent to a destination, each day |
| Audience | Users sent to a destination as part of an audience push, each day |
Reserved for later: a fourth area, Input Data, already has a tab reserved on the page but isn't active yet. It's intended for monitoring data processed by the reconciliation.
Severity levels
Every anomaly is assigned one of three severities (a fourth, Normal, simply means "no anomaly" and is never shown as a flagged item). Severity is what the daily counters, the tab indicators, and the default view of the page are built around.
| Severity | Meaning |
|---|---|
| Critical | Data is missing entirely, or a value is far outside its usual range. Needs immediate attention, this is the only severity ever assigned to a missing-data case. |
| Important | A value is noticeably higher or lower than expected. Worth reviewing soon, though not necessarily an active incident. |
| Informational | A value has drifted a bit from the usual range. Good to keep an eye on; no action is required on its own. |
| Normal | Within the expected range, not an anomaly, and not something the page ever lists individually. |
Anomaly types
The four distinct kinds of anomaly BPP can raise. Every flagged row on the page carries exactly one of these.
Anomalous Increase
Today's value came in abnormally higher than the item's expected baseline for this weekday, enough to cross the 80%-gap or statistical-deviation threshold on the high side.
Anomalous Decrease
The mirror image of an increase: today's value came in abnormally lower than expected, without dropping all the way to zero.
Missing Data
Nothing arrived at all for that item on that day, even though its history says it normally would have. This is always Critical, BPP doesn't grade how bad a total stoppage is, it just flags it.
Error
This anomaly types is triggered when the respective ai model/signal/audience is in an Error status.
Using the page
Run status
At the top of the page, a status indicator shows the health of last night's automated run: Ready (completed successfully), Running (in progress), or Error (the run itself failed, with the specific reason available on hover). This tells you whether what you're looking at is fresh.
Daily Summary
A headline block for the most recent completed run's date, showing how many Critical and how many Important anomalies were found, alongside an overall status, Action Needed, Review Needed, or No Action Needed, so the state of the platform is legible in one glance without reading a single row. If a run hasn't completed for the current calendar day, this summary is anchored to the last date that did complete, and says so.
Affected Areas
Directly below the summary, one card per area you have access to (Signals / Audience / Models), each listing its most notable issues for the day, up to four, worst severity first, as a quick "what's wrong and where" digest. Clicking a card jumps straight into that area's detail. If nothing notable happened anywhere that day, this section is simply absent.
Areas & filters
Below the summary, the page splits into tabs, one per area you have access to, each carrying a coloured dot if it currently holds any flagged items. Within a tab, three filters narrow the list:
- Date range, defaults to the last 7 days ending on the summary date; can't be pushed back further than 7 days from today.
- Search, free-text match on the item's name (model table, signal, or audience name, depending on the tab).
- Severity, defaults to Critical & Important, the same default the Daily Summary and Affected Areas use, with the option to widen to all severities or narrow to just one.
The anomaly list
Each row is one item, one flagged day. It shows the date, the item's identity (plus, for Signals and Audience, the destination and trigger context), the actual value recorded that day, the baseline it was compared against, the percentage gap with a directional arrow, the statistical deviation score, the anomaly type, and the severity. The item's name links straight through to that model's, signal's, or audience's own page, already filtered to it, the natural next step for investigating further.
Trend view
Any row can be expanded to reveal a bar chart of that item's recent history for the same weekday, with a dashed line marking the baseline it's compared against. Past days are shown in a neutral colour; the flagged day is highlighted in its severity's colour, so it's immediately obvious how far out of line it really is against real history, not just a number in a table.
Reviewing and dismissing
Once an anomaly has been looked at, a user can dismiss it. Dismissing removes it from the list permanently, there's no snooze, no note field, and no way to bring it back once dismissed. The page only ever shows anomalies that haven't been dismissed yet, so the list is always what's currently outstanding, not a full history.
Good to know
- Don't confuse this with schema anomalies. Elsewhere in the platform, a separate warning can appear about tables or fields registered in BPP being out of sync with the underlying data warehouse. That's a structural configuration check, unrelated to this feature, it shares the word "anomaly" but has nothing to do with daily volume monitoring, severities, or the page described here.