Microsoft has introduced a Metrics Layer into Fabric and Power BI, and if you've read anything else I've written this year you'll know why I sat up. Back in January I predicted the semantic model — the layer where you define what your numbers actually mean — would become the real battleground of 2024. A dedicated Metrics Layer is that prediction turning into a product. So I want to look at it clearly: what it genuinely gives you, and the thing it very much doesn't, which is the thing that mattered all along.

Let me start with the plain description. A metric here is a reusable, centrally-defined KPI — "Revenue", "Active Users", "Gross Margin" — defined once, with its logic and rules attached, and then consumed everywhere: in reports, in dashboards, by Copilot, by whatever asks for it. Instead of the number "revenue" being re-implemented slightly differently in fourteen reports by eleven people, there's one canonical definition and everything references it.

Why this is worth being excited about

The problem it targets is real, expensive, and nearly universal. Walk into almost any organisation and ask three teams for "this month's revenue" and you'll get three numbers — not because anyone's incompetent, but because each team quietly built the calculation themselves, made slightly different choices about what counts, and has been faithfully reporting their own version for years. The disagreement is invisible until two of those numbers land in the same meeting, and then it's a credibility crisis.

A Metrics Layer attacks that at the root. Define the metric once, govern that definition, and every consumer draws from the same source of truth. Concretely, the wins are:

  • One definition, many surfaces. The measure a report shows, the number Copilot returns when someone asks in plain English, the figure on the executive dashboard — all resolve to the same governed definition. That consistency is exactly what makes an AI assistant trustworthy, incidentally: Copilot is far safer when there's one thing "revenue" can mean.
  • A place for the rules to live. Real KPIs have rules — which segments count, how returns are handled, what the time boundaries are. A Metrics Layer gives those rules a governed home instead of leaving them scattered across report files and tribal knowledge.
  • Change in one place. When the definition of a KPI legitimately changes, you change it once and everything inherits it, rather than hunting through dozens of reports hoping you found them all.

This is genuine governance infrastructure for the part of analytics that most needed it. I'm glad it exists, and I think it'll matter.

The part the feature can't do for you

And now the caution, which is the same caution I keep arriving at from different directions this year, because it keeps being true. A Metrics Layer gives you a place to store the agreed definition. It does not produce the agreement. And the agreement was always the hard part.

Think about what it actually takes to define "Active User" once, canonically, for the whole organisation. It means getting the people who currently, quietly, mean different things by "active" — the product team, the finance team, the marketing team — into a room to hammer out a single definition they'll all live with. That's not a modelling task. It's a negotiation, often a mildly political one, because someone's existing number is about to be declared not-the-official-one, and people are attached to their numbers.

The Metrics Layer is waiting, helpfully, at the end of that negotiation to store whatever you agreed. It offers no help with the negotiation itself. And so the failure mode is predictable and I'd bet money we'll see plenty of it: organisations that stand up the Metrics Layer, feel governed, and then either fill it with definitions nobody actually agreed on — laundering the old disagreement into a shiny central location — or never populate it properly because the underlying arguments never got had.

A Metrics Layer is a beautiful cabinet for your agreed definitions. It will sit empty, or full of contested numbers wearing an official badge, until the humans do the unglamorous work of actually agreeing.

How to use it well

So the tool is good and the tool is not the point — which means using it well is mostly about doing the human work the tool assumes you've already done. My advice:

Start with your contested metrics, not your easy ones. Find the two or three KPIs where you know teams disagree — the ones that cause the awkward meetings — and do the hard work of getting the relevant humans to agree a single definition, out loud, on the record. Then enshrine that hard-won agreement in the Metrics Layer, where its being canonical is enforced by the platform rather than by your vigilance. The layer's job is to make the agreement durable and consistently applied. Your job — the part no feature ships — is to produce the agreement in the first place.

Do it that way and the Metrics Layer earns its keep: it takes the expensive, fragile consensus you built between people and makes it the automatic default everywhere, so you don't have to re-fight the same battle every quarter. Skip the human work and reach for the tool first, and you'll have industrialised your disagreements — exactly the outcome I warned about in January, now with better tooling to make the wrong numbers consistent. The battleground was always the definitions. Microsoft just gave you somewhere to keep the treaty once you've signed it.