Finance and performance
KPI Anomaly & Driver Analysis
Modeled evidence on what is driving a metric, routed to the forum that owns it, with every decision logged and checked against what it was expected to do.
The problem
A metric moves and the explanation arrives as a one-off analyst deck. Drivers shift from week to week with the noise, decisions go unrecorded, and nobody checks whether the action taken did what it was meant to.
Who owns it
The executive whose forum it is, often the CFO or COO, with a named decision owner for each driver domain.
What it learns from
- The systems of record behind the metric, such as the ledger, ERP, or CRM, with lineage
- The metric's own history
- Customer feedback text, where it explains the metric
- The decision log itself
How it works
Predict, decide, act, measure
The same four steps in every solution, in this order, each one visible to the team that owns it.
- 01
Detects anomalies and explains drivers
Anomaly detection watches the metric series within an alert budget sized to what the forum can handle. Driver analysis on point-in-time data decomposes each move by segment with confidence intervals, and every driver is labelled a hypothesis, not a cause.
- 02
Decides in the forum that owns the metric
Each recommendation arrives as a proposed action with its expected effect and its confidence. The accountable owner decides, and a high-stakes driver gets an experiment before money moves.
- 03
Acts through the decision log
Accepted actions are logged with an owner, a metric, and a check-in date, and tracked in your ticketing system. Reports reach the BI tools the team already uses.
- 04
Measures expected against realized effect
Every adopted decision is checked at its check-in date: what it was expected to do against what it did. The forum sees how honest its own forecasts were.
What it moves
The business levers
Decision quality
Costly decisions caught before they are made, and good ones found earlier.
Earlier action
Anomalies surface while there is time to respond, not at quarter end.
Analyst time
Recurring editions replace one-off decks.
Institutional memory
The decision log keeps what was decided, by whom, and what happened.
Proof
How the return is proven
The return is the tracked outcome of the decisions the forum adopted, measured against what each was expected to do and stated against the return model agreed up front. Decision adoption and forecast honesty are reported in every edition.
What you see: the ROI readout
Every solution produces the same readout, assembled from the system's own records rather than built by hand.
Correctness
The checks the pipeline passed on your own data: leakage, point-in-time, and entity resolution.
Incrementality
The incremental effect against the holdout or equivalent design, with its confidence interval.
Return
The measured return against the investment, set beside the return model agreed before work started.
Guardrails
Complaints, cost, margin, fairness, and contact limits, each shown against its bounds.
Audit extract
Every score, action, and outcome, with the model and policy versions behind it.
Governance
What is governed
Access, approvals, and the audit trail are part of the solution, not a review step added at the end.
Identity-scoped access
Sensitive drivers, such as compensation, are restricted by identity, and the analysis never makes claims about individual people.
Approval gates
Follow-up experiments need the decision owner's approval.
Audit trail
Each edition is reproducible from versioned data and code, so what changed since the last edition can be computed.
Decision record
The decision log is retained as a governed record, with every decision, its owner, and its outcome.
Why it holds up
Trained on your data, framed by the outcome
This solution trains models on your own data, checks every stage from data to decision, and is measured against the outcome it was built for. Because its predictive power is measured, it also shows the drivers behind the metric, so your team can fix causes as well as act on scores.
Why solutions hold upStart with one decision
Bring the problem and the systems your team works in. We scope the first solution with you, agree how its return will be measured, and run it in production with your people.