dbt Cloud IntegrationYour 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 foundation solves metric consistency. But it was never designed to answer the next set of questions: which metrics cause which, who is accountable when something moves, and what is being done about it. KPI Tree imports your entire metric catalogue from the semantic layer and adds causal structure, ownership, and an action loop on top. Your dbt project stays untouched. Definitions stay governed. You just get 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 from your semantic layer automatically.
Create a read-only service token
In dbt Cloud, generate a service token with "Semantic Layer Only" and "Metadata Only" permissions. 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 imports every metric with its dimensions and time grains, then returns a summary of what was created. Single-tenant dbt Cloud instances are fully supported.
Build metric trees and assign ownership
Arrange imported metrics into cause-and-effect trees that model how your business actually works. 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: causal relationships, human ownership, and a closed loop from metric movement to verified impact.
Your full metric catalogue, imported exactly as defined
Every metric name, label, description, dimension, time dimension, and queryable granularity imports directly from your semantic layer. No re-mapping, no translation layer, no drift between what dbt defines and what KPI Tree shows.
Optional warehouse-direct queries for large catalogues
For teams with large metric catalogues or frequent refreshes, KPI Tree can query your warehouse directly while still sourcing all metric definitions from the semantic layer. Governance stays unchanged, only the data path changes.
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.
See which metrics drive which across your entire business.
Your semantic layer tells you what each metric is. KPI Tree shows how they relate. Arrange metrics into causal parent-child trees that model how pipeline generation drives revenue, how activation drives retention, or however your business actually works. 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 real people, not teams. Your governed definitions gain the causal structure and human accountability they were missing.
- Full metric catalogue imported directly from your semantic layer
- Arrange metrics into causal trees with drag-and-drop
- RACI ownership, notifications, and action tracking per metric
- Re-sync preserves existing trees, ownership, and action history
Run analytics at your own scale, on your own warehouse.
For teams with large metric catalogues, KPI Tree can query your warehouse directly while keeping all metric definitions sourced from the semantic layer. Link a warehouse connection (Snowflake, BigQuery, Databricks, Redshift, or PostgreSQL) and queries go straight to your infrastructure. Governance is unchanged. You just choose where the data path runs.
- Warehouse-direct queries for large or frequently refreshed catalogues
- Metric definitions always sourced from the semantic layer
- Supports Snowflake, BigQuery, Databricks, Redshift, and PostgreSQL
- Governance unchanged, only the data path changes
Break down any metric by the dimensions you have already defined.
Your dbt project already defines the dimensions that matter for each metric. KPI Tree reads them, queries the distinct values, and generates a child metric per value. Each child appears as its own node on the metric tree, receives its own RACI owners, and tracks independently. High-cardinality dimensions are detected and skipped to keep trees navigable.
- Reads dimensions directly from your semantic layer definitions
- Auto-generates child metrics for each dimension value
- High-cardinality dimensions detected and skipped
- Each dimension metric gets its own ownership and tracking
Governed definitions in dbt, operational context in KPI Tree.
Your dbt Cloud Semantic Layer is the source of truth for how metrics are calculated. KPI Tree never modifies that. It adds the operational layer dbt was never designed to carry. Push notifications via Slack, Email, WhatsApp, or SMS alert owners when metrics move. Actions are tracked against the specific metric they target. Impact is verified after the fact. The result is a closed loop: governed metric definitions, causal structure, human accountability, and a path from insight to verified impact.
- dbt Cloud remains the sole source of truth for metric calculations
- Notifications via Slack, Email, WhatsApp, and SMS
- Actions tracked against the metric they target
- MCP server exposes enriched dbt metrics to AI assistants
What makes this different from other tools that read the semantic layer
Several products consume the dbt Cloud Semantic Layer. The difference is what they build on top of your governed definitions.
Causal structure, not flat catalogues
Most semantic layer consumers display your metrics in charts and tables. KPI Tree arranges them into causal trees that model how metrics drive each other. That answers a different question: not "what happened" but "what caused it."
Analytics that scale independently of dbt Cloud
KPI Tree can query your warehouse directly while keeping definitions sourced from the semantic layer. All statistical analysis, correlations, and anomaly detection run in KPI Tree's own engine, so your dbt Cloud infrastructure is not the bottleneck as your catalogue grows.
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
- Team or Enterprise plans. The Semantic Layer API is not available on Developer plans. If you run dbt Core without dbt Cloud, use the dbt Core integration instead.
- "Semantic Layer Only" and "Metadata Only". These are read-only. KPI Tree never writes to your dbt project.
- Yes. Link a warehouse connection and KPI Tree queries the warehouse directly. Metric definitions still come from the semantic layer on every sync, so governance is unchanged. This is useful for large catalogues or teams that want analytics to run on their own infrastructure.
- Trigger a manual sync at any time from the connection settings page. Each sync compares against your existing catalogue and reports what was created, updated, or deleted. Existing tree structures and ownership are preserved.
- When enabled, KPI Tree reads each metric's dimensions from the semantic layer, 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.
- No. KPI Tree is a read-only consumer. It never writes to your project, models, or deployment configuration.
- Yes. The Semantic Layer host is configurable during setup. The default is the standard multi-tenant endpoint, but you can point it at any custom or single-tenant instance.
- If you have a dbt Cloud Team or Enterprise plan, use this integration. It connects directly to the Semantic Layer API and requires no manifest uploads. The dbt Core integration is for teams running dbt Core without dbt Cloud.
Related guides
Deep dives into the frameworks and metrics that work with dbt Cloud.
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.
