Snowflake Semantic Views Integration
Your Semantic Views define the metrics. KPI Tree shows how they drive each other, who owns them, and what to do when they move.
You built Semantic Views on Snowflake so that everyone, and every agent, calculates each metric the same way. That solves definition consistency. It was never designed to answer the next set of questions: which metrics cause which, who is accountable when one moves, and whether the last action actually worked. KPI Tree reads a Semantic View on your existing Snowflake connection, turns every measure into a tracked metric that Snowflake itself calculates, and adds the layer above the definition: a causal metric tree, RACI ownership, and a closed action loop. Your Semantic Views stay the single source of truth for how metrics are computed, and the numbers always match Snowflake.
Sync a Semantic View in minutes
The Semantic View sync runs on top of an existing Snowflake connection. Point KPI Tree at a view, pick the measures you want, and each one becomes a metric with Snowflake performing the calculation. No definitions are re-entered and no logic is re-implemented.
Connect Snowflake once
If you have not already connected Snowflake, the setup wizard generates copy-paste SQL that creates a dedicated user with RSA key-pair authentication, a least-privilege read-only role, and an optional network policy scoped to KPI Tree's static IP. The connection is validated with a live SELECT 1 before it is saved. Your Semantic Views ride on this same connection, so there is nothing extra to authorise.
Pick a Semantic View and sync
KPI Tree finds the Semantic Views in your connection's default database automatically, so you select one from a list rather than typing anything by hand. Choose the measures you want to track and start the sync. It runs as a background workflow you can poll, not a single blocking request, so even large views complete reliably. Each measure becomes a metric, and KPI Tree builds native SEMANTIC_VIEW() queries so Snowflake computes every value.
Build the tree and assign ownership
Arrange the 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, route anomalies to the person accountable, and track the actions taken against each number. Re-sync whenever the Semantic View changes; existing trees, ownership, and action history are preserved.
Everything your Semantic View defines, with context it was never designed to carry
KPI Tree consumes your Snowflake Semantic View as an upstream source and never re-implements a calculation. Your semantic layer tells AI how each metric is calculated. KPI Tree adds the layer above: how metrics drive each other, who owns them, and what is being done about it.
Measures imported exactly as defined
Pick a Semantic View and each measure becomes a tracked metric. KPI Tree builds native SEMANTIC_VIEW() SQL, so Snowflake performs the calculation and the numbers match the source exactly. The aggregation type is read straight from the definition: flows are summed, minimums and maximums carry through, and averages, ratios, and other point-in-time measures take the latest value, so weekly, monthly, and quarterly rollups are correct with no manual setup. Semantic Views are listed for you to pick from, so you select rather than type.
One query per metric, analytics off-warehouse
Each measure syncs with a single query on a schedule you set. Comparison periods, week and quarter rollups, correlations, regressions, and outlier detection all run in KPI Tree's own compute engine rather than back on Snowflake, so no extra queries hit your warehouse as your team explores. Your Snowflake bill stays flat as you add metrics, and per-metric results are cached again in the browser so filtering, comparing, and drilling never re-hit the source.
Automatic dimension breakdowns
Enable "Create dimension metrics" and KPI Tree reads a measure's dimensions, queries their distinct values, and generates a child metric per value, for example Revenue by Region. Each child appears as its own node on the tree, receives its own RACI owners, and tracks independently. Breakdowns are capped by default, so your tree stays bounded even when a dimension holds hundreds of distinct values.
Sync a Semantic View and every measure becomes a tracked metric.
Your Snowflake Semantic Views describe your data in governed business terms. KPI Tree reads them as an upstream source: choose a view, pick the measures, and each one becomes a metric that Snowflake calculates through native SEMANTIC_VIEW() queries, so definitions never drift from the warehouse. Views are listed for you automatically, so setup is a selection rather than a configuration exercise. Turn on "Create dimension metrics" to expand a measure into per-value breakdowns such as Revenue by Region, capped at five per parent so trees stay navigable. The sync runs as a background workflow and reports what it created when it finishes, however large the catalogue.
- Semantic Views discovered automatically, ready to pick from a list
- Each measure becomes a metric that Snowflake calculates, so numbers match the source
- Dimension toggle expands a measure into per-value breakdowns, capped per parent
- Sync runs as a background workflow, so large views complete without timing out
Map cause and effect across metrics your Semantic View only defines.
A Semantic View tells you what each measure is. KPI Tree shows how they relate. Arrange the imported measures into a causal metric tree that models how each operational input drives the metrics above it, up to revenue. Every driver edge is scored by proprietary ML models and statistical tests, using Pearson and lagged cross-correlation, partial correlation, and Granger causality with a Benjamini-Hochberg correction, so you see the relationships that survive significance testing rather than every coincidence. When a number moves, root-cause detection traces the anomaly down the tree and the AI analysis queries Snowflake directly to explain it. Every metric carries RACI ownership tied to a named person, their team, and their manager.
- Driver edges scored by proprietary ML models and statistical tests with confidence levels
- Confidence levels refreshed nightly, not lines drawn by hand
- Root-cause detection traces anomalies down the tree automatically
- RACI ownership assigns accountability to real people, not just teams
One query per metric, so your Snowflake bill stays flat.
KPI Tree runs one native SEMANTIC_VIEW() query per metric to aggregate the measure down to a daily series on the schedule you set, returned as Apache Arrow and cached. Comparison periods, rollups, correlations, regressions, outlier detection, and causal analysis all run in KPI Tree's compute engine, and per-metric results are cached again in the browser, so filtering, comparing, and drilling never re-hit Snowflake. Business-model budgets and forecasts flow through the same pipeline as actuals, so a target and its metric are computed the same way. Adding metrics adds no exploration load to your warehouse.
- No additional Snowflake queries for comparisons, rollups, or drill-downs
- Results returned as Apache Arrow and cached with a configurable schedule
- Budgets and forecasts run through the same off-warehouse pipeline as actuals
- Point the connection at a dedicated XS warehouse to isolate the sync traffic on your bill
Governed definitions in Snowflake, the accountability layer in KPI Tree.
Your Semantic Views and Snowflake Horizon stay the single source of truth for how each metric is calculated and where it came from, and KPI Tree never re-implements that logic. It adds the layer they were 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 against the statistical baseline rather than self-reported, 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 definitions your Semantic View already publishes.
- Snowflake 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 against the baseline
- MCP server exposes RACI, significance-tested drivers, and verified impact to AI assistants
The layer above your Semantic View
Snowflake Semantic Views and Horizon are the substrate KPI Tree reads from, not something it competes with. They govern what a metric means and how it is calculated. KPI Tree adds the four primitives above the definition: which metric drives which, who owns each one, what action is in flight, and whether it worked.
Every source resolves onto one causal tree.
A causal layer, not just governed definitions
Your Semantic Views and Horizon Context tell AI how each metric is calculated and where it came from. KPI Tree adds how metrics drive each other, as a graph where every edge carries a confidence level from nightly statistical tests, not graph-walking or a hand-written narrative. Same governed data, a question your semantic layer does not answer.
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 with org-chart escalation, and the proof the metric actually moved. Diagnosis is table stakes everywhere now. Closing that loop is not.
We read your definitions, we never ask you to redefine them
Snowflake 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. Portable, standardised metric definitions make that easier, not harder, because none of them standardise drivers, ownership, or verified impact.
Related integrations. More sources that work with KPI Tree.
Common questions
What do I need before I can sync Semantic Views?
How does the sync turn a Semantic View into metrics?
Does the sync scan every database on the connection?
How does KPI Tree know whether to sum or take the last value across a week or month?
What are dimension metrics?
How does this affect my Snowflake costs?
Can I use Cortex Analyst alongside Semantic Views?
What happens when the Semantic View changes?
How does KPI Tree relate to Snowflake Horizon?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with Snowflake Semantic Views.
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.
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
You built the Semantic Views. Now build on them.
Sync your Snowflake Semantic Views into KPI Tree, keep every definition governed exactly where it is, and add the causal tree, ownership, and verified impact your organisation needs to act on what the metrics are telling you.
