- Report tables (
rpt_*): fastest for common dashboard-style questions - One Big Tables (
obt_*): flexible analysis with pre-modeled joins and business logic - Semantic metrics: a single “metric definition layer” so the same metrics power dashboards and saved queries
- Managed BI dashboard tiles
- The SQL Query Library
Metric definitions (single source of truth)
Metric definitions are documented in: In the dbt project, semantic layer definitions live undermodels/semantic/ (semantic models + metrics + saved queries).
When to use semantic metrics vs raw tables
Use semantic metrics when you need:- Consistent metric logic across tools (dashboards, ad-hoc analysis, exports)
- Standardized naming (no “two versions” of CAC/ROAS/net revenue)
- The ability to group metrics by dimensions without re-writing business logic
- Custom fields not covered by metrics
- Deep row-level inspection and debugging
Saved queries (recommended starting points)
The semantic layer includes a set of saved queries designed to match common “dashboard tile” questions. If you’re using the Query Library, these saved queries also map cleanly to sections/recipes.“Dashboard tile” mappings above are intended as practical starting points, not hard guarantees. Not every brand has every integration, and coverage can vary by source system.
How this relates to the SQL Query Library
If you prefer writing SQL directly in BigQuery, the Query Library recipes are pre-built around the same core concepts:- Valid order filtering (
is_order_sm_valid = TRUE) - Stable “analysis tables” (
obt_*andrpt_*) - Lowercased categorical groupings for safe aggregation
(Optional) Querying via dbt Semantic Layer
If you have dbt Semantic Layer tooling enabled (e.g., MetricFlow), you can query metrics using a CLI interface instead of writing SQL.If you don’t have Semantic Layer tooling enabled, use the SQL Query Library + OBT/RPT tables instead.

