DataAnalytics & BI

How Airbnb rebuilt metric consistency with a semantic layer

Airbnb's analytics teams were producing conflicting numbers for the same business questions, undermining trust in data across the company. Their response, building Minerva, a centralised semantic layer, offers a precise and transferable blueprint for CDOs dealing with the same problem.

🎙️

Listen to the podcast

4 min

By 2019, Airbnb had accumulated a data infrastructure problem that many scaling companies recognise too late. Different teams, using different tools, were computing the same metrics differently. "Bookings" meant one thing to the growth team and something slightly different to the finance team. The definition of an "active host" varied depending on which dashboard you consulted. Executives would arrive at quarterly reviews holding contradictory numbers, each defensible by its own logic, and the meeting would pivot from decision-making to a debate about whose query was correct. The cost was not just wasted time. It was eroded confidence in the entire analytics function.

This is not a data quality problem in the traditional sense. The underlying data was largely accurate. The problem was definitional: there was no single, authoritative layer that translated raw data into agreed business concepts before analysts and tools consumed it. Every team was running their own transformations, embedding their own assumptions, and producing their own versions of company truth.

What Airbnb actually built

Airbnb's data engineering team designed and built Minerva, described in their public engineering blog posts as a "metrics platform" and, in practical terms, a semantic layer sitting between their data warehouse and the various consumption tools used across the business.

The core mechanics are worth understanding precisely. Minerva stores metric definitions centrally, in code, using a YAML-based configuration. A metric like "nights booked" is defined once, including its aggregation logic, the grain at which it can be sliced, and which dimensions (geography, listing type, booking channel) are valid for that metric. When an analyst or a BI tool requests that metric, they query Minerva, not the raw tables directly. The transformation happens consistently, every time, for every consumer.

This is structurally different from simply building a well-governed data warehouse or a well-documented dbt project. Those approaches improve the underlying data or the transformations, but they do not prevent downstream teams from writing ad hoc queries that diverge from agreed definitions. Minerva puts the definition itself under version control and makes it the mandatory interface. Analysts lose the ability to quietly redefine a metric inside their own notebook.

Airbnb also built an experimentation layer on top of Minerva, so that A/B test results are computed using the same metric definitions as production reporting. This closed a particularly damaging gap: companies frequently run experiments and measure outcomes using metrics defined differently from how those outcomes are tracked in dashboards. The result is that a winning experiment can be deployed and then appear to have no effect in the production data, because the two measurement systems were never aligned.

The engineering work was substantial. Airbnb's team described the build in terms of years, not months. Minerva required resolving disagreements between business units about what terms actually mean, before a single line of infrastructure code was written. That definitional work, often underestimated, was in many ways the harder part.

The results

Airbnb has not published a controlled before-and-after study with precise time savings or revenue attribution, and it would be appropriate to be cautious about any specific figure not sourced independently. What their engineering team described publicly, across multiple blog posts between 2021 and 2023, was a significant reduction in the time analysts spent reconciling conflicting numbers, and a material improvement in confidence when metrics appeared in executive presentations.

The more concrete and verifiable outcome is architectural. By 2022, Minerva had become the mandatory source of metric computation for core business metrics at Airbnb, consumed by their internal dashboarding tools, their experimentation platform, and external-facing reporting. The fact that a company of Airbnb's complexity standardised on a single metric layer across those three domains is itself a meaningful signal: it means the governance model held under real organisational pressure.

The experimentation alignment story is the clearest measurable contribution. When experiment results and production metrics are computed identically, false positives from measurement inconsistency disappear. That has direct consequences for product decision quality, even if the dollar value is hard to isolate.

What transfers, and where your context differs

The Airbnb case points to four things that translate directly to most large organisations.

First, the semantic layer conversation is not a technology purchase. It is a governance decision. The tooling, whether you use dbt Semantic Layer, Cube, AtScale, or something custom like Minerva, matters less than the political commitment to make metric definitions authoritative and enforced. CDOs who buy a tool without resolving the definitional disputes first will find the tool becomes another layer of inconsistency.

Second, start with the metrics that cause the most conflict, not the most metrics. Airbnb's team was explicit that they prioritised the handful of metrics that appeared in executive reviews and cross-team planning. Trying to standardise everything at once is a route to a project that takes three years and delivers nothing visible for two of them.

Third, the integration with experimentation is underrated. Most organisations treat their A/B testing infrastructure and their BI infrastructure as separate domains. If your experiment metrics and your production metrics are computed differently, you are systematically measuring the effect of changes incorrectly. That is a significant decision-quality problem.

Fourth, the YAML-as-definition approach, where metric logic lives in version-controlled code rather than in a dashboard or a wiki, has a specific advantage: it creates auditability. When a metric definition changes, there is a record of who changed it, when, and why. That matters a great deal in regulated industries or in any company where finance and data teams have to agree on numbers for external reporting.

Where context differs: Airbnb is a technology company with strong engineering capacity. Building Minerva internally was feasible for them. Most organisations will use a commercial vendor, which introduces its own considerations. Vendors such as Cube (Cube.dev) and AtScale (now part of Microsoft's ecosystem) offer semantic layer capabilities, but their product roadmaps and pricing structures are tied to commercial interests. Independent assessments from analysts like Gartner or Forrester are more reliable guides to fit than the vendors' own benchmarks.

The underlying lesson from Airbnb's experience is that metric consistency is an organisational problem with a technical solution, in that order. Get the definitions agreed before you pick the platform. The platform will not negotiate your business definitions for you.

Finished reading?

Validate your read to earn XP and feed your radar.