Wie Airbnb mit einem Semantic Layer die Konsistenz seiner Metriken wiederhergestellt hat

Bis 2019 hatte Airbnb ein Problem mit der Dateninfrastruktur angesammelt, das viele wachsende Unternehmen zu spät erkennen. Verschiedene Teams berechneten mit verschiedenen Tools dieselben Metriken unterschiedlich. „Bookings“ bedeutete für das Growth-Team etwas anderes als für das Finance-Team. Die Definition eines „active host“ hing davon ab, welches Dashboard man aufrief. Führungskräfte kamen mit widersprüchlichen Zahlen in die Quartalsreviews, jede nach eigener Logik vertretbar, und das Meeting kippte von der Entscheidungsfindung in eine Debatte darüber, wessen Query korrekt war. Der Preis war nicht nur verlorene Zeit. Es war der Vertrauensverlust in die gesamte Analytics-Funktion.

Das ist kein Datenqualitätsproblem im klassischen Sinn. Die zugrunde liegenden Daten waren größtenteils korrekt. Das Problem war definitorisch: Es gab keine einzige, verbindliche Schicht, die Rohdaten in vereinbarte Geschäftsbegriffe übersetzte, bevor Analysten und Tools sie konsumierten. Jedes Team fuhr seine eigenen Transformationen, baute seine eigenen Annahmen ein und produzierte seine eigene Version der Unternehmenswahrheit.

Was Airbnb tatsächlich gebaut hat

Das Data-Engineering-Team von Airbnb konzipierte und baute Minerva, in den öffentlichen Beiträgen des Engineering-Blogs beschrieben als „metrics platform“ und praktisch gesehen ein Semantic Layer zwischen dem Data WarehouseData WarehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.Vollständige Definition ansehen → und den verschiedenen Consumption-Tools im Unternehmen.

Die Mechanik im Kern lohnt eine genaue Betrachtung. Minerva speichert Metrik-Definitionen zentral, in Code, über eine YAML-basierte Konfiguration. Eine Metrik wie „nights booked“ wird einmal definiert, inklusive Aggregationslogik, der Granularität, auf der sie geschnitten werden kann, und der Dimensionen (Geografie, Listing-Typ, Buchungskanal), die für diese Metrik gültig sind. Fordert ein Analyst oder ein 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.Vollständige Definition ansehen →-Tool diese Metrik an, wird Minerva abgefragt, nicht direkt die Rohtabellen. Die Transformation läuft jedes Mal konsistent, für jeden Konsumenten.

Das unterscheidet sich strukturell davon, einfach ein gut governiertes Data Warehouse oder ein gut dokumentiertes dbt-Projekt zu bauen. Diese Ansätze verbessern die zugrunde liegenden Daten oder die Transformationen, sie verhindern aber nicht, dass Teams weiter unten Ad-hoc-Queries schreiben, die von den vereinbarten Definitionen abweichen. Minerva stellt die Definition selbst unter Versionskontrolle und macht sie zum verbindlichen Interface. Analysten verlieren die Möglichkeit, eine Metrik still und leise in ihrem eigenen Notebook neu zu definieren.

Airbnb baute außerdem einen Experimentation Layer auf Minerva auf, sodass A/B-Testergebnisse mit denselben Metrik-Definitionen berechnet werden wie das produktive Reporting. Damit wurde eine besonders schädliche Lücke geschlossen: Unternehmen führen häufig Experimente durch und messen Ergebnisse mit Metriken, die anders definiert sind als die Messung derselben Ergebnisse in den Dashboards. Die Folge: Ein erfolgreiches Experiment wird ausgerollt und zeigt in den Produktionsdaten dann keine Wirkung, weil die beiden Messsysteme nie aufeinander abgestimmt waren.

Der Engineering-Aufwand war erheblich. Das Team von Airbnb beschrieb den Aufbau in Jahren, nicht in Monaten. Minerva erforderte, Meinungsverschiedenheiten zwischen Geschäftseinheiten darüber auszuräumen, was Begriffe eigentlich bedeuten, bevor eine einzige Zeile Infrastrukturcode geschrieben wurde. Diese definitorische Arbeit wird häufig unterschätzt und war in vielerlei Hinsicht der schwierigere Teil.

Die Ergebnisse

Airbnb hat keine kontrollierte Vorher-Nachher-Studie mit präzisen Zeitersparnissen oder Umsatzzuordnungen veröffentlicht, und bei jeder Zahl ohne unabhängige Quelle ist Zurückhaltung angebracht. Was das Engineering-Team zwischen 2021 und 2023 in mehreren Blogbeiträgen öffentlich beschrieb, war eine deutliche Reduktion der Zeit, die Analysten mit dem Abgleich widersprüchlicher Zahlen verbrachten, und eine spürbar höhere Sicherheit, wenn Metriken in Präsentationen für das Management auftauchten.

Das konkretere und überprüfbare Ergebnis ist architektonisch. Bis 2022 war Minerva bei Airbnb zur verbindlichen Quelle für die Berechnung zentraler Geschäftsmetriken geworden, genutzt von den internen Dashboarding-Tools, der Experimentation-Plattform und dem nach außen gerichteten Reporting. Dass ein Unternehmen der Komplexität von Airbnb sich über diese drei Bereiche hinweg auf einen einzigen Metric Layer standardisiert hat, ist selbst ein aussagekräftiges Signal: Es bedeutet, dass das Governance-Modell unter echtem organisatorischem Druck gehalten hat.

Die Abstimmung mit der Experimentation ist der klarste messbare Beitrag. Werden Experimentergebnisse und produktive Metriken identisch berechnet, verschwinden False Positives aus Messinkonsistenzen. Das hat direkte Folgen für die Qualität von Produktentscheidungen, auch wenn der Eurobetrag schwer zu isolieren ist.

Was übertragbar ist und wo Ihr Kontext abweicht

Der Fall Airbnb verweist auf vier Punkte, die sich direkt auf die meisten großen Organisationen übertragen lassen.

Erstens: Die Diskussion über den Semantic Layer ist kein Technologiekauf. Sie ist eine Governance-Entscheidung. Das Tooling, ob dbt Semantic Layer, Cube, AtScale oder etwas Eigenes wie Minerva, zählt weniger als die politische Verpflichtung, Metrik-Definitionen verbindlich zu machen und durchzusetzen. CDOs, die ein Tool kaufen, ohne zuerst die definitorischen Streitfragen zu klären, werden feststellen, dass das Tool zu einer weiteren Schicht Inkonsistenz wird.

Zweitens: Beginnen Sie mit den Metriken, die den größten Konflikt auslösen, nicht mit den meisten Metriken. Das Team von Airbnb sagte ausdrücklich, dass es die Handvoll Metriken priorisierte, die in Management-Reviews und teamübergreifender Planung auftauchten. Alles auf einmal zu standardisieren, führt zu einem Projekt, das drei Jahre dauert und zwei davon nichts Sichtbares liefert.

Drittens: Die Integration mit Experimentation wird unterschätzt. Die meisten Organisationen behandeln ihre A/B-Testing-Infrastruktur und ihre BI-Infrastruktur als getrennte Welten. Werden Ihre Experiment-Metriken und Ihre produktiven Metriken unterschiedlich berechnet, messen Sie die Wirkung von Änderungen systematisch falsch. Das ist ein erhebliches Problem für die Entscheidungsqualität.

Viertens: Der Ansatz YAML-als-Definition, bei dem die Metrik-Logik in versionskontrolliertem Code statt in einem Dashboard oder Wiki liegt, hat einen konkreten Vorteil: ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → schafft Auditierbarkeit. Ändert sich eine Metrik-Definition, ist dokumentiert, wer sie wann und warum geändert hat. Das zählt viel in regulierten Branchen oder in jedem Unternehmen, in dem Finance- und Data-Teams sich für das externe Reporting auf Zahlen verständigen müssen.

Wo der Kontext abweicht: Airbnb ist ein Technologieunternehmen mit starker Engineering-Kapazität. Minerva intern zu bauen, war für sie machbar. Die meisten Organisationen werden einen kommerziellen Anbieter nutzen, was eigene Überlegungen mit sich bringt. Anbieter wie Cube (Cube.dev) und AtScale (inzwischen Teil des Microsoft-Ökosystems) bieten Semantic-Layer-Funktionalität, aber ihre Produkt-Roadmaps und Preisstrukturen sind an kommerzielle Interessen gebunden. Unabhängige Assessments von Analysten wie Gartner oder Forrester sind verlässlichere Orientierung für die Passung als die Benchmarks der Anbieter selbst.

Die grundlegende Lehre aus Airbnbs Erfahrung: Metrik-Konsistenz ist ein organisatorisches Problem mit einer technischen Lösung, in dieser Reihenfolge. Klären Sie die Definitionen, bevor Sie die Plattform auswählen. Die Plattform wird Ihre Geschäftsdefinitionen nicht für Sie aushandeln.