KPI Definitions and Ownership
Owned numbers beat beautiful numbers
A KPI is decision-grade only when it has a definition, an owner and a review cadence. KPI registries make numbers auditable, replace arguments and keep dashboards alive.
What you will learn
- Compose a KPI registry entry
- Assign ownership and cadence
- Version definitions through changes
What is this?
KPI governance formalizes the discipline from business-metric fundamentals: every KPI lives in a registry with a definition, formula, source, owner, target and review cadence. Changes are versioned so a number's meaning can be traced backward in time. A registry turns 'my dashboard is wrong' into 'the definition changed in v3 and the old chart was mislabeled'.
Why do you need it?
- Shared definitions remove whole classes of disagreement.
- Ownership means someone is accountable for freshness and correctness.
- Cadences force metrics to be reviewed, not just rendered.
- Versioning makes changes auditable and reversible.
Mental model
A passport
A governed KPI
A passport names the holder, the country, the validity dates and the issuing authority. A KPI entry names the metric, its formula, its source, its owner and its review date — identification and accountability in one document.
How it works
- The registry is a table or doc listing every KPI with fields.
- Each KPI references one source query that is replicated nowhere else.
- Ownership is a person or small team, not a group alias.
- Review cadence (weekly/monthly) matches how often the decision is made.
- Definition changes bump the version and log the diff.
KPI lifecycle under governance.
Examples
A registry row with governance fields
KPI: Activation Rate (first-paid within 14 days)Owner: growth-analytics (Ada Vince)Cadence: weekly review, exec narrated monthlySource: events_fct join subs (activation_v1.sql)Version: 4 (chg: exclude invite_referral segment earlier)SQL: 100% AS seen in activation_v4.sqlLast review: 2026-09-15Registry rows carry the exact query, the named owner, the cadence and version history, so the KPI can be audited down to the SQL diff whenever two decks disagree.
In production
- An analytics team maintains a 40-entry KPI registry in a shared data store; every dashboard pulls definitions rather than hard-coding formulas.
- A finance-adjacent product group versions its LTV definition so a churn-model change never silently rewrites history.
- An ops leader runs a weekly cadence with owners walking through their one owned KPI, green or red.
Best practices
- One source query per KPI; dashboards bind to the metric, never to a copy.
- Require a named owner and a review cadence at creation.
- Automate the registry's freshness checks (source health, drift flags).
- Publish a changelog when any definition is bumped.
Common mistakes
- Excellent definitions with no owners, so nothing ever gets fixed.
- Registry entries that copy a formula from an old dashboard — drift encoded.
- Review cadences too long to catch problems (monthly for a daily decision).
- Version fields stored but never maintained.
Common issues
A KPI is green but reality is redThe definition misses a segment the field hits
Review with the owner, tighten the WHERE clause and bump the version.
Nobody responded to the red SLAOwner field stale or a group alias
Replace group aliases with a named human owner.
Charts argue because two versions are liveDashboards bound to old versions after a definition change
Deprecate old versions and force dashboards onto the current definition.
Debugging tips
- When numbers disagree, open the registry's version field and diff the SQL.
- Check the 'last reviewed' date before trusting an old KPI.
- Automate an alert when the source query's row count changes.
- Run a quarterly registry audit for orphan KPIs nobody owns.
Interview checkpoint
Quick quiz
Which role must a KPI have to be decision-grade?
Versioning a KPI definition erases the old meaning forever.