Google Sheets Integration
Start on the spreadsheet you already have. Add the accountability it never could.
Your team already tracks the numbers in Google Sheets. Revenue by week, pipeline by stage, NPS by quarter, headcount by department. The data is there, the structure and ownership are not. KPI Tree reads your spreadsheet as a first-class source and adds the layer above it: how each metric drives the ones above it with confidence levels, who is accountable for each as a RACI primitive, the action in flight against it, and whether the last action actually moved the number. Provide a spreadsheet ID, optionally pick a sheet tab, map your date and metric columns, and KPI Tree syncs on a schedule. No engineering, no SQL, no warehouse to stand up first. When you do outgrow spreadsheets, the tree, ownership and action plans you built stay attached to each metric, and you re-point the metric at a warehouse rather than starting again.
Connected in minutes, not a data project
Authenticate with a service account or workload identity, point at a spreadsheet, and map your columns to metrics. There is no SQL to write, no pipeline to build, and no warehouse to provision first.
Authenticate with Google
Two methods are available. Provide a service account JSON key for explicit control over which identity reads your data, or use default credentials via workload identity when KPI Tree runs in a Google Cloud environment. Either way KPI Tree requests read-only access to your spreadsheets (the read-only Sheets scope). You grant access by sharing the specific spreadsheet with the service account email, so nothing outside the sheets you deliberately share is ever reachable.
Point at your spreadsheet and tab
Paste the spreadsheet ID (the long string in the Sheets URL). Optionally name a sheet tab to read a specific tab instead of the first one. KPI Tree validates the connection live before saving, confirming the sheet exists, that the service account has access, and that the named tab is present.
Map columns to metrics and assign ownership
Tell KPI Tree which column is the date and which columns are metrics. Pick the aggregation for each metric (sum, average, count, first or last value, among others). From there each metric gets a RACI owner, causal edges to the metrics it drives, and statistical monitoring. Your spreadsheet stays the source of truth. KPI Tree reads it on a schedule and runs every downstream calculation in its own engine.
Structure and accountability for the metrics you already track
Your team tracks KPIs in spreadsheets because it was the fastest path. KPI Tree makes it a durable one, adding causal drivers, RACI ownership and action plans without a warehouse or a data team, and reading the sheet in a way that never slows it down.
No engineering. Connected in minutes.
Provide a service account key or use workload identity, paste a spreadsheet ID, optionally name a tab, and map your columns. There is no SQL to write, no ETL to build, and no warehouse to provision. The person who maintains the spreadsheet can connect it themselves, without filing a ticket or waiting for a sprint.
Read as a first-class source, on its own engine
KPI Tree reads your sheet through its own compute engine and returns each metric as a single scheduled read. Comparison periods, week and quarter rollups, correlations and outlier detection all run off to the side in that engine, never back against the spreadsheet, so the sheet is only ever read, never hammered. Every metric links back to the exact spreadsheet and tab it reads from, so you can open the source in one click.
Read-only access with two authentication paths
Use a service account JSON key for explicit control, or workload identity for keyless access inside Google Cloud. Both grant read-only access under the Sheets read-only scope, and keys are encrypted at rest. Only the spreadsheets you share with the service account are reachable, and you revoke access at any time by removing the share.
You do not need a warehouse to have metric accountability.
Most accountability and BI tools assume you already have a warehouse, a data team and a quarter to spare. Your team tracks its KPIs in a sheet because it works. KPI Tree meets you there. Paste a spreadsheet ID, optionally pick a tab, and map your columns. A metric tree with causal drivers, RACI ownership and action plans is live in minutes. Weekly revenue, pipeline coverage, activation rate, NPS: if it is in a sheet, it works. The warehouse can come later. The accountability starts now.
- Connect with a spreadsheet ID and an optional sheet tab name
- Weekly revenue, activation rate, NPS, pipeline coverage: if it is in a sheet, it works
- Causal drivers, RACI ownership and action plans from the first sync
- Re-point a metric at a warehouse later and keep the tree you built on it
Revenue · Liverpool St
15%£43,452
Map what drives what, and who owns each number.
A spreadsheet holds the values. It cannot tell you how they connect or who is on the hook for them. KPI Tree builds a tree across your sheet metrics that maps how each one drives the metrics above it, from operational inputs through to revenue. It surfaces the relationships statistically using proprietary ML models and tests (Pearson and lagged cross-correlation, partial correlation and Granger causality, with Benjamini-Hochberg correction) so you see drivers with a confidence level rather than a hunch. Every metric carries a full RACI owner tied to their team, department and manager, and when a number moves out of pattern root cause traces it through the tree automatically.
- A causal metric tree built from the columns in your spreadsheet
- Statistical driver signals with confidence levels, not manual arrows
- RACI ownership tied to real people, teams and managers
- Automatic root cause tracing when a metric moves out of pattern
Your spreadsheet stays the source of truth.
KPI Tree reads your sheet on a schedule you choose. Update it however you already do, by hand, through Google Forms, via Zapier or with Apps Script, and KPI Tree picks up the changes on the next sync. The header row is detected by default, and you can turn it off for sheets that start with data on row one, or force every column to text when a column mixes numbers and labels. No exports, no copy-paste, no stale duplicate. The spreadsheet your team already keeps becomes the foundation of the accountability layer, and each metric deep-links straight back to the tab it came from.
- Reads on a schedule you choose: hourly, daily or weekly
- Update the sheet any way you like and the next sync picks it up
- Header detection on by default, with options for headerless or mixed-type columns
- Every metric links back to the exact spreadsheet and tab it reads
Graduate to a warehouse without rebuilding your tree.
A sheet is the right starting point for many teams, and some outgrow it. When that happens, connect a warehouse such as BigQuery, Snowflake or PostgreSQL and re-point the metric at the new source. The tree structure, RACI ownership, causal relationships and action plans are attached to the metric, not to the connection, so they stay in place. What changes is the data path underneath: you swap the source and rewrite the metric query for the warehouse, and everything built on top of the metric carries on. You can also run a mix, keeping some metrics on Sheets while others read from the warehouse, all on one tree.
- Re-point a metric from Sheets to a warehouse and keep the tree, ownership and actions
- Swap the source and rewrite the query; the structure around the metric stays
- BigQuery, Snowflake, PostgreSQL and every supported source available as a target
- Mix sources on one tree: some metrics on Sheets, others on the warehouse
How KPI Tree uses Google Sheets differently
Most tools either ignore spreadsheets or treat them as a temporary workaround to be migrated away. KPI Tree treats Google Sheets as a legitimate source and adds the same layer above it that it adds above a warehouse: causal drivers, ownership, routed action and verified impact.
Every source resolves onto one causal tree.
Spreadsheets as a first-class source
Other accountability tools demand a warehouse before you can begin. KPI Tree reads a sheet with the same seriousness as a warehouse: scheduled reads, statistical monitoring, RACI ownership, causal trees and action plans. Your spreadsheet is not a workaround, it is a real starting point.
The layer above your data, wherever it lives
A spreadsheet, and a warehouse, hold the numbers. KPI Tree adds the layer above them: which metric drives which with a confidence level, who owns each one as a RACI primitive, the channel they get pinged in when it moves, and whether the last action actually shifted it. That is the part no dashboard and no spreadsheet closes.
A graduation path that keeps your structure
Start on Sheets, move to a warehouse when you are ready. Because the tree, ownership and actions attach to the metric rather than the connection, you re-point the source and keep the structure instead of rebuilding it. Most tools force you to start over when the data moves. KPI Tree does not.
Related integrations. More sources that work with KPI Tree.
Common questions
What connection details does KPI Tree need?
How does KPI Tree authenticate with Google Sheets?
Do I need a data warehouse to use KPI Tree?
Does connecting Sheets slow down or add load to my spreadsheet?
Can I write SQL against my sheet, or only map columns?
What happens when I update my spreadsheet?
Can I move to a warehouse later without rebuilding my work?
Can I mix Google Sheets with other data sources on one tree?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with Google Sheets.
Your spreadsheet data is ready. Give it the structure it deserves.
Connect Google Sheets to KPI Tree in minutes. No warehouse, no engineering, no data project. Start with the sheet your team already maintains and give every metric a driver, an owner and an action plan, then swap in a warehouse when you are ready.
