Semantic Layer

A semantic layer is the shared business vocabulary and rules that translate raw tables into consistent, human‑readable metrics and dimensions. It turns questions like “What do we mean by revenue?” into reusable definitions every chart and query uses.

In depth

A semantic layer sits between your storage systems and your analysis tools. It models entities, relationships, metrics, and dimensions using names the business understands. Instead of exposing table columns like “invoice_total” or “cust_id”, it publishes “Revenue”, “Customer”, and “Invoice Date” with calculation rules and filters built in.

A semantic model typically includes:

  • Entities and relationships: For example, customers, orders, and products, with defined joins and keys.
  • Metrics and calculations: For example, “Revenue”, “MRR”,  “Active Users”, with formulas and aggregation rules.
  • Dimensions: For example, time, region, product, or plan.
  • Constraints and policies: For example, access control, metric certification, and default filters.

This layer separates business logic from physical tables. This enables you to change a source or add a new table without breaking downstream dashboards, because users depend on named metrics rather than hidden SQL.

Pro tip

Name metrics for decisions, not for tables. For example, “New MRR” is a better name than “fact_subscriptions.amount_sum.” Add a short description and an owner to improve trust.

Why Semantic Layers matter

A well-run semantic layer makes for faster, more-informed decisions.

  • Shared meaning: Teams use the same certified definitions for “Revenue”, “Net MRR Churn Rate”, and “ARPU”.
  • Centralized organization: Logic lives in one place instead of being scattered across spreadsheets and dashboards.
  • Governance with agility: Data teams control definitions so business users can explore independently and safely.
  • Change management: Upstream changes are versioned and communicated, so reports stay current.

Semantic Layers – In practice

  1. Pick your top 10 questions. Define the metrics that will answer them, such as “MRR”, “Active Users (28‑day)”, and “Lead-to‑SQL Rate”.
  2. Write metric statements. Include name, description, formula, grain, filters, and source lineage.
  3. Model joins. Declare keys and one‑to‑many rules to prevent double counting.
  4. Encode default logic. Set canonical time grains, time window definitions, and currency formats.
  5. Set access rules. Limit access to sensitive information and publish certified versions for company-wide use.
  6. Version and test. Stage changes, run sample queries, and note unexpected shifts in values.

Semantic Layers and PowerMetrics

PowerMetrics applies a metric‑centric approach that integrates well with a semantic layer.

  • Metric catalog: Create shared, human‑readable definitions with names, formulas, dimensions, and descriptions.
  • Certification and tagging: Highlight trusted metrics so teams choose the right version.
  • Explorer and published views: Investigate and personalize metrics in a free-form way and share your insights with published dashboards or embeds.
  • Access control: Use roles and groups to manage who can create, edit, certify, or view.
  • Data modelling and formulas: Perform lightweight modelling. Join data sources. Combine metrics with calculations using familiar, Excel-like functions.
  • Stored history and comparisons: Maintain historical values for audits and time‑series analysis.
  • Integrations: Connect to data in warehouses and popular semantic layers, like dbt and Cube, for visualization and analysis in PowerMetrics.

Related terms