Building a semantic layer for consistent metrics across business units

The meeting happens at almost every large organisation. The CFO's slide says quarterly revenue is $847 million. The CROCROConversion Rate Optimization (CRO) is the systematic practice of increasing the percentage of users who complete a desired action, using data, testing, and user research.View full definition →'s deck says $891 million. Both figures are technically correct, because one team books revenue on contract signature and the other on cash receipt. The data is fine. The definitions are not. And when this happens in a board presentation, the credibility damage lands squarely on the CDO.

This is precisely the problem a semantic layer solves. In 2026, with more business units running their own analytics stacks, their own BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → tools, and increasingly their own AI-generated reports, metric drift has accelerated. The answer is not more governance meetings. It is a single, enforced definition layer that sits between your data sources and every consumer of that data.

Building the layer: a concrete sequence

Step 1: audit your current metric landscape before writing any code

Start by collecting every significant metric definition currently in use across business units. Assign a small cross-functional team, two analysts from Finance, one from Marketing, one from Operations, and pull every definition of your top twenty business metrics from dashboards, spreadsheets, and BI tool calculated fields. The goal is a "metric collision mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →": a document showing where the same metric name produces different numbers in different systems.

At Airbnb, the data team published a widely cited internal case study (referenced independently by multiple engineering blogs between 2020 and 2022) describing exactly this exercise. They found dozens of conflicting definitions for metrics like "nights booked" before building what they called a certified metrics layer in their internal tool, Minerva. That audit phase was not optional; it was where the actual business logic surfaced.

Step 2: choose the right tooling for your architecture

A semantic layer can be implemented in several ways. dbt Metrics (now evolved into the MetricFlow framework within dbt Labs' platform) lets you define metrics as code alongside your transformations. Tools like Looker (now part of Google Cloud) embed the semantic layer in LookML, centralising logic in the BI layer. Platforms like AtScale or Cube.dev sit as a standalone layer across multiple query engines.

The right choice depends on your existing stack. If your team already uses dbt heavily, MetricFlow is the lowest-friction path. If you have multiple BI tools consuming the same metrics, a standalone semantic layer like Cube.dev gives you tool-agnostic consistency. Avoid the temptation to pick the most technically elegant solution when your analysts are not going to adopt it. Adoption is the only thing that matters here.

Step 3: define a governance model for metric ownership

Each certified metric needs a named owner, not a team, a person. That owner approves changes to the definition, documents the business rationale, and signs off on deprecations. This sounds bureaucratic until you realise that without it, a well-intentioned analyst quietly changes the revenue filter logic and breaks three months of trend comparisons.

Build a simple changelog into whatever system you use. dbt supports documentation natively. Looker has a content validation framework. If you are using a lighter-weight approach, a version-controlled YAML file in Git is entirely adequate. The key requirement: no metric definition changes without a pull request review by the metric owner and a downstream impact check.

Step 4: integrate with the tools business units actually use

A semantic layer nobody queries is just documentation. Push certified metric definitions into the tools your business units use daily. If Marketing runs on Tableau, configure the semantic layer as a certified data source that Tableau connects to. If Finance uses Excel with live connections to your warehouse, ensure the certified metric names appear in the query interface. Most modern semantic layer tools expose a SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → or REST APIREST APIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → that BI tools can consume natively.

One concrete integration worth prioritising: ensure your organisation's AI-assisted analytics tools, whether that is Tableau Pulse, Microsoft Fabric's Copilot features, or any other natural language query interface, are pulling from your semantic layer rather than raw tables. These tools will otherwise generate their own on-the-fly metric logic, which is a fast path back to metric chaos.

Pitfalls that will kill this initiative

The most common failure mode is trying to define every metric before launching. Teams spend four months in workshops, achieve nothing deployable, and lose stakeholder confidence. Start with five to ten metrics that cause the most friction, ship those as certified definitions, and expand from there. The early wins build the political capital to continue.

The second failure mode is centralising ownership too aggressively. If every metric definition must be approved by the central data team, business units will route around you and build their own shadow definitions. Metric ownership should sit with the business domain. Finance owns revenue definitions. Marketing owns campaign attributionattributionA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results.View full definition → definitions. The data team provides the infrastructure and enforces the process, not the content.

A subtler trap: semantic layers that codify bad definitions. If your "active user" definition has been wrong for two years, encoding it into the semantic layer makes it harder to fix, not easier. Before certifying any metric, validate the business logic with the domain owner, not just the technical logic.

Finally, watch for vendor lock-in. Several semantic layer vendors, including some who publish benchmark studies on metric consistency ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition →, have a commercial interest in portraying their tool as the only viable path. Treat those claims accordingly and cross-reference with independent analyst assessments from firms like Gartner or Forrester when evaluating platforms.

Quick wins to start this week

• Pull the three metrics that caused disagreement in your last executive review. Document the competing definitions side by side, with the name of each business unit using each variant.
• Identify which of your current BI or transformation tools already supports semantic layer functionality you are not using. dbt users almost certainly have MetricFlow available today.
• Name a metric owner for each of your top ten business metrics. Send a one-paragraph email to each owner explaining their role. This costs nothing and starts the governance muscle before any tooling is in place.
• Block one hour with your CFO and CRO to walk through the metric collision map. Executive sponsorship at that level is what makes business units comply.

A semantic layer is not a technology project. It is a contract between business units about what words mean, enforced through technology. The CDOs who have made this work treated the social and political work as the main effort and the tooling as the supporting infrastructure.