Der Semantic Layer im Go-to-Market: was er ist und wie er hilft

Ein Semantic Layer (semantische Schicht) ist der Ort, an dem ein Unternehmen einmal und als Code festlegt, was jede Geschäftskennzahl bedeutet, damit jedes Dashboard, jedes Spreadsheet und jeder KI-Agent Pipeline, Win Rate und Annual Recurring Revenue (ARR) auf dieselbe Weise berechnet. Für Go-to-Market-Teams (GTM) beendet er den Streit darüber, wessen Zahl stimmt, und er macht den Unterschied aus zwischen einem KI-Agenten, der rät, und einem, dem Sie Umsatzdaten anvertrauen können.

Stellen Sie sich einen Montagmorgen bei MyGym24 vor, dem fiktiven Unternehmen für Fitnessstudio-Software aus meinem Buch The RevOps Pendulum. Maria, Head of Revenue Operations (RevOps), fragt, wie viel Pipeline das Unternehmen für dieses Quartal hat.

Marketing sagt $4,2 Millionen, weil dort jede Opportunity zählt, die in diesem Quartal aus einem Marketing-Lead entstanden ist. Sales sagt $3,1 Millionen und zählt offene Opportunities, deren Abschlussdatum im Quartal liegt. Finance sagt $2,6 Millionen und vertraut nur Deals in der Angebotsphase. Dann fragt der CEO den neuen KI-Assistenten des Unternehmens, und der antwortet mit voller Überzeugung, die Pipeline betrage $5 Millionen. Er hat jede offene Opportunity addiert, Verlängerungen und zwei Testdatensätze eingeschlossen.

Vier Zahlen für eine Frage, und niemand hat sich verrechnet. Alle vier haben jeweils eine leicht andere Frage beantwortet und ihr denselben Namen gegeben. MyGym24 und die Zahlen sind erfunden, aber das Meeting dürfte Ihnen bekannt vorkommen.

Was ein Semantic Layer ist und worin er sich von einem Data Dictionary unterscheidet

Die meisten Unternehmen haben irgendwo ein Data Dictionary, eine Confluence-Seite oder ein Spreadsheet, in dem steht, was ein Marketing Qualified Lead (MQL) ist, wie die Win Rate berechnet wird und was als ARR zählt. Das Problem ist, dass nichts ein Dashboard zwingt, sich daran zu halten. Im Dokument steht das eine, und den Bericht hat jemand gebaut, der es nie gelesen hat.

Ein Semantic Layer ist dasselbe Dictionary, als Code geschrieben. Die Definitionen liegen direkt bei den Daten, jede Änderung wird geprüft, und die Tools berechnen die Zahl aus der Definition selbst. Sie fragen eine Kennzahl über ihren Namen ab, etwa die Win Rate nach Segment und Quartal, und der Layer schreibt die Datenbankabfrage. Der Test ist einfach. Lässt sich eine Zahl noch auf zwei Arten berechnen, hat der Layer noch nicht entschieden.

Die Idee ist nicht neu. Business Objects verkaufte sie Anfang der 1990er-Jahre und nannte sie ein "Universe". Geändert hat sich, wer die Fragen stellt. Ein Dashboard wird einmal gebaut, von einem Analysten, der die Daten kennt. Ein KI-Agent schreibt jedes einzelne Mal eine neue Abfrage, und er weiß nichts über Ihr Geschäft, solange Sie es ihm nicht sagen.

Wo der Semantic Layer zwischen Datenbank und Dashboard sitzt

Um zu sehen, wo der Layer sitzt, folgen Sie einer Opportunity bei MyGym24 auf ihrem Weg in Marias Meeting.

1. Sie entsteht in einem Quellsystem, dem Customer-Relationship-Management-System (CRM). Abonnements liegen im Abrechnungstool, Logins in der Produktdatenbank und Werbeausgaben in den Werbeplattformen.
2. Ein Connector kopiert diese Rohdaten nach Zeitplan an einen einzigen Ort.
3. Dieser Ort ist das Data Warehouse, zum Beispiel Snowflake, Databricks oder BigQuery.
4. Datenmodelle formen die Rohtabellen zu dem um, was der Fachbereich wiedererkennt, etwa eine Zeile pro Account, pro Opportunity und pro Kunde und Monat.
5. Der Semantic Layer sitzt auf diesen Tabellen. Hier definieren Sie die Kennzahlen und die Dimensionen, nach denen Sie sie aufschlüsseln können.
6. Dashboards, Spreadsheets und KI-Agenten fragen eine Kennzahl über ihren Namen ab.

Beachten Sie, was das für das CRM bedeutet. Es wird zu einer Quelle unter mehreren, einer wichtigen, aber nicht zur Source of Truth. Zugleich steigen die Anforderungen daran, wie Sie das CRM-Datenmodell gestalten, denn aus sauberen Objekten und Feldern wird Schritt vier gebaut.

Schritt fünf funktioniert nur, wenn Schritt vier gut gemacht ist. Ist Ihre Account-Tabelle voller Dubletten, liefert Ihnen eine perfekte Definition der Win Rate eine perfekt berechnete falsche Zahl. Und manche Unternehmen, mit denen ich spreche, sind noch nicht bei Schritt drei. Sie haben kein Data Warehouse, oder sie speichern darin nur Produktdaten. Wenn das auf Sie zutrifft, ist das Ihr erstes Projekt.

Warum Go-to-Market-Kennzahlen eine verbindliche Definition brauchen

Die Mathematik im GTM ist einfach. Die Win Rate ist eine Division. Schwierig ist alles drum herum, denn in jeder kommerziellen Kennzahl stecken vier Entscheidungen. Sie müssen festlegen, welche Datensätze zählen, zu welchem Zeitpunkt, in welcher Einheit und aus welchem System.

Kennzahl	Was Sie entscheiden müssen
Pipeline	In diesem Quartal erstellt oder heute offen? Welche Abschlussdaten? Gemessen am Plan oder am Forecast?
Win Rate	Zählen No-Decisions als verloren? Im Zeitraum abgeschlossene Deals oder eine Kohorte erstellter Deals? Anzahl oder Dollar?
ARR	Beginnt sie mit der Unterschrift, dem Go-live oder der ersten Rechnung? Zählt Nutzung mit?
Aktiver Kunde	Übergeordneter oder untergeordneter Account? Eine bezahlte Rechnung oder ein Login? In welchem Zeitfenster?

Nehmen Sie die Win Rate. Dave Kellogg unterscheidet eine enge Win Rate, gewonnene Deals geteilt durch gewonnene plus verlorene Deals, von einer weiten, die auch die No-Decisions in den Nenner nimmt. Beide sind legitim. Sie beantworten unterschiedliche Fragen.

Wie groß kann die Lücke werden? In einer Demo von Amazon Web Services (AWS) und dbt Labs ergab eine Abfrage, die einfach die Betragsspalte summierte, $14,86 Millionen Umsatz gegenüber einem verbindlich definierten Wert von $11,36 Millionen. Die einfache Abfrage ignorierte Rabatte und Erstattungen und zählte stornierte Bestellungen und Testkonten mit, was Ihnen nichts in der Tabellenstruktur verrät.

Ich würde keine einzelne Definition erzwingen, wo zwei legitim sind. Behalten Sie beide, geben Sie ihnen unterschiedliche Namen, und lassen Sie jeden Bericht angeben, welche er verwendet hat.

Wie ein Semantic Layer Daten aus Sales, Finance und Produkt verbindet

Nirgends ist das Benennungsproblem sichtbarer als zwischen Sales, Finance und Produkt. Angenommen, eine Fitnessstudio-Kette mit acht Standorten unterschreibt einen Zweijahresvertrag über $15.000 pro Studio und Jahr. Sales meldet Bookings von $240.000, die Abrechnung stellt jedes Quartal $30.000 in Rechnung, Finance realisiert jeden Monat $10.000 Umsatz, und die ARR beträgt $120.000. Alle vier Zahlen sind korrekt, und dieselbe Aufteilung gehen wir in unserem Beitrag zu Commercial und Financial RevOps durch.

In unserer Five-Dots-Wissensdatenbank nutzen wir dafür eine Faustregel. Das CRM verkauft, das Produkt liefert, Finance zählt. Wo das CRM einen Fakt aus den beiden anderen braucht, etwa eine Nutzungsstufe oder ein Health-Signal, schreibt das verantwortliche System ihn als schreibgeschützten Wert hinein. Das Ziel ist ein Verantwortlicher pro Fakt, nicht ein System für alles.

Ein Semantic Layer macht das praktikabel, weil jede Zahl zu einer eigenen, benannten Kennzahl mit einem verantwortlichen System wird. Er zwingt Sie außerdem, das zu schaffen, was den meisten Unternehmen fehlt, eine gemeinsame Kunden-ID, die den CRM-Account, den Kunden in der Abrechnung und den Produkt-Workspace verbindet. Ohne diesen Schlüssel lässt sich nichts verknüpfen.

Auch auf die Definition von "Kunde" kommt es an. In einem weiteren Beispiel von Kellogg schrumpft ein Geschäftsbereich eines Kunden von 100 auf 80, während ein zweiter Geschäftsbereich für 40 kauft. Die Net Revenue Retention (NRR) liegt bei 80%, wenn der zweite Geschäftsbereich als Neukunde zählt, und bei 120%, wenn er zum selben Kunden gehört.

Wenn Sie sich nicht sicher sind, wie viele Ihrer Kernkennzahlen mehr als eine Definition haben, erfasst unser RevOps-Audit Ihre Strategie, Prozesse, Daten und Ihren Stack und zeigt, wo sich KI auszahlt.

Warum KI-Agenten verbindliche Kennzahlendefinitionen brauchen

All das galt schon vor fünf Jahren. Heute wiegt es schwerer, weil ein Dashboard und ein Agent unterschiedlich scheitern. Ein Dashboard ohne Definition zeigt nichts an. Ein Agent ohne Definition gibt Ihnen trotzdem eine Antwort.

In zwei akademischen Benchmarks, die auf echten Unternehmensdaten beruhen, lösten KI-Agenten, die ihre Abfragen selbst schreiben, 21,3% der Fragen bei Spider 2.0 und 10,8% bei BEAVER. Die Abfragesprache ist nicht das Problem. Das Modell weiß nicht, welcher Tabelle Finance vertraut, wann Ihr Geschäftsjahr beginnt oder ob Verlängerungen zur Pipeline zählen.

Darf der Agent nur definierte Kennzahlen abfragen, ändert sich das Bild. In einem Test, den dbt Labs im April 2026 durchführte, erreichte der Agent 100% bei den Fragen, die der Semantic Layer abdeckte, und 0% bei den Fragen, die er nicht abdeckte. Der Layer macht aus "manchmal falsch" ein "richtig oder abgelehnt". Bei einer Zahl für das Board oder einem Forecast ist das der Tausch, den ich eingehen würde.

Eine Einschränkung gehört dazu. Diese Vergleiche stammen von Anbietern, die einen Semantic Layer verkaufen, sie beruhen auf kleinen Fragenkatalogen, und eine unabhängige Studie habe ich bisher nicht gefunden. Die genauen Prozentwerte sind mit Vorsicht zu genießen.

Wie viel Aufwand dahintersteckt, habe ich aus der Nähe gesehen. Ein Unternehmen, mit dem ich arbeite, hat seinen Semantic Layer in dbt gebaut, wobei jede Kennzahl in einer Datei definiert, in GitHub abgelegt und vor jeder Änderung freigegeben wird. Davor lagen die Definitionen in Confluence und in Spreadsheets, und der Connector für den KI-Assistenten war auf rund 60 handgeschriebene Abfragen angewachsen. Heute hat er drei Tools, die die Kennzahlen auflisten, eine Kennzahl abfragen und die Abfrage hinter der Antwort zeigen. Der Aufbau des Layers hat sechs Monate gedauert, und er ist nicht abgeschlossen. Der Connector hat Tage gedauert.

Dieses Verhältnis ist die Lehre daraus. Planen Sie Monate für die Definitionen ein und Tage für die Technologie. Es erklärt auch eine Lücke in unserer eigenen Studie. In unserem Report RevOps in 2026, einer Umfrage unter 123 RevOps-Fachleuten, haben 73% der B2B-SaaS-Teams im Mid-Market ein KI-Mandat und 38% die Daten, um es zu stützen. Unsere KI-Readiness-Scorecard für Revenue-Teams prüft den Rest Ihres Fundaments in 20 Fragen.

Als ich im Podcast Growth After Headcount mit Dora Kondeva sprach, VP of Growth and Revenue Marketing für EMEA bei Snowflake, sagte sie aus Sicht des Marketings dasselbe. Agenten brauchen Daten, die einer Governance unterliegen, und sie brauchen Kontext. Was ein Account mit hohem Engagement ist, muss für Marketing und für Sales dasselbe bedeuten.

Meine Regel für Agenten ist kurz. Verbindlich definierte Kennzahlen oder keine Zahl. Bei der Formulierung darf der Assistent kreativ sein, bei der Berechnung nie.

Wo Sie mit einem Semantic Layer in RevOps anfangen

Sie beginnen nicht mit einem Tool. Sie beginnen mit einer Liste, und Sie planen Monate an Arbeit ein und eine Wartung, die nie endet. Ich würde fünf Dinge tun, in dieser Reihenfolge.

1. Sammeln Sie die rund 20 Kennzahlen aus Ihrem Management-Reporting. Stellen Sie dieselbe Frage, zum Beispiel nach der Pipeline des letzten Quartals, in jedem Dashboard und jedem KI-Assistenten, den Sie haben. Wo die Antworten voneinander abweichen, haben Sie ein Wort gefunden, das niemand definiert hat.
2. Halten Sie für jede Kennzahl die vier Entscheidungen schriftlich fest und benennen Sie eine verantwortliche Person. Der Fachbereich verantwortet die Definition, das Datenteam die Berechnung.
3. Benennen Sie die konkurrierenden Definitionen, statt über sie zu streiten. Bookings und ARR können nebeneinander bestehen. "Umsatz" mit zwei Bedeutungen kann es nicht.
4. Erledigen Sie diese Woche zwei Dinge, die wenig kosten. Aktivieren Sie in Ihrem CRM die Feldhistorie für die Opportunity-Phase, denn die Phasenhistorie lässt sich später nicht rekonstruieren. Und schreiben Sie die CRM-Account-ID auf den Kunden in der Abrechnung und auf den Produkt-Workspace.
5. Entscheiden Sie dann, wo die Definitionen liegen. Bei nur einem Data Warehouse und einem Reporting-Tool würde ich mit dem Layer im Warehouse selbst anfangen, etwa mit den Semantic Views von Snowflake oder den Metric Views von Databricks. Wenn mehrere Tools und Agenten dieselben Zahlen brauchen, sehen Sie sich einen eigenständigen Layer wie den dbt Semantic Layer oder Cube an.

Ein Semantic-Layer-Setup, das wir einem B2B-SaaS-Unternehmen empfehlen würden

Wie sähe das in der Praxis aus? MyGym24 nutzt ein CRM, Stripe für die Abrechnung, eine eigene Produktdatenbank und eine Handvoll Werbeplattformen. Es gibt einen Analytics Engineer, und Maria hat ihre Liste mit 20 Kennzahlen.

Die Tabelle zeigt das Setup, das wir empfehlen würden. Es ist eine von mehreren guten Optionen, und jedes Tool darin lässt sich gegen ein vergleichbares austauschen. Entscheidend ist die Reihenfolge der Schichten.

Schicht	Was MyGym24 nutzt	Was sie leistet
Datenbank	Ein Cloud-Data-Warehouse, in diesem Fall BigQuery mit Hosting in der EU	Ein Ort für alle kommerziellen Daten sowie Abrechnungs- und Produktdaten
Eingehende Integration	Verwaltete Connectoren wie Fivetran oder Airbyte	Kopieren das CRM, Stripe, die Produktdatenbank und die Werbeplattformen nach Zeitplan ins Warehouse
Datenmodelle	dbt, in einem GitHub-Repository	Machen aus Rohtabellen Accounts, Opportunities, Abonnements und Nutzung
Semantic Layer	Der dbt Semantic Layer, im selben Repository	Enthält die Kennzahlendefinitionen als Textdateien
Gateway	Ein MCP-Server (Model Context Protocol) mit reinem Lesezugriff	Lässt den KI-Assistenten Kennzahlen auflisten und abfragen, sonst nichts
Skills	Eine kurze Anweisungsdatei pro Meeting	Liefert den Geschäftskontext für das Pipeline-Review, den Forecast und die Verlängerungen
Ausgehende Integration	Dashboards, Google Sheets, der KI-Assistent und ein Sync zurück ins CRM	Alle lesen dieselben Zahlen

Welche Datenbank und welche Datenmodelle zuerst kommen

Warum ein Warehouse und nicht das CRM? Weil das CRM Rechnungen, Logins und Werbeausgaben nicht so speichern kann, dass sie sich verknüpfen lassen. Snowflake, Databricks und BigQuery erfüllen alle den Zweck, wählen Sie also das, was Ihr Engineering-Team bereits kennt. Viel wichtiger ist, was Sie zuerst modellieren, und MyGym24 beginnt mit drei Tabellen.

1. Eine Account-Tabelle mit der CRM-Account-ID, der Stripe-Kunden-ID und der ID des Produkt-Workspace. Das ist der gemeinsame Kundenschlüssel von weiter oben.
2. Eine Opportunity-Tabelle sowie ein täglicher Snapshot der offenen Opportunities. Ohne den Snapshot gibt es keine "Pipeline zum Stand von Woche drei".
3. Eine Abonnement-Tabelle mit einer Zeile pro Kunde und Monat. ARR und NRR werden aus dieser Tabelle berechnet, nicht aus Opportunity-Beträgen. ARR-Snapshots im CRM beschreiben wir in einem eigenen Beitrag.

Wie Sie eine Kennzahlendefinition schreiben

Jede Kennzahl wird zu einer kurzen Textdatei im selben GitHub-Repository wie die Datenmodelle. In dbt ist das Format YAML, ein einfaches Textformat, das Menschen und Maschinen gleichermaßen lesen können, und die genaue Syntax steht in der MetricFlow-Dokumentation von dbt. Das hält MyGym24 für die enge Win Rate fest.

Feld	Was MyGym24 festhält
Name	win_rate_narrow
Formel	Gewonnene Opportunities geteilt durch gewonnene plus verlorene Opportunities
Ausgeschlossen	No-Decisions, Verlängerungen und Testdatensätze
Zeitbezug	Abschlussdatum
Einheit	Anzahl der Deals, nicht Dollar
Aufschlüsselbar nach	Segment, Region, verantwortlicher Person und Lead-Quelle
Verantwortliche	Der Head of Sales für die Definition, der Analytics Engineer für die Berechnung

Um das zu lesen, müssen Sie nicht aus dem Engineering kommen. Maria sieht, dass No-Decisions ausgeschlossen sind, dass die Kennzahl Deals zählt und nicht Dollar und dass sie sich auf das Abschlussdatum bezieht. Das sind die vier Entscheidungen von vorhin, festgehalten dort, wo die Zahl berechnet wird.

Eine Änderung läuft ab wie eine Vertragsänderung. Jemand schlägt sie in GitHub vor, die fachlich verantwortliche Person gibt die Definition frei, der Analytics Engineer gibt die Berechnung frei, und erst dann geht sie für alle Dashboards und Agenten gleichzeitig live. Halten Sie auch das Vokabular fest. In dem Unternehmen, das ich erwähnt habe, sind Geschäftsjahr und Kalenderjahr dasselbe, was im Layer fehlte und was ein Assistent nicht erraten kann.

Wie Sie Dashboards, KI-Agenten und das CRM anbinden

Es gibt drei Richtungen. Die erste sind Dashboards und Spreadsheets. Verbinden Sie sie mit dem Semantic Layer, statt die Formeln in jedem Tool nachzubauen. Zum Beispiel bietet dbt eine Integration für Google Sheets, sodass Finance die ARR in ein Sheet ziehen kann, ohne eine Abfrage zu schreiben. Prüfen Sie vor dem Kauf eines Dashboard-Tools, ob es Kennzahlen aus Ihrem Layer lesen kann, sonst definieren Sie alles doppelt.

Die zweite ist der KI-Assistent. Er bekommt nie direkten Zugriff auf die Tabellen. Er spricht mit einem kleinen Gateway mit reinem Lesezugriff, das die Kennzahlen auflisten, die möglichen Aufschlüsselungen einer Kennzahl zeigen und sie abfragen kann. Einen solchen MCP-Server liefert dbt mit, und das Unternehmen, das ich erwähnt habe, hat seinen eigenen innerhalb von Tagen gebaut. Lassen Sie das Gateway mit den Berechtigungen der fragenden Person laufen, damit ein Vertriebsmitarbeiter nie Zahlen sieht, die er nicht sehen darf. Auf dem Gateway sitzen die Skills, die dem Assistenten sagen, welche Kennzahlen ins Pipeline-Review gehören und was er niemals selbst berechnen darf.

Die dritte ist der Weg zurück ins CRM. Ein Sync-Tool wie Hightouch oder Fivetran Activations schreibt Werte wie die ARR aus der Abrechnung, eine Nutzungsstufe oder einen Health Score als schreibgeschützte Felder auf den Account-Datensatz. Im CRM landet der Wert, nicht die Formel.

Maria verantwortet die Liste der Kennzahlen und leitet die Entscheidungsfindung, wenn sich zwei Teams nicht einig sind, und der Analytics Engineer verantwortet die Modelle und die Berechnung. Die Tools sind austauschbar. Die Reihenfolge ist es nicht. Zuerst kommen die Tabellen, dann die Definitionen, dann die Agenten.

Warum die Einigung auf Definitionen schwerer ist als die Technologie

Die Technologie wird zum einfachen Teil. Die Formate sind offen, die KI-Modelle können den Code entwerfen, und jede Datenplattform liefert ihren eigenen Layer mit. Schwer bleibt es, Marketing, Sales, Customer Success und Finance dazu zu bringen, sich darauf zu einigen, was ein Wort bedeutet, und es dann aufzuschreiben. Das ist Abstimmungsarbeit, und Abstimmung war schon immer die Aufgabe von RevOps.

Ein paar Monate später steht in Marias Montagsmeeting eine einzige Pipeline-Zahl auf dem Bildschirm, darunter eine Zeile, die sagt, welche Definition verwendet wurde. Der Assistent des CEO liefert dieselbe Zahl, und im Meeting geht es darum, was mit der Pipeline zu tun ist, nicht darum, wessen Zahl stimmt.

Wenn Sie einen zweiten Blick auf Ihre eigenen Definitionen und Ihr Datenfundament möchten, ist ein RevOps-Audit der richtige Einstieg.

FAQ zum Semantic Layer

Was ist ein Semantic Layer, einfach erklärt?

Ein Semantic Layer ist ein gemeinsamer Satz von Kennzahlendefinitionen, als Code geschrieben, mit dem jedes Dashboard und jeder KI-Agent eine Zahl berechnet. Sie fragen die Win Rate über ihren Namen ab, und der Layer schreibt die Datenbankabfrage, sodass das Ergebnis in jedem Tool dasselbe ist.

Was ist der Unterschied zwischen einem Semantic Layer und einem Data Dictionary?

Ein Data Dictionary beschreibt, was eine Kennzahl bedeutet, während ein Semantic Layer das ist, woraus die Kennzahl berechnet wird. Das Dictionary ist ein Dokument, das man ignorieren kann. Der Semantic Layer ist versionierter Code, an dem die Tools nicht vorbeikommen.

Brauchen Sie ein Data Warehouse, bevor Sie einen Semantic Layer aufbauen?

Ja, in der Praxis schon. Der Layer sitzt auf sauberen, verknüpften Tabellen, und die liegen in einem Warehouse wie Snowflake, Databricks oder BigQuery. Ohne ein Warehouse lassen sich CRM-, Abrechnungs- und Produktdaten nicht zu einer einzigen Definition zusammenführen.

Wie lange dauert der Aufbau eines Semantic Layers?

Planen Sie Monate ein, nicht Wochen. Das in diesem Artikel beschriebene Unternehmen brauchte sechs Monate für einen ersten funktionierenden Layer und erweitert ihn noch immer, während der Connector für seinen KI-Assistenten Tage dauerte. Die meiste Zeit fließt in die Einigung auf die Definitionen, nicht in die Software.