dbt Core Integration
Your dbt Core semantic layer defines the metrics. KPI Tree shows how they drive each other, who owns them, and what to do when they move.
You have spent months defining metrics, dimensions, time grains, and aggregations in dbt Core. That work gives you governed, version-controlled definitions. It does not tell you which metrics drive which with confidence, who is accountable when a number moves, or whether the last thing anyone tried actually worked. KPI Tree reads your semantic manifest and renders the SQL from it directly, so there is no dbt Cloud API and no subscription in the loop. It runs that SQL against your own warehouse, imports every definition exactly as written, and adds the layer above: a causal metric tree with statistical significance on every edge, RACI ownership tied to real people, and a closed loop from anomaly to verified impact. Your dbt project stays the single source of truth for how metrics are calculated.
Live in minutes, not weeks
Compile your semantic manifest, upload it, and link the warehouse your models are materialised in. Every metric is then ready to organise into a tree with clear ownership.
Compile and upload your semantic manifest
Run dbt parse (or dbt build) to produce semantic_manifest.json in your target/ directory, then upload it. Drag and drop through the UI, or automate it with curl, a Python script, or the ready-made GitHub Actions workflow. Include manifest.json in a ZIP of the target/ directory to also unlock data model exploration: upstream tables, columns, and lineage.
Link the warehouse your models run in
dbt Core defines the metrics but does not execute anything. KPI Tree renders each metric as MetricFlow SQL in your warehouse's own dialect and runs it against a linked warehouse connection: Snowflake, BigQuery, Databricks, Redshift, or PostgreSQL. One aggregation query per metric, on a schedule you set.
Build your metric trees
Every metric and dimension from your dbt project is imported automatically, with its aggregation type read straight from the model. Arrange them into a tree that reflects real cause and effect, assign RACI owners, and route anomalies. When your dbt project evolves, re-sync and KPI Tree applies a diff, 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 the governed definitions you have already built and extends them into operational territory the semantic layer does not cover: causation, ownership, and verified outcomes.
Your governed definitions, imported exactly as written
Every metric, dimension, entity, measure, and time grain imports with its labels and descriptions intact. Nothing is re-mapped or translated. Aggregation type is read directly from the model, so sum, average, first, and last behave the way your dbt definition says, including a First Value aggregation for point-in-time metrics.
One query per metric, all downstream analytics off-warehouse
Each metric runs a single aggregation query on a schedule you set, returned as Apache Arrow and cached. Comparison periods, week and quarter rollups, correlations, regressions, and outlier detection all run in KPI Tree's own compute engine, and per-metric results are cached again in the browser, so exploring never re-hits your warehouse. The warehouse bill stays flat as you add metrics.
Continuous, diff-based sync from your repo
Wire your repo up once and every merge to main keeps KPI Tree current. Because each re-sync applies as a diff rather than a rebuild, definition changes flow straight through while your trees, ownership, and action history stay exactly where you left them.
See which metrics drive which across your entire business.
Your dbt project defines metrics one at a time. KPI Tree connects them into a causal model. Arrange metrics into a tree that reflects real business causation, from operational inputs up to revenue, then trace any movement down to the specific driver that moved. Every driver edge is scored by proprietary ML models and statistical tests, using Pearson and lagged cross-correlation, partial correlation, and Granger causality with Benjamini-Hochberg correction, so each relationship carries a confidence level and you are working from evidence that survives significance testing, not assumption. When a number breaches its baseline, root-cause detection traces the anomaly down the tree automatically.
- Every metric and dimension from your dbt project, imported automatically
- Drag-and-drop tree builder for cause-and-effect relationships
- Driver edges scored by proprietary ML models and statistical tests, with a confidence level on every edge
- Root-cause detection traces anomalies down the tree automatically
Your metric trees update every time your dbt project changes.
The connection wizard generates a complete GitHub Actions workflow. On every push to main it runs dbt build and posts the artifacts to KPI Tree, so new metrics are added, removed ones are flagged, and changed definitions are updated. Your workspace domain and connection ID are set as workflow variables, so the only secret you add to the repo is a single scoped API key. Four upload methods cover any workflow: GitHub Actions, curl, a Python script, or drag-and-drop through the UI. Re-syncs are diff-based, so your trees, ownership assignments, and action history are never rebuilt.
- Ready-made GitHub Actions workflow generated in the connection wizard
- Automatic sync on every merge to main
- One scoped API key secret, no other credentials in the repo
- 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 declares which dimensions apply to each metric. KPI Tree reads those declarations, queries their distinct values on your warehouse, and generates a child metric for each value. Each child appears as its own node on the tree with its own owner and its own tracking, so when Revenue by Region dips you see exactly which region moved and who is accountable. High-cardinality dimensions are detected and skipped automatically to keep the tree navigable. No changes to your dbt YAML required.
- Reads dimensions directly from your existing dbt definitions
- Auto-generates a child metric 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 movement to verified impact.
Your dbt project is the source of truth for how metrics are calculated, and that never changes. KPI Tree adds what a semantic layer does not attempt to provide. Every metric gets full RACI ownership tied to a real person, their team, and their manager, not an owner text field. When a metric breaches its baseline, the anomaly is pushed to the Accountable owner across Slack, email, WhatsApp, or SMS, with org-chart escalation if it is not picked up. Actions are tracked against the metric they target, and impact is verified against the statistical baseline rather than self-reported. Business-model budgets and forecasts run through the same pipeline as actuals.
- dbt project remains the sole source of truth for calculations
- Full RACI ownership per metric, tied to team and manager
- Anomalies pushed to the accountable owner across Slack, email, WhatsApp, and SMS with escalation
- The MCP server exposes RACI, significance-tested drivers, and verified impact to AI assistants
What makes this different from a dashboard on your dbt metrics
Most tools that consume dbt metrics display them in charts or flat catalogues. Portable-semantics standards such as OSI, and the trend toward shared metric definitions, only standardise what a metric is: its aggregation, dimensions, and time grain. None of that standardises who owns a metric, what drives it with confidence, or whether the last action moved it. That is the layer KPI Tree adds, and it grows more valuable as the substrate below it becomes a commodity.
Every source resolves onto one causal tree.
No dbt Cloud subscription, no dbt Cloud API
Teams on dbt Core get full semantic-layer consumption with no extra SaaS dependency. KPI Tree renders the SQL from your semantic manifest itself, so your open-source investment is all you need. If you later migrate to dbt Cloud, there is a dedicated dbt Cloud integration that connects through the Semantic Layer API instead.
A causal layer, not a flat metric list
A dashboard shows what happened. KPI Tree shows why. Your dbt metrics become a tree where every edge carries a confidence level from statistical tests, not a hand-drawn diagram or a graph-walk. When a number moves unexpectedly, you trace the cause through the tree instead of guessing.
Owned, routed, and verified action
dbt governs how metrics are calculated. KPI Tree adds who owns each one, routes the anomaly to that person on the channel they actually read, and verifies whether their action moved the number against the baseline. Every tool claims insights to action; KPI Tree closes the loop and shows the proof.
Related integrations. More sources that work with KPI Tree.
Common questions
Do I need a dbt Cloud subscription?
Which versions of dbt Core are supported?
Where does the metric SQL actually run?
Does KPI Tree respect my metric's aggregation?
How does the automatic sync work?
What happens when my dbt project changes?
Which warehouses can KPI Tree run the metric SQL against?
How do dimension breakdowns work?
Can I also upload the standard manifest.json?
Should I use this or the dbt Cloud integration?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with dbt Core.
How to build a metric tree
A step-by-step metric tree and KPI tree template from North Star to daily levers
Metric decomposition
Break any business metric into the components that drive it
Semantic layer vs business context layer
A semantic layer settles what a metric is. It cannot settle how metrics drive each other, who owns them, or what happens when one moves.
Your dbt metrics already exist. Now give them causal structure, ownership, and a closed loop.
Connect your dbt Core project to KPI Tree. It renders the SQL against your own warehouse, imports every governed definition, and adds statistically significant drivers, RACI ownership, and verified impact in minutes. No dbt Cloud required.
