Targets and Thresholds
Zones, bands and the art of the achievable
Targets anchor KPIs; thresholds add alarm zones. Tensions between achievable and aspirational, hard-coded vs data-driven, and traffic-light conventions are the design decisions.
What you will learn
- Set targets with direction and basis
- Define threshold bands (green/amber/red)
- Keep targets data-driven, not hard-coded
What is this?
A target is the number a KPI aims for; thresholds define the status bands around it (red/amber/green). Targets come from plans, benchmarks, optimization models or historical baselines; thresholds encode 'what does off-track look like?' Design decisions: signed direction, how bands are set, and keeping them data-driven so they're editable without a code release.
Why do you need it?
- Without thresholds, '100→93' means nothing — is that alarm or noise?
- Aspirational vs achievable targets change the message ('stretch' vs 'miss').
- Data-driven targets survive re-forecasts, unlike hard-coded constants.
- Threshold design is the difference between useful alerts and alert fatigue.
Mental model
A speedometer with redzone and fuel light
Targets and thresholds
The gauge has a limit line (target), a slower amber zone (close to limit) and a red light (act now). Drivers respond to zones, not raw numbers. The BI dashboard's traffic light is the same system: bands tell you 'get comfortable', 'watch', or 'stop'.
How it works
- Target direction: higher-is-better vs lower-is-better default rules the delta sign.
- Target basis: plan, benchmark, forecast, or baseline — each with documented source.
- Band definitions: percentage-off-target (95-100% green) etc., configured centrally.
- Data-driven targets: held in a target table, joined to context (per region, per period).
- Alerting: crossing a threshold triggers paging/notifications with owner escalation.
Target, bands and the alarm path.
Examples
Thresholds as a config table
targets (data-driven): metric | region | period | target | direction revenue | EU | 2026-Q1 | 300000 | higher_is_better bands: revenue EU Q1: green: value >= 0.95*target amber: 0.85*target .. 0.95*target red : < 0.85*target alert: crossing red pages owner; amber sends digest.Targets and bands live in tables; the dashboard just reads status. Re-forecast = update a row, not redeploy code.
In production
- A sales KPI re-targets per quarter via a target table; bands flag regions to recover.
- An SLA KPI uses lower-is-better bands with amber at 92%, red at 90%.
- Threshold crossing alerts page the owner while amber digests go weekly.
Best practices
- Store targets and bands as data, with decimal-direction semantics.
- Document the target basis — plan vs forecast — so renegotiation isn't cryptic.
- Prefer table-driven thresholds over IF-constants in measures.
- Bounded alerting: red pages, amber progresses, green is silence.
Common mistakes
- Hard-coded targets in seven measures — re-planning means a code release.
- Direction-agnostic targets that flash red on improvement.
- Amber used as 'nothing special', so everyone stops trusting bands.
- Maxed alerting → every red emails everyone; alert fatigue kills the signal.
Debugging tips
- KPI red but improving → check direction/flag logic.
- Band flapping (green/red scrolling) → add a hysteresis or trailing-window smoothing.
- Targets stale → the target table wasn't refreshed; verify its own freshness.
Interview checkpoint
Hands-on lab
- Store targets data-driven with direction
- Compute band status per rule
- Wire a bounded alert condition
Model Targets, Bands and Alerts in SQL
45 min · intermediate
Quick quiz
How should threshold bands typically be stored?
An amber zone should be rare enough to still mean something.