Semantic Layer
Define the metric once, serve it everywhere
The semantic layer defines business metrics once — revenue, active users, churn — and serves them consistently to every dashboard, notebook, and AI tool. It is the single source of truth that ends metric anarchy.
What you will learn
- Explain the problem the semantic layer solves
- Define a metric object with where-filters and cumulation semantics
- Decide what belongs in the semantic layer vs the mart
What is this?
A semantic layer is a server that exposes business metrics defined in one place — revenue, MRR, D7 retention — with their filters, grains, and time-window semantics, to any consumer that asks. Whether the client is a BI tool, a notebook, or an AI assistant, the metric is computed the same way every time.
Why do you need it?
- It ends the five-definitions-of-revenue wars at weekly metric review.
- Definitions live in codified, testable form near the data, not in a slide deck.
- It gives self-serve + governed access: analysts build on metrics, without redefining them.
Mental model
Every department keeps its own price list
One published catalog with one price per item
The catalog (semantic layer) is the canonical list everyone quotes from, so 'revenue' means the same number in sales, finance, and product.
How it works
- Write metric definitions: name, description, aggregation, measure, grain, filters.
- Attach time-window and cumulation semantics for rolling measures.
- Publish a metrics API that BI and notebooks query.
- Consumers ask for the metric by name and get a consistently computed result.
Consumers ask one API for metrics computed from the same definitions.
In production
- Dashboards, Excel, and a new AI assistant all query 'MRR' and agree within one run.
- Metric governance review changes a definition in one place and every surface updates.
- Self-serve analysts compose metric-on-metric without copying logic into notebooks.
Best practices
- Define the grain and time semantics explicitly on every metric.
- Tag metrics with owners and status so 'approved' vs 'draft' is visible.
- Keep the layer thin: business metrics, not every possible transformation.
Common mistakes
- Using the semantic layer as a second transformation engine and duplicating model logic.
- Defining metrics with different grains under the same name.
- Exposing metrics with no owner, so no one can be challenged on a definition.
Debugging tips
- If two surfaces disagree after the semantic layer, check their params (grain/time window), not the definition.
- If a metric is slow, inspect the generated SQL — poor measure definitions generate hunting queries.
Interview checkpoint
Quick quiz
A semantic layer guarantees
Duplicate metric definitions across tools result in