De semantic layer voor go-to-market: wat het is en wat het oplevert

Een semantic layer (semantische laag) is de plek waar een bedrijf één keer, en als code, vastlegt wat elk bedrijfscijfer betekent, zodat elk dashboard, elke spreadsheet en elke AI-agent de pipeline, de winrate en de annual recurring revenue (ARR) op dezelfde manier berekent. Voor go-to-market-teams (GTM) maakt zo'n laag een einde aan de discussie over wiens cijfer klopt, en het is het verschil tussen een AI-agent die gokt en een agent die je omzetdata kunt toevertrouwen.

Stel je een maandagochtend voor bij MyGym24, het fictieve softwarebedrijf voor sportscholen uit mijn boek The RevOps Pendulum. Maria, de Head of Revenue Operations (RevOps), vraagt hoeveel pipeline het bedrijf dit kwartaal heeft.

Marketing zegt $4,2 miljoen, omdat ze elke opportunity tellen die dit kwartaal uit een marketinglead is aangemaakt. Sales zegt $3,1 miljoen en telt de open opportunities die binnen het kwartaal sluiten. Finance zegt $2,6 miljoen en vertrouwt alleen deals in de offertefase. Dan stelt de CEO de vraag aan de nieuwe AI-assistent van het bedrijf, die vol zelfvertrouwen antwoordt dat de pipeline $5 miljoen is. Hij telde elke open opportunity op, inclusief verlengingen en twee testrecords.

Vier cijfers voor één vraag, en niemand heeft een rekenfout gemaakt. Ze beantwoordden elk een net iets andere vraag en gaven die dezelfde naam. MyGym24 en de cijfers zijn verzonnen, maar het overleg zul je herkennen.

Wat een semantic layer is en hoe die verschilt van een data dictionary

De meeste bedrijven hebben ergens een data dictionary, een Confluence-pagina of een spreadsheet waarin staat wat een marketing qualified lead (MQL) is, hoe je de winrate berekent en wat als ARR telt. Het probleem is dat niets een dashboard dwingt om zich eraan te houden. In het document staat het ene, en het rapport is gebouwd door iemand die het nooit heeft gelezen.

Een semantic layer is datzelfde woordenboek, maar dan geschreven als code. De definities staan naast de data, elke wijziging wordt nagekeken, en de tools berekenen het cijfer vanuit de definitie zelf. Je vraagt een metric op bij naam, bijvoorbeeld winrate per segment per kwartaal, en de laag schrijft de databasequery. De test is simpel. Kan een cijfer nog op twee manieren worden berekend, dan heeft de laag nog niet beslist.

Het idee is niet nieuw. Business Objects verkocht het aan het begin van de jaren 1990 en noemde het een "universe". Wat is veranderd, is wie de vragen stelt. Een dashboard wordt één keer gebouwd, door een analist die de data kent. Een AI-agent schrijft elke keer opnieuw een query, en hij weet niets van je bedrijf tenzij je het hem vertelt.

Waar de semantic layer zit tussen de database en het dashboard

Om te zien waar de laag zit, volg je één opportunity bij MyGym24 op weg naar het overleg van Maria.

1. De opportunity begint in een bronsysteem, het customer relationship management-systeem (CRM). Abonnementen staan in de facturatietool, logins in de productdatabase en advertentie-uitgaven in de advertentieplatforms.
2. Een connector kopieert die ruwe data volgens een vast schema naar één plek.
3. Die plek is het datawarehouse, bijvoorbeeld Snowflake, Databricks of BigQuery.
4. Datamodellen vormen de ruwe tabellen om tot dingen die de business herkent, zoals één rij per account, per opportunity en per klant per maand.
5. De semantic layer ligt boven op die tabellen. Hier definieer je de metrics en de dimensies waarnaar je ze kunt uitsplitsen.
6. Dashboards, spreadsheets en AI-agents vragen een metric op bij naam.

Let op wat dit met het CRM doet. Het wordt één bron naast andere, een belangrijke, maar niet dé bron van waarheid. Dat legt ook de lat hoger voor hoe je het CRM-datamodel ontwerpt, want stap vier is opgebouwd uit schone objecten en velden.

Stap vijf werkt alleen als stap vier goed is gedaan. Zit je accounttabel vol duplicaten, dan levert een perfecte definitie van winrate je een perfect berekend verkeerd cijfer op. En sommige bedrijven die ik spreek, zijn nog niet bij stap drie. Ze hebben geen datawarehouse, of ze bewaren er alleen productdata in. Geldt dat voor jou, dan is dat je eerste project.

Waarom go-to-market-metrics één beheerde definitie nodig hebben

Het rekenwerk in GTM is eenvoudig. Winrate is een deling. Het moeilijke zit in alles eromheen, want achter elke commerciële metric gaan vier beslissingen schuil. Je moet beslissen welke records meetellen, per welk moment, in welke eenheid en uit welk systeem.

Metric	Wat je moet beslissen
Pipeline	Dit kwartaal aangemaakt of vandaag open? Welke close dates? Afgezet tegen het plan of tegen de forecast?
Winrate	Tellen no-decisions als verloren? Deals die in de periode zijn gesloten, of een cohort van aangemaakte deals? Aantallen of dollars?
ARR	Begint de ARR bij ondertekening, bij go-live of bij de eerste factuur? Telt gebruik mee?
Actieve klant	Parent account of child account? Een betaalde factuur of een login? In welk tijdvenster?

Neem winrate. Dave Kellogg onderscheidt een smalle winrate, gewonnen deals gedeeld door gewonnen plus verloren deals, van een brede, die ook de no-decisions in de noemer zet. Beide zijn legitiem. Ze beantwoorden verschillende vragen.

Hoe groot kan het verschil worden? In een demo van Amazon Web Services (AWS) en dbt Labs kwam een query die simpelweg de kolom met bedragen optelde uit op $14,86 miljoen omzet, tegenover $11,36 miljoen volgens de beheerde definitie. De simpele query negeerde kortingen en terugbetalingen en telde geannuleerde orders en testaccounts mee, iets wat je nergens uit de tabelstructuur kunt afleiden.

Ik zou niet één definitie afdwingen waar er twee legitiem zijn. Houd ze allebei, geef ze verschillende namen en laat elk rapport vermelden welke het heeft gebruikt.

Hoe een semantic layer data van sales, finance en product verbindt

Nergens is het naamgevingsprobleem zichtbaarder dan tussen sales, finance en product. Stel dat een sportschoolketen met acht vestigingen een tweejarig contract tekent voor $15.000 per sportschool per jaar. Sales rapporteert $240.000 aan bookings, de facturatie brengt elk kwartaal $30.000 in rekening, finance erkent elke maand $10.000 omzet, en de ARR is $120.000. Alle vier de cijfers kloppen, en dezelfde uitsplitsing lopen we door in ons artikel over commerciële en financiële RevOps.

In onze Five Dots-kennisbank gebruiken we hiervoor een vuistregel. Het CRM verkoopt, het product levert, finance telt. Heeft het CRM een feit uit de andere twee nodig, zoals een gebruiksklasse of een healthsignaal, dan levert het systeem dat eigenaar is dat feit aan als read-only waarde. Het doel is één eigenaar per feit, niet één systeem voor alles.

Een semantic layer maakt dit werkbaar, omdat elk cijfer een eigen metric met een eigen naam wordt, met één systeem als eigenaar. De laag dwingt je ook om te maken wat de meeste bedrijven missen, een gedeeld klant-ID tussen het CRM-account, de klant in de facturatie en de workspace in het product. Zonder die sleutel valt er niets te koppelen.

Ook de definitie van "klant" doet ertoe. In een ander voorbeeld van Kellogg krimpt één divisie van een klant van 100 naar 80, terwijl een tweede divisie voor 40 koopt. De net revenue retention (NRR) is 80% als de tweede divisie als nieuwe klant telt en 120% als die bij dezelfde klant hoort.

Weet je niet zeker hoeveel van je kernmetrics meer dan één definitie hebben, dan brengt onze Revenue Operations Audit je strategie, processen, data en stack in kaart en laat die zien waar AI zich terugverdient.

Waarom AI-agents beheerde metricdefinities nodig hebben

Dit gold allemaal vijf jaar geleden ook al. Het weegt nu zwaarder, omdat een dashboard anders faalt dan een agent. Een dashboard zonder definitie laat niets zien. Een agent zonder definitie geeft je toch een antwoord.

Op twee academische benchmarks die zijn opgebouwd uit echte bedrijfsdata, kregen AI-agents die hun eigen queries schrijven 21,3% van de vragen in Spider 2.0 en 10,8% in BEAVER opgelost. De querytaal is het probleem niet. Het model weet niet welke tabel finance vertrouwt, wanneer je boekjaar begint en of verlengingen als pipeline meetellen.

Mag de agent alleen gedefinieerde metrics opvragen, dan verandert het beeld. In een test die dbt Labs in april 2026 uitvoerde scoorde de agent 100% op de vragen die de semantic layer dekte en 0% op de vragen die de laag niet dekte. De laag verandert "soms fout" in "goed of geweigerd". Gaat het om een cijfer voor de raad van bestuur of om een forecast, dan is dat de ruil die ik zou maken.

Een kanttekening. Deze vergelijkingen zijn uitgevoerd door leveranciers die een semantic layer verkopen, op kleine sets vragen, en een onafhankelijk onderzoek heb ik nog niet gevonden. Neem de exacte percentages met een korreltje zout.

Hoeveel werk dit kost, heb ik van dichtbij gezien. Een bedrijf waarmee ik werk, bouwde zijn semantic layer in dbt, waarbij elke metric in een bestand is gedefinieerd, in GitHub staat en wordt goedgekeurd voordat er iets aan verandert. Daarvoor stonden de definities in Confluence en in spreadsheets, en was de connector voor de AI-assistent uitgegroeid tot zo'n 60 handgeschreven queries. Inmiddels heeft de connector drie tools, die de metrics opsommen, een metric opvragen en de query achter het antwoord tonen. De laag bouwen kostte zes maanden en hij is nog niet af. De connector kostte dagen.

Die verhouding is de les. Reken op maanden voor de definities en op dagen voor de technologie. Dat verklaart ook een kloof in ons eigen onderzoek. In ons RevOps in 2026-rapport, een enquête onder 123 RevOps-professionals, heeft 73% van de mid-market B2B-SaaS-teams een AI-mandaat en 38% de data om dat te ondersteunen. Onze AI readiness scorecard voor commerciële teams toetst de rest van je fundament in 20 vragen.

Toen ik in de podcast Growth After Headcount sprak met Dora Kondeva, VP of Growth and Revenue Marketing voor EMEA bij Snowflake, maakte zij hetzelfde punt vanuit de marketingkant. Agents hebben beheerde data nodig en ze hebben context nodig. Wat een sterk betrokken account is, moet voor marketing en voor sales hetzelfde betekenen.

Mijn regel voor agents is kort. Beheerde metrics of geen cijfer. De assistent mag creatief zijn met de formulering, nooit met de berekening.

Waar je begint met een semantic layer in RevOps

Je begint niet met een tool. Je begint met een lijst, en je rekent op maanden werk en op onderhoud dat nooit ophoudt. Ik zou vijf dingen doen, in deze volgorde.

1. Verzamel de ongeveer 20 metrics uit je managementrapportage. Stel dezelfde vraag, bijvoorbeeld de pipeline van vorig kwartaal, in elk dashboard en aan elke AI-assistent die je hebt. Waar de antwoorden verschillen, heb je een woord gevonden dat niemand heeft gedefinieerd.
2. Leg per metric de vier beslissingen vast en wijs een eigenaar aan die je bij naam kunt noemen. De business is eigenaar van de definitie, en het datateam van de berekening.
3. Geef de concurrerende definities een naam in plaats van erover te ruziën. Bookings en ARR kunnen naast elkaar bestaan. "Omzet" met twee betekenissen kan dat niet.
4. Regel deze week twee goedkope dingen. Zet in je CRM de veldhistorie aan voor de opportunityfase, want de fasehistorie kun je later niet meer reconstrueren. En schrijf het CRM-account-ID weg op de klant in de facturatie en op de workspace in het product.
5. Kies daarna waar de definities komen te staan. Met één datawarehouse en één rapportagetool zou ik beginnen met de laag in het warehouse zelf, zoals de semantic views van Snowflake of de metric views van Databricks. Hebben meerdere tools en agents dezelfde cijfers nodig, kijk dan naar een losstaande laag zoals de dbt Semantic Layer of Cube.

Een opzet voor de semantic layer die we een B2B-SaaS-bedrijf zouden aanraden

Hoe zou dit er in de praktijk uitzien? MyGym24 werkt met een CRM, Stripe voor de facturatie, een eigen productdatabase en een handvol advertentieplatforms. Er is één analytics engineer, en Maria heeft haar lijst met 20 metrics.

De tabel laat de opzet zien die wij zouden aanraden. Het is een van meerdere goede opties, en elke tool erin kun je vervangen door een vergelijkbare. Waar het om gaat, is de volgorde van de lagen.

Laag	Wat MyGym24 gebruikt	Wat de laag doet
Database	Een datawarehouse in de cloud, in hun geval BigQuery gehost in de EU	Eén plek voor alle commerciële data, facturatiedata en productdata
Inkomende integratie	Managed connectors zoals Fivetran of Airbyte	Kopiëren het CRM, Stripe, de productdatabase en de advertentieplatforms volgens een vast schema naar het warehouse
Datamodellen	dbt, in een GitHub-repository	Maken van ruwe tabellen accounts, opportunities, abonnementen en gebruik
Semantic layer	De dbt Semantic Layer, in dezelfde repository	Bevat de metricdefinities als tekstbestanden
Gateway	Een read-only Model Context Protocol-server (MCP)	Laat de AI-assistent metrics opsommen en opvragen, en verder niets
Skills	Een kort instructiebestand per overleg	Bevat de zakelijke context voor de pipelinereview, de forecast en de verlengingen
Uitgaande integratie	Dashboards, Google Sheets, de AI-assistent en een sync terug naar het CRM	Iedereen leest dezelfde cijfers

Welke database en datamodellen als eerste komen

Waarom een warehouse en niet het CRM? Omdat het CRM facturen, logins en advertentie-uitgaven niet zo kan bewaren dat je ze kunt koppelen. Snowflake, Databricks en BigQuery kunnen het alle drie, dus kies het platform dat je engineers al kennen. Veel belangrijker is wat je als eerste modelleert, en MyGym24 begint met drie tabellen.

1. Eén accounttabel met het CRM-account-ID, het klant-ID uit Stripe en het workspace-ID uit het product. Dit is de gedeelde klantsleutel van eerder.
2. Eén opportunitytabel, plus een dagelijkse snapshot van de open opportunities. Zonder die snapshot bestaat "de pipeline van week drie" niet.
3. Eén abonnementstabel met één rij per klant per maand. ARR en NRR bereken je uit deze tabel, niet uit opportunitybedragen. ARR-snapshots in het CRM beschrijven we in een apart artikel.

Hoe je een metricdefinitie schrijft

Elke metric wordt een kort tekstbestand in dezelfde GitHub-repository als de datamodellen. In dbt is het formaat YAML, een formaat in platte tekst dat mensen en machines allebei kunnen lezen, en de exacte syntaxis staat in de MetricFlow-documentatie van dbt. Dit legt MyGym24 vast voor de smalle winrate.

Veld	Wat MyGym24 vastlegt
Naam	win_rate_narrow
Formule	Gewonnen opportunities gedeeld door gewonnen plus verloren opportunities
Uitgesloten	No-decisions, verlengingen en testrecords
Tijdsanker	Close date
Eenheid	Aantal deals, geen dollars
Uit te splitsen naar	Segment, regio, eigenaar en leadbron
Eigenaren	De Head of Sales voor de definitie, de analytics engineer voor de berekening

Je hoeft geen engineer te zijn om dit te lezen. Maria kan zien dat no-decisions zijn uitgesloten, dat de metric deals telt en geen dollars, en dat hij is verankerd aan de close date. Dat zijn de vier beslissingen van eerder, vastgelegd op de plek waar het cijfer wordt berekend.

Een wijziging werkt als een contractwijziging. Iemand stelt de wijziging voor in GitHub, de eigenaar uit de business keurt de definitie goed, de analytics engineer keurt de berekening goed, en pas dan gaat ze live, voor elk dashboard en elke agent tegelijk. Leg ook het vocabulaire vast. Bij het bedrijf dat ik noemde, zijn boekjaar en kalenderjaar hetzelfde, wat in de laag ontbrak en wat een assistent niet kan raden.

Hoe je dashboards, AI-agents en het CRM aansluit

Er zijn drie richtingen. De eerste is dashboards en spreadsheets. Sluit ze aan op de semantic layer in plaats van de formules in elke tool opnieuw te bouwen. dbt biedt bijvoorbeeld een integratie met Google Sheets, zodat finance de ARR in een sheet kan ophalen zonder een query te schrijven. Voordat je een dashboardtool koopt, ga je na of die metrics uit je laag kan lezen, anders definieer je alles twee keer.

De tweede is de AI-assistent. Die krijgt nooit directe toegang tot de tabellen. Hij praat met een kleine read-only gateway die de metrics kan opsommen, kan laten zien waarnaar je een metric kunt uitsplitsen, en de metric kan opvragen. dbt levert zo'n MCP-server mee, en het bedrijf dat ik noemde, bouwde in dagen een eigen server. Laat de gateway draaien met de rechten van degene die de vraag stelt, zodat verkopers nooit cijfers zien die ze niet mogen zien. Boven op de gateway zitten de skills, die de assistent vertellen welke metrics in de pipelinereview thuishoren en wat hij nooit zelf mag berekenen.

De derde is de weg terug naar het CRM. Een synctool, zoals Hightouch of Fivetran Activations, schrijft waarden zoals de ARR uit de facturatie, een gebruiksklasse of een health score als read-only velden op het accountrecord. Wat in het CRM terechtkomt, is de waarde, niet de formule.

Maria is eigenaar van de lijst met metrics en leidt de besluitvorming als twee teams het oneens zijn, en de analytics engineer is eigenaar van de modellen en de berekening. De tools zijn inwisselbaar. De volgorde is dat niet. Eerst de tabellen, dan de definities, dan de agents.

Waarom het eens worden over definities moeilijker is dan de technologie

De technologie wordt het makkelijke deel. De formaten zijn open, de modellen kunnen een eerste versie van de code schrijven, en elk dataplatform levert een eigen laag mee. Wat moeilijk blijft, is marketing, sales, customer success en finance het eens laten worden over wat een woord betekent, en dat vervolgens opschrijven. Dat is afstemmingswerk, en afstemming is altijd al het werk van RevOps geweest.

Een paar maanden later staat er in Maria's maandagoverleg één pipelinecijfer op het scherm, met daaronder een regel die zegt welke definitie is gebruikt. De assistent van de CEO geeft hetzelfde cijfer, en het overleg gaat over wat er met de pipeline moet gebeuren, niet over wiens cijfer klopt.

Wil je dat er een tweede paar ogen naar je eigen definities en je datafundament kijkt, dan is een Revenue Operations Audit de plek om te beginnen.

FAQ over de semantic layer

Wat is een semantic layer in eenvoudige woorden?

Een semantic layer is een gedeelde set metricdefinities, geschreven als code, die elk dashboard en elke AI-agent gebruikt om een cijfer te berekenen. Je vraagt de winrate op bij naam en de laag schrijft de databasequery, zodat de uitkomst in elke tool hetzelfde is.

Wat is het verschil tussen een semantic layer en een data dictionary?

Een data dictionary beschrijft wat een metric betekent, terwijl een semantic layer datgene is waaruit de metric wordt berekend. De data dictionary is een document dat mensen kunnen negeren. De semantic layer is code onder versiebeheer waar de tools doorheen moeten.

Heb je een datawarehouse nodig voordat je een semantic layer bouwt?

Ja, in de praktijk wel. De laag ligt boven op schone, gekoppelde tabellen, en die staan in een warehouse zoals Snowflake, Databricks of BigQuery. Zonder warehouse kun je CRM-data, facturatiedata en productdata niet in één definitie combineren.

Hoe lang duurt het om een semantic layer te bouwen?

Reken op maanden, niet op weken. Het bedrijf uit dit artikel had zes maanden nodig voor een eerste werkende laag en breidt die nog steeds uit, terwijl de connector voor de AI-assistent dagen kostte. De meeste tijd gaat zitten in het eens worden over de definities, niet in de software.