A metric is any number your business tracks. A KPI is a metric you've promoted: it has a target, a named owner, and a direct line to whether the business is winning or losing. A measure, in the Power BI sense, is the calculation that produces a number, the definition written once so it comes out the same on every page. So the three words describe three different layers: measures are how numbers get computed, metrics are which numbers you watch, and KPIs are the few metrics you steer by.
That's the whole answer, and you can use it in a meeting this afternoon. The rest of this post is why the distinction matters when you're buying or building reporting, because the most common reporting failure I see is the three layers collapsing into one: every number treated as a KPI, no number owned by anyone, and the calculations underneath defined slightly differently on every page.
What's the difference in plain English?
Here's the comparison laid out. It's a definitional table, not a statistical one; the examples are generic and the "how many" column is my professional opinion, stated as such.
| Metric | KPI | Measure (Power BI) | |
|---|---|---|---|
| What it is | Any number the business tracks | A metric with a target, an owner and consequences | The stored calculation that produces a number |
| Lives in | Reports, dashboards, conversations | The management meeting agenda | The semantic model |
| Example | Website sessions, orders per day, average basket | Gross margin % against a 40% target, owned by the sales director | The DAX definition of Gross Margin % that every page reuses |
| Has a target? | Not necessarily | Always, or it isn't one | No, it's arithmetic, not ambition |
| Who cares about it | Whoever finds it useful | The leadership team, by name | Whoever builds and audits the reports |
| How many you need | Dozens is fine | A handful, and I'd argue rarely more than ten | One per business concept, reused everywhere |
The layers stack. A KPI is displayed using a metric, the metric is computed by a measure, and the measure lives in one place in the model. When someone challenges the number in a board pack, that stack is the audit trail: from the ambition, through the number, down to the arithmetic.
Why does "KPI" get attached to everything?
Because the word signals importance, and nobody wants their number to sound unimportant. So the sales pipeline count becomes a KPI, then the email open rate, then the number of support tickets closed, and before long the monthly pack has forty KPIs. At which point the term has stopped doing its one job, which was to mark the handful of numbers that matter more than the rest.
The test for whether something is genuinely a KPI is behavioural, not statistical. Does it have a target this year? Is one named person answerable when it drifts? Would leadership change what the business does if it moved sharply? Three yeses and it's a KPI. Anything less and it's a metric, which is not a demotion. Metrics are the supporting cast that explain why a KPI moved; a business with honest metrics and few KPIs is healthier than one with forty "key" indicators and no idea which ones would trigger action.
There's no published survey I'd trust on the "right" number of KPIs, so I'll give you opinion labelled as opinion: across the businesses I've built reporting for, the leadership teams that actually steer by their numbers watch somewhere between five and ten. Beyond that, attention gets rationed, and rationed attention defeats the point of designating anything as key.
What's a measure, and why should a buyer care?
A measure is a Power BI calculation with a name, stored in the semantic model: Gross Margin %, Revenue YTD, Orders Shipped Late. Written once, it produces the same answer on every page, in every report built on that model, filtered whichever way the reader filters it.
The buyer-relevant part is the alternative. When report builders skip shared measures and rebuild the arithmetic page by page, each page carries its own private version of the logic. The versions drift, and eventually two reports answer the same question differently, at which point the meeting becomes an argument about whose number is right. I've written up that failure in six reports, six different numbers, and the root cause is nearly always this: definitions duplicated instead of defined once.
So when you're commissioning reporting, one of the most valuable questions you can ask a supplier is where the definitions will live. The answer you want is one shared model, measures defined once and reused. It's why my reporting system builds put the modelled layer before any report page: the measures are the product, and the report pages are windows onto them.
How should the three layers shape what you build?
Work down the stack, in order, before anyone opens Power BI Desktop.
Start with the KPIs. Which handful of numbers will leadership actually steer by, what's the target for each, and who owns it? This is a management conversation, not a technical one, and it's the hardest step because it forces choices. If the room can't get below twenty, the prioritisation hasn't happened yet, and no dashboard will do it for you.
Add the metrics that explain them. For each KPI, the two or three supporting numbers someone will need when it moves. Margin dropped: was it price, mix or cost? Those diagnostics are metrics. They belong one click behind the KPI, not beside it fighting for attention.
Define the measures once. Every number named in the first two steps gets exactly one definition in the shared model, written down in plain English as well as in DAX, so the same figure appears everywhere it's used and an auditor can trace it to source.
Notice what this sequencing prevents: the report with 200 visuals that answers no particular question. That report is what gets built when step one was skipped and every metric anyone mentioned got promoted to the front page. Design starts with the decision the number serves.
What does this mean for how much reporting you buy?
It ends the month where this series started: the anti-overbuild argument, one more time, from the definitions side.
A business that knows its KPIs from its metrics needs a smaller reporting estate than it thinks. A front page for the handful of owned, targeted numbers. Diagnostic pages behind it for the metrics that explain movement. One model underneath where every measure is defined once. That's not a starter version you'll outgrow; for most small and mid-sized businesses it's the destination, and every page past it costs build money, maintenance money and, most expensively, attention.
So before commissioning anything, run the cheap exercise: list your candidate KPIs, apply the three-part test (target, owner, would-we-act), and see what survives. If the surviving list with owners against it fits on an index card, you're ready to brief a builder, and the brief will be better than most. If working out what state your existing reporting is in comes first, that's a £950 Health Check; it scores whether your measures are consistent and sensibly named as part of the review, which is usually where the metric-KPI confusion shows up in the wiring.
Common questions
What's the difference between a KPI and a metric?
A metric is any number the business tracks. A KPI is a metric that's been promoted to steering duty: it carries a target, a named owner, and leadership would act if it moved sharply. Every KPI is a metric; very few metrics deserve to be KPIs. If a number has no target and no owner, calling it "key" is decoration.
What's a measure in Power BI?
A named, stored calculation in the semantic model, usually written in DAX: Gross Margin %, Revenue YTD and so on. Defined once, it returns the same answer on every report page and under every filter, which is what keeps numbers consistent across an estate. It's an arithmetic definition, not a target, so it's a different thing from a KPI even when they share a name.
How many KPIs should a business have?
There's no honest published magic number, so I'll give you my opinion as opinion: the leadership teams I've seen steer well watch between five and ten. The practical test is that each KPI needs a target and an owner who answers for it. If you can't staff the owner column, the list is too long, whatever the count says.
Can the same number be both a metric and a KPI?
Yes, and the same underlying measure often serves both. Gross margin might be a board KPI with a target, and simultaneously an ordinary diagnostic metric within a product-line page. The measure computing it should be defined exactly once either way. What changes between the two roles is ownership and consequence, not arithmetic.
Why do the same KPIs show different numbers in different reports?
Almost always because the calculation was rebuilt separately in each report instead of being defined once in a shared model, and the copies drifted: a different filter here, a different date boundary there. The fix is structural, not cosmetic: one shared measure per business concept, and every report reusing it.
What's the difference between a KPI and a target?
The target is one component of the KPI. The KPI is the whole package: the number, the target it's judged against, and the owner accountable for the gap. "40% gross margin" is a target; "gross margin %, target 40%, owned by the sales director, reviewed monthly" is a KPI.
Should every measure in our Power BI model appear on a report?
No. A well-built model contains plenty of measures that exist to support others or to answer occasional questions, and only a fraction earn a place on a page. Reports are for the numbers people steer and diagnose by; the model is the full vocabulary. Putting the whole vocabulary on screen is how 200-visual dashboards happen.
Health Check and build prices are from my published Health Check and reporting system build pages, September 2026. All figures exclude VAT where applicable.