dbt Core IntegrationYour dbt Core investment is about to pay off in a way dashboards never could.
You have spent months defining metrics, dimensions, and time grains in dbt Core. That work gives you governed, version-controlled definitions. But it does not tell you which metrics cause which, who is responsible when something moves, or what anyone is doing about it. KPI Tree consumes your existing semantic layer and adds the operational layer on top: causal trees that show how metrics drive each other, RACI ownership so the right person acts, and a closed loop from anomaly to resolution. No dbt Cloud subscription required. Your dbt project stays the single source of truth.
Live in minutes, not weeks
Connect your dbt project, point at your warehouse, and every metric is ready to organise into trees with clear ownership.
Connect your dbt project
Upload your semantic manifest through the UI, or automate it with the ready-made GitHub Actions workflow so your metrics stay in sync on every merge. curl and Python upload options are also available for teams with existing CI/CD pipelines.
Point at your warehouse
Tell KPI Tree which warehouse your dbt models are materialised in. Snowflake, BigQuery, PostgreSQL, Redshift, Databricks, and others are all supported. KPI Tree queries the warehouse directly to fetch metric values.
Build your metric trees
Every metric and dimension from your dbt project is imported automatically. Arrange them into cause-and-effect trees. Assign owners. When your dbt project evolves, re-sync and KPI Tree picks up the changes while preserving your existing trees, ownership, and action history.
Everything your semantic layer defines, plus the layer it was never designed to carry
KPI Tree is a first-class consumer of the open-source dbt semantic layer. It starts from what you have already built and extends it into operational territory.
Full metric catalogue import
Every metric, dimension, entity, measure, and time grain from your dbt project is imported with labels and descriptions intact. Nothing is re-mapped or translated. Your governed definitions carry through exactly as written.
Continuous sync via GitHub Actions
The connection wizard generates a ready-made GitHub Actions workflow. On every push to main, your metrics sync automatically. Three repository secrets are all you need. Your metric trees always reflect the latest version of your dbt project.
Automatic dimension breakdowns
Enable dimension metrics and KPI Tree generates breakdowns for every dimension attached to each metric. "Revenue" becomes "Revenue (Region: EMEA)", "Revenue (Region: APAC)", and so on. High-cardinality dimensions are detected and skipped automatically.
See which metrics drive which across your entire business.
Your dbt project defines metrics individually. KPI Tree connects them into a causal model that shows how they relate. Arrange metrics into parent-child trees that reflect real business causation. When revenue drops, trace the cause through the tree to the specific input metric that moved. Statistical analysis validates the relationships so you are working from evidence, not assumptions.
- Every metric and dimension from your dbt project, imported automatically
- Drag-and-drop tree builder for cause-and-effect relationships
- Statistical validation of causal links between metrics
- Re-sync preserves existing tree structures, ownership, and action history
Your metric trees update every time your dbt project changes.
The connection wizard generates a complete GitHub Actions workflow. On every push to main, the workflow runs your dbt build and uploads the results to KPI Tree. New metrics are added. Removed metrics are flagged. Changed definitions are updated. Your trees, ownership assignments, and action history stay intact. Four upload methods are available to suit any workflow: GitHub Actions, curl, Python script, or drag-and-drop through the UI.
- Ready-made GitHub Actions workflow generated in the connection wizard
- Automatic sync on every merge to main
- Diff-based updates: new metrics added, removed metrics flagged
- Four upload methods for teams with different CI/CD setups
Break any metric down by dimension without changing your dbt project.
Your dbt project already defines which dimensions apply to each metric. KPI Tree reads those definitions and generates a child metric for every dimension value. Each child appears as its own node on your metric tree with its own owner and its own tracking. When "Revenue by Region" dips, you see exactly which region moved and who is responsible. No changes to your dbt YAML required.
- Reads dimensions directly from your existing dbt definitions
- Auto-generates child metrics for each dimension value
- High-cardinality dimensions detected and skipped to keep trees navigable
- Each dimension metric gets its own ownership and tracking
dbt defines the metrics. KPI Tree closes the loop from insight to action.
Your dbt project is the source of truth for how metrics are calculated, and that does not change. KPI Tree adds what dbt was never designed to carry: RACI ownership at the metric level, push notifications when metrics move outside expected ranges, action tracking against specific metrics, and impact verification after the fact. The result is a closed loop where governed definitions lead to clear accountability and measurable outcomes.
- dbt project remains the sole source of truth for calculations
- RACI ownership, notifications, and action tracking per metric
- AI assistants access enriched dbt metrics via the MCP server
- Causal relationships and statistical analysis on governed definitions
What makes this different from a dashboard on your dbt metrics
Most tools that consume dbt metrics display them in charts or flat catalogues. KPI Tree starts from the same definitions but takes them somewhere different.
No dbt Cloud subscription required
Teams on dbt Core get full semantic layer consumption without any additional SaaS dependency. Your existing open-source investment is all you need. If you later migrate to dbt Cloud, KPI Tree supports that path too.
Causal trees, not flat metric lists
Dashboards show you what happened. Metric trees show you why. Arrange your dbt metrics into parent-child hierarchies that represent real business causation. When a number moves unexpectedly, trace the cause through the tree instead of guessing.
Ownership and accountability on every metric
dbt governs how metrics are calculated. KPI Tree adds who owns each one, what actions are being taken, and whether those actions moved the number. The combination closes the loop from definition to impact.
Related integrations
Other data sources that work with KPI Tree.
Common questions
- No. KPI Tree works directly with your dbt Core project. There is no dependency on dbt Cloud. If you later migrate to dbt Cloud, KPI Tree has a dedicated dbt Cloud integration that connects via the Semantic Layer API.
- dbt Core 1.6 or later. That is when MetricFlow and the semantic manifest were introduced.
- The connection wizard generates a GitHub Actions workflow. It triggers on push to main, runs dbt build, and uploads the results to the KPI Tree API. You add three secrets to your repository and your metric definitions stay synchronised with every merge.
- KPI Tree compares the new version against the previous one. New metrics are added, removed metrics are flagged, and changed definitions are updated. Your existing tree structures, ownership assignments, and action history are preserved.
- Any warehouse dbt Core supports. During setup you point KPI Tree at whichever warehouse your dbt models are materialised in: Snowflake, BigQuery, PostgreSQL, Redshift, Databricks, and others.
- When enabled, KPI Tree reads each metric's dimensions from your dbt project, queries their distinct values, and generates a child metric for each one. "Revenue" with a Region dimension becomes "Revenue (Region: EMEA)", "Revenue (Region: APAC)", and so on. High-cardinality dimensions are skipped automatically to keep trees navigable.
- Yes. Including manifest.json alongside the semantic manifest unlocks data model exploration: upstream tables, columns, and DAG lineage. It gives your team visibility into where metrics come from at the model level. Metric sync itself is driven entirely by the semantic manifest.
- If you have a dbt Cloud Team or Enterprise plan, use the dbt Cloud integration. It connects directly to the Semantic Layer API and requires no manifest uploads. This integration is for teams running dbt Core without dbt Cloud.
Related guides
Deep dives into the frameworks and metrics that work with dbt Core.
Your dbt metrics already exist. Now give them structure, ownership, and a closed loop.
Connect your dbt Core project to KPI Tree. Every metric imported with causal trees, RACI ownership, and action tracking in minutes. No dbt Cloud required.
