dbt Cloud Integration
Your 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 already invested in dbt Cloud to govern your metric definitions in one place. That solves metric consistency. It was never designed to answer the next set of questions: which metrics cause which, who is accountable when one moves, and what is being done about it. KPI Tree reads your entire metric catalogue through the dbt Cloud Semantic Layer API, with no dbt CLI to install and no manifest uploads, and never re-implements a single calculation, so the numbers always match dbt. On top of that governed foundation it adds a causal metric tree, RACI ownership, and a closed action loop. Your dbt project stays untouched, your definitions stay governed, and you get far more from the work you have already done.
Live in under two minutes
Provide a read-only service token and your Environment ID. KPI Tree imports every metric, dimension, time grain, and aggregation type from your semantic layer automatically.
Create a read-only service token
In dbt Cloud, generate a service token scoped to "Semantic Layer Only" and "Metadata Only". Both are read-only. KPI Tree never writes to your dbt project, models, or deployment configuration.
Connect and import your metric catalogue
Enter the service token and your Environment ID. KPI Tree runs a background sync that reads every metric with its dimensions, time grains, and aggregation type, then returns a summary of what was created. The sync runs as a job rather than a single blocking request, so large metric catalogues complete reliably. Single-tenant dbt Cloud instances are supported by pointing the Semantic Layer host at your endpoint.
Build metric trees and assign ownership
Arrange imported metrics into a causal metric tree that models how your business actually works. KPI Tree scores each driver link statistically, then you assign RACI ownership, set up notifications, and create action plans. When your dbt project evolves, re-sync to pull the latest definitions. Existing trees, ownership, and action history are preserved.
Everything your semantic layer defines, with context it was never designed to carry
KPI Tree starts with the metric catalogue you have already built in dbt Cloud and extends it into territory the semantic layer does not cover. Your semantic layer tells AI how metrics are calculated. KPI Tree adds the layer above: how they drive each other, who owns them, and what is being done about it.
Your full metric catalogue, imported exactly as defined
Every metric name, label, description, dimension, time dimension, and queryable granularity imports through the dbt Cloud Semantic Layer API, with no dbt CLI to install. KPI Tree even reads the aggregation type, sum, average, first, or last, straight from each dbt definition, so time rollups are correct with no manual setup. No re-mapping, no translation layer, no drift between what dbt defines and what KPI Tree shows.
One query per metric, all analytics off-warehouse
Each metric syncs with a single query on a schedule you set. Every rollup, comparison period, correlation, and outlier test runs in KPI Tree's own compute engine, so your dbt Cloud Semantic Layer and warehouse bills stay flat as you add metrics. For very large or frequently refreshed catalogues, an optional warehouse-direct path issues those queries against your own infrastructure while definitions still come from the semantic layer.
Automatic dimension breakdowns
Enable "Create Dimension Metrics" and KPI Tree reads each metric's dimensions, queries their distinct values, and generates a child metric per value. "Revenue" becomes "Revenue (Region: EMEA)", "Revenue (Region: APAC)", and so on. High-cardinality dimensions are detected and skipped automatically to keep trees navigable.
See which metrics drive which, with a confidence level on every link.
Your semantic layer tells you what each metric is. KPI Tree shows how they relate. Arrange imported metrics into a causal metric tree that models how pipeline generation drives revenue, how activation drives retention, or however your business actually works. Every driver link is scored by proprietary ML models and statistical tests, including Pearson correlation, lagged cross-correlation, partial correlation, and Granger causality with a Benjamini-Hochberg correction, so you get statistical driver signals with confidence levels rather than lines someone drew by hand. When a metric moves, stakeholders trace the cause through the tree instead of filing a request with your data team. RACI ownership assigns accountability to named people, not teams.
- Full metric catalogue imported straight from your semantic layer
- Every driver link carries a statistical confidence level, refreshed nightly
- Drag-and-drop the tree to match how your business actually works
- RACI ownership, notifications, and action tracking per metric
One query per metric, so your dbt Cloud and warehouse bills stay flat.
KPI Tree fetches each metric with a single query on a schedule you set, then does the heavy lifting elsewhere. Time rollups, period comparisons, correlation scoring, and outlier detection all execute in KPI Tree's own compute, which means the cost of adding a metric stays constant instead of compounding across your dbt Cloud Semantic Layer and your warehouse. If your catalogue is very large or refreshes often, link a warehouse connection and route those sync queries through your own infrastructure instead. Either way, definitions still come from the semantic layer on every sync, so governance is unchanged and only the data path moves.
- One query per metric; comparisons, rollups, and correlations run off-warehouse
- Metric definitions always sourced from the semantic layer
- Optional warehouse-direct queries against Snowflake, BigQuery, Databricks, Redshift, or PostgreSQL
- Governance unchanged, only the data path changes
The aggregation and dimensions you already defined, read straight from dbt.
KPI Tree reads the aggregation type from each dbt metric definition, whether that is a sum, an average, a minimum, a maximum, or a point-in-time First Value, so weekly, monthly, and quarterly rollups are correct without any manual configuration. It also reads each metric's dimensions and, with dimension metrics enabled, expands them into a child metric per distinct value, so a revenue metric with a Region dimension gains a node for each region. Each child appears as its own node on the tree, receives its own RACI owners, and tracks independently. Dimensions with too many distinct values are skipped so trees stay navigable.
- Aggregation type (sum, average, first, last) auto-detected from the dbt model
- First Value aggregation handles point-in-time metrics correctly
- Auto-generates child metrics for each dimension value, labelled by value
- High-cardinality dimensions detected and skipped automatically
Governed definitions in dbt, the accountability layer in KPI Tree.
Your dbt Cloud Semantic Layer stays the single source of truth for how every metric is calculated, and KPI Tree never re-implements that logic. It adds the layer dbt was never designed to carry. When a metric breaks its expected range, KPI Tree pushes the anomaly to the Accountable owner over Slack, Email, WhatsApp, or SMS, escalating up the org chart if it goes unactioned. Every task and workflow is tracked against the specific metric it targets, and impact is verified after the fact so you can see whether the action actually moved the number. KPI Tree's MCP server exposes that enriched context, the RACI owner, the significance-tested drivers, and the verified impact, to any AI assistant, not just the raw definitions your semantic layer already publishes.
- dbt Cloud remains the sole source of truth for metric calculations
- Anomalies pushed to the Accountable owner via Slack, Email, WhatsApp, or SMS
- Actions tracked against their target metric, with impact verified after the fact
- MCP server exposes RACI, significance-tested drivers, and verified impact to AI assistants
What makes this different from other tools that read the semantic layer
Plenty of products consume the dbt Cloud Semantic Layer and portable, standardised definitions. Shared definitions are the input to KPI Tree's accountability layer, not a substitute for it. The difference is the three things KPI Tree builds on top of your governed metrics.
Every source resolves onto one causal tree.
Statistical driver signals, not a flat catalogue
Most semantic layer consumers render your metrics as charts and tables. KPI Tree arranges them into a causal metric tree where every driver link carries a confidence level from proprietary ML models and statistical tests. That answers a different question: not what happened, but what is moving it and how sure we are.
Ownership, routing, and proof, not just definitions
Shared metric definitions are the starting point. KPI Tree adds the owner who is accountable as a first-class RACI primitive, the anomaly routed to their channel, and the proof the metric actually moved. Diagnosis is now table stakes everywhere. Closing that loop is not.
We read your definitions, we never ask you to redefine them
dbt tells the warehouse what your metrics are. KPI Tree reads them as an upstream source, so there is no competing semantic layer to reconcile, and it pulls metrics from several warehouses onto one tree at the same time. The industry move toward portable, standardised definitions makes that easier, not harder.
Related integrations. More sources that work with KPI Tree.
Common questions
Which dbt Cloud plans support this integration?
What permissions does the service token need?
Do I have to redefine my metrics in KPI Tree?
How does KPI Tree know whether to sum or take the last value across a week or month?
Can KPI Tree query our warehouse directly instead of going through dbt Cloud?
How does the sync work, and how often can I run it?
What does "driver" mean statistically?
What are dimension metrics?
Does KPI Tree modify my dbt project?
Does it work with single-tenant dbt Cloud instances?
Should I use this or the dbt Core integration?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with dbt Cloud.
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.
You built the semantic layer. Now build on it.
Connect your dbt Cloud Semantic Layer to KPI Tree. Keep your governed definitions exactly where they are and add the causal structure, ownership, and accountability your organisation needs to act on what the metrics are telling you.
