Metric change request workflow for shared KPI definitions
Problem
A KPI, short for key performance indicator, such as attendance or ticket revenue, is defined once, inside a transformation model, by whoever last touched it. When the ticketing team decides comps should count and the finance team decides they should not, both edit the same model independently, or one edits it and never tells the other. The request usually arrives as a Slack message to a data engineer, who makes the change because it is quick, without checking which of the dozen dashboards downstream reference that field. Two departments then report different attendance figures for the same fixture at the same board meeting, and both numbers trace back to a real, defensible change that nobody outside the two people involved knew had happened. The only record of the decision, if one exists, is buried in a private message thread.
Product idea
A change-request workflow that sits in front of the transformation layer rather than replacing it. Anyone can propose a change to a metric's definition, but the request must name the metric, the proposed change and the reason. The tool looks up the metric's registered owner and every dashboard or report tagged against it, and routes the request to all of them for sign-off. Nothing merges into the model until every affected owner has approved or the request is withdrawn. Each decision is logged with who approved it, when, and why, so the next person proposing a similar change can see the history instead of re-litigating it. It deliberately does not calculate the metric itself or touch the warehouse: it is a gate in front of the change, not a rebuild of the pipeline.
Who it is for
Analytics engineers and data engineers who implement metric changes, the head of data who owns definitions, and insight analysts and department heads whose dashboards depend on the outcome.
Possible first version
A web form for submitting a metric change request against a manually maintained metric registry (name, current definition, owner, list of known downstream reports), routed by email to the owner and each listed consumer for approval, with a running log of decisions and their rationale. Approvals are recorded manually rather than auto-detected from the warehouse or catalogue tool. Out of scope for v1: automatic lineage discovery from the transformation layer or BI tool, and any enforcement that blocks a model deployment. The registry starts as a spreadsheet import, not a live sync.
- Build classification
- Workflow application
- Rough effort
- 6-week first release
- Roles involved
- Head of data, Analytics engineer, Insight and BI analyst, Data engineer
- Relevant to
- Professional club, League office, Federation / governing body, Venue & stadium operator
- Systems in play
- Data warehouse and BI tool, Data catalogue and quality monitoring, Transformation and modelling frameworks, Messaging apps and email
- Product framing
- Automate a workflow
Questions we get asked
We don't have a list of who owns each metric or which dashboards use it. How do we even start?
You start with whatever you already know, even if incomplete: the handful of metrics that have caused a disagreement before are usually the ones worth registering first. The tool does not require a complete catalogue on day one. It makes the gaps visible, because a metric with no listed owner or no listed consumers is exactly the case worth flagging rather than hiding.
Does this replace our BI tool or the transformation layer where the metrics actually live?
No. It sits in front of both. The transformation framework still calculates the metric and the business intelligence tool still displays it; this only gates the moment someone wants to change the definition. If your team already has strong change control through code review on the transformation repository, this may be redundant. It earns its place where that discipline exists on paper but does not survive a Friday afternoon request.
Our data engineers already know not to change a shared metric without asking around. Why formalise it?
That informal check works until the person who usually asks around is on leave, or the request looks small enough to seem safe. The failure this addresses is not bad intent, it is that nobody currently has a complete list of who to ask. A workflow that surfaces the full list of affected owners catches the case the informal version misses, which is usually the one that costs a board meeting.
Who has to keep this updated once it exists?
The metric registry needs an owner, typically the head of data or an analytics engineering lead, who adds new metrics and retires old ones as the warehouse changes. Left unmaintained, the registry drifts and the tool starts routing requests to owners who have moved teams, which is a real ongoing cost worth weighing against how often definition disputes actually happen in your organisation.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Access permission drift monitor for warehouse and reporting toolsA monitor that compares entity access rules across the identity provider, warehouse and reporting tool, and alerts a named owner when they drift out of sync.
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.