Metrics layer

What is a metrics layer?

A metrics layer is the central place where business metrics are defined once and reused everywhere. Revenue, active customers, gross margin, churn, pipeline, stock cover, and SLA performance get a shared definition instead of being rebuilt in every dashboard and spreadsheet.

The metrics layer sits between your data warehouse or lakehouse and the tools that consume numbers. It usually stores definitions, relationships, dimensions, calendars, filters, and security rules. The underlying data stays in the warehouse. When a tool asks for a metric, the layer translates that request into a query and returns the result.

You may also hear the terms semantic layer or metrics store. The vocabulary differs by vendor, but the practical question is the same: where is the metric defined, and can every tool use that definition without copying it?

The problem it solves

Without a shared layer, the same metric often exists in several places. Finance calculates revenue in a spreadsheet. Sales has a Power BI measure. Product has a SQL query. An analyst copies the logic into a notebook. Someone forgets to exclude refunds, someone else filters a different date field, and the meeting turns into a debate about which number is right.

A metrics layer moves the logic into a governed model. If the definition changes, the change happens once. Reports, notebooks, embedded dashboards, and AI assistants can all ask for the same metric and receive the same result.

This is especially useful when metrics outlive a single BI tool. A company may show the same active-customer count in Power BI, Excel, a customer portal, a board pack, and an AI assistant. Copying the formula five times is where disagreement starts.

How a metrics layer works

Metric definitions. Each metric has a name and a calculation. Net revenue might be order amount minus refunds and discounts. Active customer might mean at least one paid order in the last 90 days.

Dimensions. Metrics are grouped by things such as date, region, product, customer segment, sales channel, or team. The layer knows which dimensions make sense for each metric.

Relationships and joins. The model describes how fact tables and dimension tables connect, often based on dimensional modelling.

Serving interfaces. Tools connect through SQL, REST, GraphQL, JDBC, Python, semantic APIs, or native connectors, depending on the product.

dbt Semantic Layer, Cube, LookML, MetricFlow, and Power BI semantic models all approach this problem from different ecosystems. dbt focuses on metric definitions in a dbt project and exposes them through semantic-layer interfaces. Cube exposes a semantic layer through SQL, REST, and GraphQL APIs. Power BI semantic models define measures and relationships mainly for the Microsoft reporting stack.

Example: active customer

Suppose your business agrees that an active customer is a customer with at least one paid order in the last 90 days. The metrics layer stores that definition, together with dimensions such as month, country, product line, and account owner.

After that, several tools can use the same definition:

• A Power BI report shows active customers by country.

• A spreadsheet pulls active customers by month for finance planning.

• A notebook compares active-customer growth with support tickets.

• An AI assistant answers a sales question using the approved definition instead of guessing from raw tables.

If leadership changes the rule from 90 days to 60 days, the team updates one metric definition and reviews the downstream effect.

Metrics layer and Power BI semantic models

In a Microsoft environment, a Power BI semantic model already does part of the metrics-layer job. It defines relationships, measures, DAX calculations, security rules, and descriptions. Multiple reports can reuse one certified model and get the same numbers.

The difference is reach. A Power BI semantic model is strongest inside Power BI, Excel, Fabric, and tools that understand the Analysis Services model. A dedicated metrics layer is usually designed to serve several frontends through generic APIs or SQL-like interfaces.

If your reporting world is mostly Microsoft, a well-managed semantic model may be enough. If the same metrics must serve Power BI, a web application, notebooks, another BI tool, and AI agents, a tool-neutral metrics layer starts to make more sense.

Metrics layer and headless BI

Headless BI is the architecture where metric definitions are separated from the visualisation layer. The metrics layer is the part that makes this possible. Dashboards become one consumer among many, rather than the place where business logic lives.

That separation helps with embedded analytics, tool migrations, AI on business data, and shared reporting across departments. It also adds a component that needs ownership, testing, monitoring, performance tuning, and access control.

What to watch out for with a metrics layer

Definitions are people work. The layer cannot decide what revenue means. Finance, sales, operations, and leadership still need to agree.

Model too much and nobody uses it. Start with the metrics that cause repeated disagreement or appear in several tools. One-off analysis metrics can stay local.

The layer can become a bottleneck. Slow queries, missing dimensions, unclear ownership, or weak documentation will frustrate every connected tool.

Security must travel with the metric. A metric result may still reveal sensitive information. Permissions, row filters, and aggregation rules need the same attention as the calculation.