The business metrics problem that data quality tools cannot fix

At a telecommunications company I worked with, the sales team and the engineering team both tracked revenue. Both drew from the same data warehouse. When their data analysts presented their figures in the same management meeting, the numbers were close — but not the same.

The difference was subtle. Sales assumed payments received excluding trials, as of invoice date. Engineering assumed all payments received, without any exclusions. Neither team had done anything wrong. Neither had been told the other's definition.

The instinct was to investigate the data. The data was fine. The problem was that nobody in the organisation had formally decided what "revenue" means.

A semantic layer does not fix a data quality problem. It fixes the problem that precedes data quality: the absence of a shared semantic agreement about what the business actually measures.

The semantic layer

A semantic layer is a single, version-controlled definition of business metrics, sitting between the data warehouse and the tools that consume it. Revenue is defined once: payments received excluding trials, as of invoice date. That definition lives in configuration. Tools like dbt Semantic Layer or Cube implement this pattern, and every BI tool, every report, and every AI agent that needs revenue reads from that single source. They cannot diverge because there is only one definition to read.

This changes how self-service analytics works in practice. When a business analyst builds a report, they select a metric; they do not author one. The definition is not theirs to write. The semantic layer holds it, and the BI tool exposes it. The fifth definition of revenue never gets created because the tooling no longer makes it possible.

The investment

The semantic layer is one of the cheaper governance investments a data platform can make, once you account for what business metric inconsistency actually costs. Every management meeting where two revenue figures appear on the same slide and nobody can explain the gap is a meeting that did not advance the roadmap. Every data analyst hour spent reconciling two definitions of the same business metric was not spent on the question the business originally asked. At low scale, these costs are invisible — absorbed as background friction, things that will be sorted out eventually. At scale, they become a recurring budget line nobody planned for.

There is a compounding benefit that is harder to quantify: vendor independence. When business metric definitions live inside a BI tool's proprietary configuration — LookML, for example — migrating to another tool means rebuilding every business metric. When those definitions live in a tool-agnostic semantic layer, a BI migration becomes a reconfiguration exercise rather than a reconstruction. That is an architect for change decision with a long payoff horizon, but it is exactly the kind of choice that prevents a tool decision made today from becoming a constraint three years from now.

The AI readiness dimension is increasingly concrete. AI agents that query a data warehouse to analyse trends or generate reports inherit whatever business metric definitions the data contains. Without a semantic layer, an agent asked to analyse revenue will compute what the data says, unaware that revenue is ambiguous and without flagging the ambiguity. A semantic layer provides the machine-readable definition that makes AI-generated analysis interpretable and auditable. It is the semantic interface between the organisation's data and the AI layer that reads from it.

The leadership mandate

The semantic layer is under-adopted not because the tooling is immature, but because defining a business metric requires a business decision, and business decisions require someone with the authority to make them.

A data analyst can implement a metric definition. They cannot decide that the CFO's interpretation is the canonical one and that the sales team should align to it. That requires cross-functional authority: a leader who understands why the shared definition matters and can convene the right people to reach it.

The failure mode is treating this as a technical task. The technical implementation takes a few days. The conversation about what the business metrics mean, who is accountable for each definition, and how changes will be governed is the actual investment. It happens once. If it does not happen, the semantic layer stays empty, or fills up with definitions that replicate the same inconsistency in a more expensive format.

The path forward

Most data platforms have the infrastructure: a data warehouse, a BI tool, and often dbt already in use. What is usually missing is the one conversation where the CFO, the head of sales, and the engineering lead sit down, agree on what "revenue" means, and record that definition somewhere the whole organisation can find it. Once that agreement exists, implementing it in the semantic layer is the straightforward part. That conversation is where I usually start.