KPI Engineering: Understanding the Critical Differences Between Metrics Layer and Semantic Layer

Most organisations no longer struggle to collect data. They struggle to agree on what it means. Two teams pull the same figure from the same warehouse, get different answers, and spend the next week reconciling spreadsheets instead of acting on what the numbers say. That gap is an architecture problem, and the part of the stack that closes it is usually either a metrics layer or a semantic layer.

The two terms are often used interchangeably, and vendors do not help. They solve overlapping problems, but they were designed for different consumers, they are built and governed in different ways, and choosing the wrong one for your situation means either a governance layer nobody uses or a modelling exercise that never ends.

This guide sets out what each layer actually is, where they differ in scope, implementation, integration and governance, and how to decide which one, or which combination, suits your existing stack and team.

Understanding KPI engineering#

KPI engineering is the systematic work of designing, implementing and maintaining the infrastructure that lets an organisation define, calculate and distribute key performance indicators. It is broader than choosing which metrics to track. It covers the whole technical framework that turns stored data into figures people are willing to act on.

In practice it addresses four recurring problems:

• Data consistency. Metrics are calculated the same way in every reporting tool and platform, not re-derived by whoever built the dashboard.
• Business logic centralisation. Definitions live in one place rather than being scattered across dashboards, notebooks and saved queries.
• Governance and access control. Who can see which metrics, and at what grain, is decided deliberately rather than inherited from warehouse permissions.
• Scalability. The system copes with growing data volumes and with business definitions that change more often than anyone plans for.

Done well, KPI engineering produces a single source of truth for metrics, removes the silos that make reconciliation necessary, and shortens the path from question to answer.

Where these layers sit in the stack#

Both metrics layers and semantic layers are intermediaries. They sit between raw storage, the warehouse or lake, and the applications people actually open: BI tools, dashboards, reporting systems and increasingly conversational interfaces.

That intermediate position gives them a common set of jobs:

• Abstracting complexity, so users work in business terms rather than table and column names
• Enforcing consistent definitions and calculations across the organisation
• Improving query performance through aggregation, caching and other optimisations
• Providing a governance and security boundary between raw data and its consumers

Whether you implement one, the other, or both depends on your specific needs, your existing tooling investments and your data maturity. Each carries real advantages and real costs.

Metrics layer: definition and core functions#

A metrics layer is a comparatively recent addition to the modern data stack. It centralises the definition of business metrics and KPIs, sitting between the warehouse and the BI tools so that a metric resolves the same way no matter where it is consumed.

Core components of a metrics layer#

• Metric definitions. SQL or code-based specifications of exactly how each metric is calculated.
• Dimensions. The attributes by which a metric can be sliced: time periods, regions, product categories and so on.
• Relationships. Declared connections between entities that make joins and aggregations behave predictably.
• Metadata. Documentation, descriptions and context attached to each metric.

Primary functions#

• Standardisation. Metrics such as customer lifetime value or monthly recurring revenue are calculated identically across every report and dashboard.
• Version control. Changes to a definition can be reviewed, tracked and rolled back.
• Reusability. Once defined, a metric is reused rather than rebuilt for each new report.
• Discoverability. Users can browse available metrics and read their definitions before they start building.

How metrics layers are implemented#

A metrics layer is normally built with tools that let you define metrics as code. That code-first approach fits modern data engineering practice: definitions live in a repository, changes go through review, and tests run automatically.

Tools and frameworks in this space include dbt Metrics, Cube, GoodData and several others, each with different capabilities and different integration points with the rest of the stack.

Semantic layer: definition and core functions#

The semantic layer is the older idea, familiar from decades of business intelligence work. It provides a business-friendly abstraction over complex data structures, translating technical schemas into terms non-technical users can navigate on their own.

Core components of a semantic layer#

• Business entities. Representations of real-world concepts such as customers, products and orders.
• Attributes. Properties of those entities: customer name, product price, order date.
• Hierarchies. Defined drill-down paths, for example country, then state, then city.
• Calculated fields. Expressions and formulas defined within the layer itself.
• Security rules. Definitions of who may access which data elements.

Primary functions#

• Simplification. The complexity of the underlying model is hidden from business users.
• Translation. Technical structures are expressed in business terminology.
• Query optimisation. Queries are structured and often pre-aggregated for performance.
• Access control. Security and permissions are enforced at a granular level, including row level.

How semantic layers are implemented#

Semantic layers are usually delivered through a BI platform, a data virtualisation tool, or a dedicated semantic layer product. Unlike metrics layers, which tend to be code-based, semantic layers frequently offer visual modelling interfaces so analysts can define entities and relationships without writing code.

Established options include the Tableau data model, the Power BI semantic model, Looker’s LookML, AtScale and Dremio.

Key differences between metrics and semantic layers#

Both sit in the same place in the stack, but they differ in approach, focus and implementation. These differences are what should drive the decision.

Focus and scope#

Metrics layer:

• Narrowly focused on metric definitions and calculations
• Primarily concerned with consistency in KPI reporting
• Lighter weight and more specific in purpose

Semantic layer:

• Broader, covering the whole business domain model
• Addresses both metrics and the underlying data structures
• More comprehensive, and correspondingly more complex to build

Technical implementation#

Metrics layer:

• Usually implemented as code, in SQL, YAML or a specialised DSL
• Version-controlled in git alongside the rest of the data platform
• Aligned with software engineering practice, and straightforward to put in a CI/CD pipeline

Semantic layer:

• Frequently built through visual modelling interfaces
• Often proprietary to a specific BI tool or platform
• Less amenable to version control and automated testing
• More accessible to analysts who do not write code

Integration points#

Metrics layer:

• Sits between the warehouse and multiple BI tools
• Typically tool-agnostic, so the same metric serves several platforms
• May need additional integration work to reach every analytics tool

Semantic layer:

• Often tightly coupled to a specific BI tool or platform
• Provides smoother integration within its own ecosystem
• Less flexible when several platforms have to agree

Governance approach#

Metrics layer:

• Focuses on the governance of metric definitions
• Uses code review and approval processes
• Frequently integrates with a data catalogue for discovery

Semantic layer:

• Offers broader governance, including row-level security
• Provides more granular access controls
• Commonly includes data lineage and impact analysis

Implementation considerations#

Choosing between the two, or deciding how to run both, comes down to a handful of practical factors.

Existing technology investments#

Your current stack will shape the answer more than any abstract comparison. If you have already invested heavily in a BI platform with strong semantic modelling, extending that model is usually the cheaper path. If you run several BI tools and need them to agree, a metrics layer addresses that directly in a way a tool-specific semantic model cannot.

Team skills and structure#

A metrics layer implementation assumes software engineering habits and SQL proficiency: repositories, reviews, tests, pipelines. Semantic layer configuration sits closer to a traditional BI skillset. Pick the one your team can maintain after the initial project ends, not the one that looks better on an architecture diagram.

Business requirements#

Let the actual complaint guide the decision. If the problem is that the same KPI has three values depending on which report you open, a metrics layer is the focused fix. If the problem is that business users cannot explore data without raising a ticket, a semantic layer gives them somewhere to explore.

Scale and complexity#

Data volume and domain complexity matter too. Metrics layers are lighter and quicker to stand up initially. Semantic layers tend to pay off at scale, particularly in complex domains with many entities and relationships, where pre-modelled structures and aggregations do more work.

Selecting the right approach for your organisation#

These are not mutually exclusive, and treating the decision as binary is the most common mistake. Three sequencing strategies are worth considering.

Metrics layer first#

For organisations early in their data maturity, starting with a metrics layer delivers value quickly by making KPI reporting consistent. It lets you:

• Standardise your most important business metrics without a long modelling phase
• Establish a working foundation for data governance
• Keep reporting consistent across the tools you already run

A semantic layer can follow later, once the appetite for broader modelling and self-service exploration is there.

Semantic layer first#

Organisations with an established BI platform and a largely single-tool environment often do better building a robust semantic layer first. That gives you:

• Comprehensive modelling of the business domain
• Simpler data exploration for business users
• Full use of capabilities you have already paid for

Metrics layer functionality can be added afterwards to handle cross-platform consistency, or to bring version control to the definitions that matter most.

Running both#

Increasingly, organisations implement the two in a complementary way:

• A metrics layer defines and version-controls the core business KPIs
• A semantic layer provides business-friendly exploration on top of the modelled domain
• Well-defined integration points keep the two from drifting apart

This takes coordination, and it fails quietly when the integration points are left implicit, but done properly it delivers both consistency and flexibility.

Best practices for KPI engineering#

Whichever approach you take, a few practices separate implementations that hold up from those that quietly rot.

Documentation and metadata#

Every metric and data element needs a clear description, a business definition, a stated calculation method and usage guidance. Documentation that lives somewhere nobody looks is the same as no documentation, so put it where people already work: in the catalogue, in the BI tool, next to the metric itself.

Testing and validation#

Test metric definitions the way you would test application code. Unit tests verify calculation logic, integration tests check that the same metric agrees across tools, and periodic reconciliation against a trusted source catches drift that neither test will find.

Change management#

Establish an explicit process for proposing, reviewing and shipping changes to metric definitions and data models. Communicate changes before they land, with enough notice and enough explanation that people can adjust their reports rather than discover the change through a broken dashboard.

Performance optimisation#

Monitor and tune the layer regularly. Look at real query patterns, add aggregations or materialised views where they earn their keep, and check that the access paths under the abstraction are still efficient after the underlying tables have grown.

User adoption and training#

Invest in enablement. Guides, training sessions and ongoing support determine whether people use the governed layer or go back to exporting to a spreadsheet. Adoption, not architecture, is what makes the investment pay.

Where AI changes KPI engineering#

Generative AI is starting to reshape parts of this work, mostly by lowering the effort of tasks that were previously manual. Several patterns are emerging.

AI-assisted metric definition#

Models can analyse existing reports and usage patterns to suggest metrics and dimensions that are already implied by how people query the warehouse. That shortens the work of building an initial metrics catalogue, though the suggestions still need review before they become definitions.

Anomaly detection#

Algorithms can monitor metrics continuously for unusual movement and alert the relevant owners, catching issues and opportunities that a weekly dashboard review would miss.

Natural language interfaces#

Natural language querying lets business users ask questions in plain language rather than SQL. This is also the strongest current argument for having a governed layer at all: a language model answering questions directly against raw tables will invent its own definitions, whereas one grounded in a metrics or semantic layer answers with the definitions your organisation has agreed.

Predictive metrics#

The line between historical KPIs and forecast metrics is blurring as machine learning models are wired into the layer itself, so that forward-looking indicators sit alongside historical ones and are governed the same way.

Moving KPI engineering to the cloud#

As workloads move to cloud data warehouses and lakehouse platforms, both layer types gain capabilities that are difficult to reproduce on-premises:

• Elasticity. Resources scale with query load rather than with peak provisioning.
• Managed services. Less operational overhead through serverless and managed offerings.
• Integration. Easier connection to the rest of your cloud analytics and AI services.
• Consistent access. The same metric definitions serve teams in every location.

When planning the move, decide early how the metrics or semantic layer will fit the broader platform strategy, rather than migrating it as an afterthought once the warehouse is already live.

Connecting metrics to the rest of the platform#

Effective KPI engineering is part of a wider platform strategy that connects data, applications and business processes. When that connection exists, metrics do not stop at a dashboard: they reach the systems where work actually happens.

A platform with KPI engineering built in provides:

• Consistency. One set of metric definitions across applications and touchpoints.
• Accessibility. Self-service access for the people who need the numbers.
• Actionability. A direct path from an insight to the process it should trigger.
• Adaptability. Room to change definitions as the business changes.

Treating the metrics or semantic layer as a platform component, rather than a BI feature, is what makes that possible.

Conclusion#

Choosing between a metrics layer and a semantic layer, or running both, is a genuine architectural decision rather than a naming preference. The metrics layer is strongest at standardising KPI definitions, version-controlling them and keeping them consistent across platforms. The semantic layer is strongest at modelling the business domain, simplifying exploration and integrating deeply with a chosen BI tool.

Start from your organisation’s actual context: what you have already bought, what your team can maintain, what your users are complaining about, and where the data strategy is going. Start from a business objective rather than a technical preference, and pick the approach that addresses the most pressing problem first.

The point of all of it is better decisions built on numbers people trust. Whichever layer you choose, judge it on whether the right people get reliable metrics at the moment they need them.

Decisions like this one are exactly what we work through in our hands-on ELEVATE-AI workshop, and there is more on data and platform architecture in our Infra Modernisation hub.

As an AWS Premier Partner with the AWS Generative AI competency, we build this inside your own AWS account. If you want to talk through your own metrics architecture, book a discovery call.