Decoded GA4 in Lightdash —
self-serve BI on top of
your dbt models.
Lightdash is BI built on top of dbt. It reads dbt models and metrics directly, so the governance you already have in your dbt project becomes the access layer for non-engineers. For Decode users on dbt, Lightdash is the natural next step — the events table is already a clean source, the models are already there, the metrics already exist.
Lightdash treats your dbt project as the source of truth. Whatever the models contain becomes what the BI tool exposes. Garbage in, garbage out — and a hand-built UNNEST staging layer is, structurally, the garbage.
What Lightdash inherits from dbt
Lightdash reads the dbt project directly. Models become tables in the BI tool. Dimensions and metrics defined in YAML next to those models become the dropdown options in the explore view. Tests, lineage, documentation — all inherited. The advantage is that there is no second metric layer to keep in sync. The disadvantage is that any mess in the dbt project becomes a mess in Lightdash.
Why nested GA4 makes that mess
If your dbt project sources GA4 from the raw export, you have a stg_ga4__events.sql file full of UNNEST scaffolding. Every model downstream of it is partially shaped by which parameters you remembered to flatten. Lightdash exposes the result — including the scaffolding. Analysts see column names that look like flatten artefacts because that is what they are.
What changes with Decode GA4
The decoded events table is declared as a dbt source. Models reference it through source('decode_ga4', 'events') with no UNNEST in between. The columns you expose to Lightdash are the actual event parameters — page_location, page_referrer, event_name — rather than artefacts of a flattening step. Self-serve users see dimensions that look like the GA4 event spec, because they are.
The traditional approach
UNNEST in dbt, expose the result to Lightdash
Keep stg_ga4__events.sql as a CROSS JOIN UNNEST of every parameter you care about. Build the metrics layer on top. Lightdash works, but every new event parameter requires a code change in the staging file before self-serve users can ever see it.
Use a community dbt package
Adopt a public GA4 dbt package, point Lightdash at its outputs. You inherit somebody else's modelling decisions and somebody else's release cadence. Customisations live alongside or override the package, which is a maintenance pattern dbt teams know well and dread.
Skip dbt entirely and connect Lightdash to GA4 directly
You cannot. Lightdash is built on dbt — that is the whole point. The closest equivalent is to use a different BI tool that does talk to BigQuery natively, but then you give up the dbt-as-metric-layer story that brought you to Lightdash in the first place.
Decode GA4 vs DIY UNNEST staging in Lightdash
| Feature | Decode GA4 source | Hand-built dbt staging |
|---|---|---|
| Lines of SQL in stg_ga4__events | Thin renaming or none | Hundreds, growing |
| New event parameter visibility | Auto-detected, exposed in next refresh | Code change required first |
| Dimension names in Lightdash | Match GA4 spec | Match flatten artefacts |
| dbt run cost on schema change | Picked up upstream | Full refresh of staging tree |
| Onboarding a new analyst | Standard dbt patterns | Must learn UNNEST first |
| Maintenance over a year | Zero | Recurring SQL updates |
Decode populates the events source. dbt models reference it. Lightdash reads the dbt project. Same chain you already use for every other source.
- [ 1 ]
Subscribe via Google Cloud Marketplace
Decode GA4 ships as a Marketplace listing. Usage-based pricing, no monthly minimum, billed through your existing GCP invoice. Subscription takes about a minute.
- [ 2 ]
Connect Lightdash to the dbt repo
In Lightdash, connect a Git repo containing your dbt project. Lightdash auto-reads dbt_project.yml and the model files. No model translation required.
- [ 3 ]
Add BigQuery warehouse credentials
In Lightdash project settings, add the GCP project ID, the dbt output dataset, and a service account with BigQuery Data Viewer plus Job User. Storage Object Viewer on the Decode GCS bucket — the events table is an external table backed by Parquet.
- [ 4 ]
Reference the events source in a dbt model
Write a model that selects partition_date, event_name, event_param.page_location, count(*) as pageviews from
{{ source('decode_ga4', 'events') }}where event_name = 'page_view' group by 1, 2, 3. Define dimensions and metrics in the YAML alongside the model. Trigger a dbt project refresh in Lightdash and the explore view appears.
HOW THE SETUP WORKS
Wire decoded GA4 into Lightdash in four steps. dbt is doing the heavy lifting; Lightdash is reading the result; Decode is keeping the source flat.
GCP
Run the Decode GA4 installer with the events_external template. Pick the dataset your dbt project uses for sources.
GCP
Create a service account with BigQuery Data Viewer, Job User, and Storage Object Viewer on the Decode bucket.
Lightdash
Connect the dbt repo and add the BigQuery warehouse credentials in project settings.
dbt + Lightdash
Write a model on the decoded events source, define dimensions and metrics in YAML, refresh the project in Lightdash.
Lightdash reads the dbt project for structure and BigQuery for data. The decoded events table is an external table over Parquet in your GCS bucket — Lightdash queries it through the BigQuery adapter, the data never leaves your perimeter.
What you get in Lightdash
Self-serve over your existing dbt models
The dbt graph you already maintain is the metric layer. Lightdash exposes it as explore views, charts, and dashboards without duplicating definitions in a second tool.
Dimension names that match the GA4 spec
page_location, page_referrer, ga_session_id and the rest appear in the explore view as named in the spec. Self-serve users see the same dimensions they would see in the GA4 UI.
Metrics defined in YAML, in Git
Lightdash reads metric definitions from the model YAML files. Pull requests govern changes. Every metric has provenance — anyone can find the file that defines it.
External-table economics
The events source is an external table over Parquet in GCS. Lightdash queries it through BigQuery, but you are not paying for duplicate storage. Compute costs are partition-pruned scans of flat columns.
Schema evolution that does not block self-serve
When GA4 adds an event parameter, the decode run picks it up and the source schema reflects it. Existing models keep building. The new dimension is available in the next dbt refresh.
The lowest-effort BI layer for dbt teams
If you already have Decode GA4 and a dbt project, Lightdash adds the BI layer in less work than any alternative. The events source is clean. The models exist. The metrics are defined. Lightdash is the thin layer that makes them browsable.
Marketing self-serve on attribution models
The dbt attribution mart — sources, mediums, campaigns, landing pages — exposed to marketers as a Lightdash explore view. They build their own charts. The metrics stay defined in the dbt YAML, so the analytics team still owns the truth.
Product team funnel exploration
Funnel models built on decoded events — view_item, add_to_cart, begin_checkout, purchase — exposed as a single Lightdash explore. PMs slice by device, geo, custom event_param. The dbt model behind it is shorter than the YAML that exposes it.
Cross-functional KPI dashboards
One Lightdash dashboard per business unit, each pulling from the same dbt mart on top of decoded events. When the underlying definitions change in dbt, every dashboard inherits the change automatically.
Do I have to use dbt with Lightdash?
Yes — Lightdash is built on dbt. Models, metrics, dimensions, tests all come from the dbt project. If you do not have dbt, look at Looker Studio or Steep instead. See dbt setup →
What permissions does the service account need?
BigQuery Data Viewer and Job User on the project, plus Storage Object Viewer on the Decode GCS bucket — the events table is an external table backed by Parquet files. Full prerequisites →
Can I run Lightdash self-hosted as well as Lightdash Cloud?
Yes. The integration is at the dbt + BigQuery layer, not the Lightdash deployment layer. Self-hosted, Cloud, and the open-source variant all read the same dbt project the same way.
Will my existing dbt metrics and dimensions still work?
Yes. Decoded GA4 changes the source — the events table — not the modelling layer. Existing metrics keep their definitions. New dimensions become available as you reference the new direct columns in your models.
Deploy in under 5 minutes
Self-serve BI
on a dbt project
that does not fight back.
Subscribe via Google Cloud Marketplace, point destination_dataset_id at your dbt sources dataset, and have Lightdash exposing decoded GA4 dimensions to non-engineers before the end of the day.
Google Cloud Marketplace · Usage-based · No monthly minimum