Snowflake Integration
The causal, owned, and verified layer above your Snowflake data.
You built your data foundation on Snowflake. KPI Tree sits on top of it. Your semantic layer tells AI how each metric is calculated. KPI Tree adds the layer above: how metrics drive each other with confidence levels, who owns each one as a RACI primitive, and whether the last action actually moved the number. Write metrics in SQL, sync them from your Snowflake Semantic Views so Snowflake does the calculation, or draft SQL from plain English with Cortex Analyst. One query per metric, every downstream calculation off-warehouse.
Connected in under an hour
A guided setup wizard generates the exact SQL you need. No agents to install, no bulk data extraction, no firewall changes unless you choose to add them. The connection is validated with a live SELECT 1 before it is ever saved.
Run the generated setup SQL
The wizard generates copy-paste SQL that creates a dedicated user with RSA key-pair authentication, a least-privilege role with read-only grants, and an optional network policy scoped to KPI Tree's static IP. Review the SQL, paste it into a Snowflake worksheet, and run it. Most teams also create a dedicated XS warehouse for the connection at this step.
Connect and validate
Provide your account identifier, warehouse, database, and RSA private key. KPI Tree tests the connection in real time before saving it. Snowflake supports two simultaneous public keys, so you can rotate credentials with zero downtime. The private key is held by a dedicated key handler and encrypted at rest, never logged.
Start building
Write SQL directly against your tables and views, sync measures from an existing Semantic View, or draft SQL from plain English with Cortex Analyst. From there, map how metrics drive each other, assign RACI ownership, and route anomalies to the person accountable for the number.
Reads the Snowflake platform natively
KPI Tree consumes Snowflake's own primitives rather than reimplementing them: Cortex Analyst for natural-language SQL, native Semantic Views for governed definitions, RSA key-pair auth, and network policies. Your governance model stays exactly as your team configured it.
Semantic Views and Cortex Analyst
Point KPI Tree at a Semantic View and each measure becomes a tracked metric, with Snowflake performing the calculation so the numbers always match the source. KPI Tree auto-discovers the Semantic Views in the connection's default database. In Cortex mode, describe a metric in plain English and Cortex Analyst drafts the SQL for you to review before it runs.
One query per metric, off-warehouse analytics
Each metric carries a single query that aggregates to a daily series on a configurable schedule. Comparison periods, week and quarter rollups, correlations, regressions, and outlier detection all run in KPI Tree's own compute engine, so no additional queries hit Snowflake as your team explores. Your warehouse bill stays flat as you add metrics.
Snowflake-native security
RSA key-pair authentication with no passwords stored. Network policies scoped to a single static IP. A dedicated role with read-only grants. Row-level security, dynamic data masking, and RBAC stay enforced on every query, because KPI Tree reads through your governance rather than around it.
Sync your Semantic Views, or draft SQL with Cortex Analyst.
Your Snowflake Semantic Views describe your data in governed business terms. KPI Tree reads them as an upstream source: pick a view, and every measure becomes a tracked metric that Snowflake calculates, so definitions never drift from the warehouse. A "Create dimension metrics" toggle expands a measure into per-value breakdowns, for example Revenue by Region, capped per parent to avoid metric sprawl. When you would rather start from a question, the editor has a Cortex mode: describe the metric in plain English, and Cortex Analyst drafts the SQL for you to review before it runs. Whichever route you take, the metric gets the same ownership, causal context, and statistical monitoring.
- Auto-discovers the Semantic Views in the connection's default database
- Each measure becomes a metric that Snowflake calculates, so numbers match the source
- Dimension-metric toggle expands a measure into per-value breakdowns, capped per parent
- Cortex mode drafts SQL from plain English for review before execution
Map cause and effect across your entire business.
Snowflake stores the data. KPI Tree maps how it connects. Build a metric tree that shows 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 correlation, lagged cross-correlation, partial correlation, and Granger causality with 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 the warehouse directly to explain it. Assign RACI ownership to each metric so every driver has a named person accountable for it.
- Driver edges scored by proprietary ML models and statistical tests with confidence levels
- RACI ownership assigns accountability to real people, tied to team and manager
- Root-cause detection traces anomalies down the tree automatically
- AI analysis queries the warehouse directly to explain why a number moved
One query per metric. Nothing extra hits your warehouse.
KPI Tree runs one query per metric to aggregate raw Snowflake data down to a daily series, returned as Apache Arrow and cached with a configurable TTL. 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 the warehouse. Every sync query is deep-linked back to Snowflake's query history so you can inspect exactly what ran.
- No additional warehouse queries for comparisons, rollups, or drill-downs
- A dedicated XS warehouse isolates the read traffic on its own line in your bill
- Auto-suspend spins the warehouse down between sync cycles
- Deep links to Snowflake query history for every sync query
Security your team has already approved.
The setup wizard generates review-ready SQL that follows Snowflake security best practice. RSA key-pair authentication means no passwords are stored or transmitted, and two simultaneous public keys let you rotate keys without downtime. A network policy restricts access to a single static IP. A dedicated role receives only USAGE and SELECT. Your Snowflake security posture stays exactly as configured, and KPI Tree never asks you to loosen it.
- RSA key-pair authentication with zero-downtime dual-key rotation
- Network policy scoped to a single static IP
- Least-privilege role with USAGE and read-only SELECT, including future grants
- Credentials encrypted at rest and never logged
Warehouse connection
ConnectedRead-only access · credentials never leave the encrypted store
The layer above your semantic layer
Snowflake, Horizon, and your Semantic Views 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 data, a question your semantic layer does not answer.
Ownership and routed action
Every metric has full RACI ownership tied to a real person, their team, and their manager, not an "owner" text field. When a metric breaches its baseline, KPI Tree pushes the anomaly to the Accountable owner across Slack, email, WhatsApp, or SMS, with org-chart escalation if it is not picked up. The warehouse can tell you the number moved; it cannot tell anyone whose job it is.
Proof the action moved the number
Actions are tracked against the metric they were meant to move, and impact is verified against the statistical baseline rather than self-reported. Every competitor claims insights to action; KPI Tree closes the loop and shows whether the last action actually shifted the metric. Business-model budgets and forecasts run through the same pipeline as actuals.
Related integrations. More sources that work with KPI Tree.
Common questions
What does the setup wizard generate?
What permissions does KPI Tree need?
How do Semantic Views and Cortex Analyst work?
How does KPI Tree relate to Snowflake Horizon and Cortex?
How does KPI Tree affect Snowflake costs?
Does KPI Tree work with dbt on Snowflake?
How does RSA key-pair authentication work?
What warehouse size is recommended?
Does KPI Tree copy data out of Snowflake?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with Snowflake.
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.
Connect Snowflake in under an hour.
A guided wizard generates the SQL. KPI Tree reads Semantic Views, Cortex Analyst, RSA key-pair auth, and network policies as a source. Then build the causal, owned, and verified layer above.
