dbt Semantic Layer Is the Missing Contract Between Analysts and Data

Raw event data is an implementation detail. Analysts should query metrics, not event schemas. Build a dbt semantic layer that defines metrics — sessions, conversions, engagement_score, customer_lifetime_value — once, on top of tested, documented, version-controlled SQL models.

Use dbt's incremental materialisation for large event tables (merge on a unique event key, partition by event_date). Add data quality tests: unique session keys (for GA4, user_pseudo_id plus ga_session_id, since ga_session_id alone is not unique), not_null timestamps, accepted_values for event_names, relationships between sessions and users.

When the GA4 schema changes, only one dbt model needs updating rather than dozens of downstream queries. When a stakeholder asks how an engaged user is defined, the answer is in version-controlled dbt documentation.

The layered architecture matters: staging models flatten and type raw data, intermediate models compute business logic (sessionisation, attribution), and mart models serve specific analytical domains (marketing, product, finance). Each layer has clear ownership and testing contracts.

This is the difference between a data team and a data organisation. When every report, dashboard, and notebook references the same metric definitions — tested in CI, documented automatically, and version-controlled in Git — the 'differing numbers' problem that plagues analytics teams without this foundation is eliminated.