The semantic layer for go-to-market: what it is and how it helps

A semantic layer is the place where a company defines, once and as code, what each business number means, so that every dashboard, spreadsheet and AI agent calculates pipeline, win rate and annual recurring revenue (ARR) in the same way. For go-to-market (GTM) teams it ends the argument about whose number is right, and it is the difference between an AI agent that guesses and one you can trust with revenue data.

Picture Monday morning at MyGym24, the fictional fitness software company from my book The RevOps Pendulum. Maria, the Head of Revenue Operations (RevOps), asks how much pipeline the company has for this quarter.

Marketing says $4.2 million, because they count every opportunity created this quarter from a marketing lead. Sales says $3.1 million, counting open opportunities that close inside the quarter. Finance says $2.6 million and only trusts deals at the proposal stage. Then the CEO asks the company's new AI assistant, which answers with full confidence that the pipeline is $5 million. It added up every open opportunity, renewals and two test records included.

Four numbers for one question, and nobody made a calculation error. Each of them answered a slightly different question and gave it the same name. MyGym24 and its figures are invented, but the meeting will be familiar.

What a semantic layer is and how it differs from a data dictionary

Most companies have a data dictionary somewhere, a Confluence page or a spreadsheet that explains what a marketing qualified lead (MQL) is, how win rate is calculated and what counts as ARR. The problem is that nothing forces a dashboard to follow it. The document says one thing, and the report was built by someone who never read it.

A semantic layer is that same dictionary, written as code. The definitions live next to the data, every change gets reviewed, and the tools calculate the number from the definition itself. You ask for a metric by name, such as win rate by segment by quarter, and the layer writes the database query. The test is simple. If a number can still be calculated in two ways, the layer has not decided yet.

The idea is not new. Business Objects sold it in the early 1990s and called it a "universe". What changed is who is asking the questions. A dashboard is built once, by an analyst who knows the data. An AI agent writes a new query every single time, and it knows nothing about your business unless you tell it.

Where the semantic layer sits between the database and the dashboard

To see where the layer sits, follow one opportunity at MyGym24 on its way into Maria's meeting.

1. It starts in a source system, the customer relationship management (CRM) system. Subscriptions live in the billing tool, logins in the product database and ad spend in the ad platforms.
2. A connector copies that raw data into one place on a schedule.
3. That place is the data warehouse, for example Snowflake, Databricks or BigQuery.
4. Data models reshape the raw tables into things the business recognises, such as one row per account, per opportunity and per customer per month.
5. The semantic layer sits on top of those tables. Here you define the metrics and the dimensions you can slice them by.
6. Dashboards, spreadsheets and AI agents ask for a metric by name.

Notice what this does to the CRM. It becomes one source among several, an important one, but not the source of truth. It also raises the bar for how you design the CRM data model, because clean objects and fields are what step four is built from.

Step five only works if step four is done well. If your account table is full of duplicates, a perfect definition of win rate gives you a perfectly calculated wrong number. And some companies I talk to are not at step three yet. They have no data warehouse, or they only store product data in it. If that is you, that is your first project.

Why go-to-market metrics need one governed definition

The maths in GTM is easy. Win rate is a division. The hard part is everything around it, because every commercial metric hides four decisions. You have to decide which records count, as of when, in what unit, and from which system.

Metric	What you have to decide
Pipeline	Created this quarter or open today? Which close dates? Measured against plan or against forecast?
Win rate	Do no-decisions count as losses? Deals closed in the period, or a cohort of deals created? Count or dollars?
ARR	Does it start at signature, at go-live or at the first invoice? Does usage count?
Active customer	Parent account or child account? A paid invoice or a login? In which time window?

Take win rate. Dave Kellogg separates a narrow win rate, wins divided by wins plus losses, from a broad one that also puts the no-decisions in the denominator. Both are legitimate. They answer different questions.

How big can the gap get? In a demo by Amazon Web Services (AWS) and dbt Labs, a query that simply summed the amount column returned $14.86 million in revenue against a governed figure of $11.36 million. The simple query ignored discounts and refunds and included cancelled orders and test accounts, which nothing in the table structure tells you.

I would not force one definition where two are legitimate. Keep both, give them different names, and make every report say which one it used.

How a semantic layer connects sales, finance and product data

Nowhere is the naming problem more visible than between sales, finance and product. Say a gym chain with eight locations signs a two-year contract at $15,000 per gym per year. Sales reports $240,000 in bookings, billing invoices $30,000 every quarter, finance recognises $10,000 in revenue every month, and the ARR is $120,000. All four numbers are correct, and we walk through the same split in our post on commercial and financial RevOps.

In our Five Dots knowledge base we use a rule of thumb for this. The CRM sells, the product delivers, finance counts. Where the CRM needs a fact from the other two, like a usage band or a health signal, the owning system pushes it in as a read-only value. The goal is one owner per fact, not one system for everything.

A semantic layer makes this workable because each number becomes its own named metric with one owning system. It also forces you to create the thing most companies are missing, a shared customer ID between the CRM account, the billing customer and the product workspace. Without that key, nothing joins.

The definition of "customer" matters too. In another Kellogg example, one division of a customer shrinks from 100 to 80 while a second division buys 40. Net revenue retention (NRR) is 80% if the second division counts as a new customer and 120% if it belongs to the same one.

If you are not sure how many of your core metrics carry more than one definition, our Revenue Operations Audit maps your strategy, process, data and stack and shows where AI will pay off.

Why AI agents need governed metric definitions

All of this was already true five years ago. It matters more now because a dashboard and an agent fail differently. A dashboard without a definition shows nothing. An agent without a definition gives you an answer anyway.

On two academic benchmarks built from real enterprise data, AI agents that write their own queries solved 21.3% of the questions on Spider 2.0 and 10.8% on BEAVER. The query language is not the problem. The model does not know which table finance trusts, when your fiscal year starts, or whether renewals count as pipeline.

When the agent may only ask for defined metrics, the picture changes. In a test dbt Labs ran in April 2026, the agent scored 100% on the questions the semantic layer covered and 0% on the questions it did not cover. The layer turns "sometimes wrong" into "right or refused". For a board number or a forecast, that is the trade I would take.

A word of caution. These comparisons are run by vendors that sell a semantic layer, on small sets of questions, and I have not found an independent study yet. Take the exact percentages with a grain of salt.

I have seen the effort side of this up close. One company I work with built its semantic layer in dbt, with every metric defined in a file, stored in GitHub and approved before it changes. Before that, the definitions lived in Confluence and spreadsheets, and the connector for the AI assistant had grown to around 60 hand-written queries. Today it has three tools that list the metrics, query a metric and show the query behind the answer. Building the layer took six months and it is not finished. The connector took days.

That ratio is the lesson. Plan months for the definitions and days for the technology. It also explains a gap in our own research. In our RevOps in 2026 report, a survey of 123 RevOps practitioners, 73% of mid-market B2B SaaS teams have an AI mandate and 38% have the data to support it. Our AI readiness scorecard for revenue teams checks the rest of your foundation in 20 questions.

When I spoke with Dora Kondeva, Snowflake's VP of Growth and Revenue Marketing for EMEA, on the Growth After Headcount podcast, she made the same point from the marketing side. Agents need governed data and they need context. What a highly engaged account is has to mean the same thing for marketing and for sales.

My rule for agents is short. Governed metrics or no number. The assistant can be creative with the wording, never with the calculation.

Where to start with a semantic layer in RevOps

You don't start with a tool. You start with a list, and you plan for months of work and for maintenance that never ends. I would do five things, in this order.

1. Collect the 20 or so metrics in your leadership reporting. Ask the same question, for example last quarter's pipeline, in every dashboard and AI assistant you have. Where the answers differ, you found a word nobody has defined.
2. Write down the four decisions for each metric and add a named owner. The business owns the definition, and the data team owns the calculation.
3. Name the competing definitions instead of fighting about them. Bookings and ARR can both exist. "Revenue" with two meanings cannot.
4. Fix two cheap things this week. Switch on field history for the opportunity stage in your CRM, because you cannot rebuild stage history later. And write the CRM account ID onto the billing customer and the product workspace.
5. Then choose where the definitions live. With one data warehouse and one reporting tool, I would start with the layer inside the warehouse, like Snowflake's semantic views or Databricks' metric views. If several tools and agents need the same numbers, look at a standalone layer like the dbt Semantic Layer or Cube.

A semantic layer setup we would recommend for a B2B SaaS company

What would this look like in practice? MyGym24 runs a CRM, Stripe for billing, its own product database and a handful of ad platforms. There is one analytics engineer, and Maria has her list of 20 metrics.

The table shows the setup we would recommend. It is one of several good options, and every tool in it can be swapped for a comparable one. What matters is the order of the layers.

Layer	What MyGym24 uses	What it does
Database	A cloud data warehouse, in their case BigQuery hosted in the EU	One place for all commercial, billing and product data
Integration in	Managed connectors such as Fivetran or Airbyte	Copy the CRM, Stripe, the product database and the ad platforms into the warehouse on a schedule
Data models	dbt, in a GitHub repository	Turn raw tables into accounts, opportunities, subscriptions and usage
Semantic layer	The dbt Semantic Layer, in the same repository	Holds the metric definitions as text files
Gateway	A read-only Model Context Protocol (MCP) server	Lets the AI assistant list and query metrics, and nothing else
Skills	A short instruction file per meeting	Carries the business context for the pipeline review, the forecast and the renewals
Integration out	Dashboards, Google Sheets, the AI assistant and a sync back to the CRM	Everyone reads the same numbers

Which database and data models come first

Why a warehouse and not the CRM? Because the CRM cannot hold invoices, logins and ad spend in a way you can join. Snowflake, Databricks and BigQuery all do the job, so pick the one your engineers already know. Far more important is what you model first, and MyGym24 starts with three tables.

1. One account table that carries the CRM account ID, the Stripe customer ID and the product workspace ID. This is the shared customer key from earlier.
2. One opportunity table, plus a daily snapshot of open opportunities. Without the snapshot, "pipeline as of week three" does not exist.
3. One subscription table with one row per customer per month. ARR and NRR are calculated from this table, not from opportunity amounts. We describe ARR snapshots inside the CRM in a separate post.

How to write a metric definition

Each metric becomes a short text file in the same GitHub repository as the data models. In dbt the format is YAML, a plain text format that people and machines can both read, and the exact syntax is in dbt's MetricFlow documentation. This is what MyGym24 writes down for the narrow win rate.

Field	What MyGym24 writes down
Name	win_rate_narrow
Formula	Won opportunities divided by won plus lost opportunities
Excluded	No-decisions, renewals and test records
Time anchor	Close date
Unit	Number of deals, not dollars
Can be sliced by	Segment, region, owner and lead source
Owners	The Head of Sales for the definition, the analytics engineer for the calculation

You don't need to be an engineer to read this. Maria can see that no-decisions are excluded, that the metric counts deals and not dollars, and that it is anchored on the close date. Those are the four decisions from before, written down where the number is calculated.

A change works like a contract change. Someone proposes it in GitHub, the business owner approves the definition, the analytics engineer approves the calculation, and only then does it go live for every dashboard and agent at once. Write down the vocabulary too. At the company I mentioned, fiscal year and calendar year are the same thing, which was missing from the layer and which an assistant cannot guess.

How to connect dashboards, AI agents and the CRM

There are three directions. The first is dashboards and spreadsheets. Connect them to the semantic layer instead of rebuilding the formulas inside each tool. dbt, for example, offers a Google Sheets integration, so finance can pull ARR into a sheet without writing a query. Before you buy a dashboard tool, check that it can read metrics from your layer, or you will define everything twice.

The second is the AI assistant. It never gets direct access to the tables. It talks to a small read-only gateway that can list the metrics, show what a metric can be sliced by, and query it. dbt ships such an MCP server, and the company I mentioned built its own in days. Let it run with the permissions of the person asking, so a sales rep never sees numbers they are not allowed to see. On top of the gateway sit the skills, which tell the assistant which metrics belong in the pipeline review and what it must never calculate on its own.

The third is the way back into the CRM. A sync tool, such as Hightouch or Fivetran Activations, writes values like ARR from billing, a usage band or a health score onto the account record as read-only fields. What lands in the CRM is the value, not the formula.

Maria owns the list of metrics and chairs the decisions when two teams disagree, and the analytics engineer owns the models and the calculation. The tools are interchangeable. The order is not. Tables come first, definitions second, agents third.

Why agreeing on definitions is harder than the technology

The technology is becoming the easy part. The formats are open, the models can draft the code, and every data platform ships its own layer. What stays hard is getting marketing, sales, customer success and finance to agree on what a word means, and then writing it down. That is alignment work, and alignment has always been the job of RevOps.

A few months later, Maria's Monday meeting has one pipeline number on the screen, with a line underneath that says which definition it used. The CEO's assistant returns the same number, and the meeting is about what to do with the pipeline, not about whose number is right.

If you want a second pair of eyes on your own definitions and data foundation, a Revenue Operations Audit is the place to start.

Frequently asked questions about the semantic layer

What is a semantic layer in simple terms?

A semantic layer is a shared set of metric definitions, written as code, that every dashboard and AI agent uses to calculate a number. You ask for win rate by name and the layer writes the database query, so the result is the same in every tool.

What is the difference between a semantic layer and a data dictionary?

A data dictionary describes what a metric means, while a semantic layer is what the metric is calculated from. The dictionary is a document people can ignore. The semantic layer is version-controlled code that the tools have to go through.

Do you need a data warehouse before you build a semantic layer?

Yes, in practice you do. The layer sits on top of clean, joined tables, and those live in a warehouse such as Snowflake, Databricks or BigQuery. Without one, CRM, billing and product data cannot be combined into a single definition.

How long does it take to build a semantic layer?

Plan for months, not weeks. The company described in this article needed six months for a first working layer and is still extending it, while the connector for its AI assistant took days. Most of the time goes into agreeing the definitions, not into the software.