What is customer success analytics, and how do you build it in Metabase?
Customer success analytics turns health scores, renewals, and CS activity into shared metrics about whether customers stay, grow, and get value — and about how much revenue depends on the answer. The CS software industry sells visibility into accounts; the durable advantage is retention you can explain: gross and net revenue retention by cohort, health scores validated against what actually happened at renewal, and churn signals drawn from product usage rather than from a CSM's gut feel.
TL;DR — Land accounts, dated health snapshots, activity, and subscriptions in a warehouse, then join them to product usage and billing. Re-derive health score components instead of trusting the vendor composite, freeze renewal forecasts at period start so accuracy is measurable, and keep gross and net revenue retention as separate models — gross can never exceed 100%, net can.
What does customer success analytics measure?
- How much of last year's revenue did we keep, and how much did we grow?
- Which accounts are at risk, and how much ARR sits behind that risk?
- Does the health score actually predict renewal, or just describe it?
- Which product behaviors show up before a customer churns?
- How long does it take a new customer to reach first value?
- How accurate was the renewal forecast we committed to at quarter start?
- Are CSMs covering the accounts that carry the most revenue risk?
Which tools feed customer success analytics?
| Tool | Best for | Getting data into Metabase |
|---|---|---|
| Gainsight | Account health distribution and risk tiers; Renewal forecast by quarter with at-risk ARR | Gainsight CS APIs, pipeline, or Gainsight CS MCP server for exploration |
| Vitally | Health score distribution across the account base; Score movers: accounts improving and declining | Vitally REST API, pipeline, or a scripted export for exploration |
| Planhat | Health score distribution and risk tiers; Licenses up for renewal by quarter | Planhat API, pipeline, or Planhat MCP server for exploration |
| Salesforce | Renewal opportunities and contract terms | Connector, API pipeline, or CRM MCP |
| Chargebee | Invoiced revenue for retention that reconciles | Connector or scheduled API pulls |
| Zendesk | Support history as a health score input | Connector or API pipeline |
What shared data models should you build?
Build clean models on top of the raw synced tables so each dashboard uses the same definitions.
cs_accounts— one row per account, with owner, segment, ARR, contract dates, and lifecycle stage: the spine everything else joins toaccount_health_scores— one row per account per measure per snapshot date, with the component scores kept alongside the compositecs_activities— one row per CTA, task, conversation, or note, for coverage and engagement viewssubscriptionsorcs_licenses— one row per contract line, with value, term dates, auto-renew flag, and renewal statusrenewal_opportunities— one row per renewal event, with the outcome and the reason attachedrenewal_forecast_snapshots— the forecast frozen at period start, which is the only thing forecast accuracy can honestly be measured againstproduct_usage_daily— active users and key events per account per day: the reality check on every health score
Which customer success metrics matter most?
- Customer health score — a composite you can re-derive, kept beside the vendor's version rather than replaced by it.
- Gross revenue retention — retained revenue from an existing cohort with expansion excluded; it can never exceed 100%.
- Net revenue retention — the same cohort including expansion; this one can and often should exceed 100%.
- Churn rate — accounts or revenue lost over the opening base, always labeled as logo churn or revenue churn.
- Renewal forecast accuracy — forecast against outcome, measured from a snapshot frozen at period start.
- Time to value — days from contract start to the first realized outcome, with that outcome defined before anything is charted.
How do you connect tools to Metabase?
- Warehouse pipeline first — a managed connector or scheduled API pulls, landing accounts, health snapshots, activity, and subscriptions in a database Metabase reads. Check sync mode: several connectors in this category are full-refresh only.
- MCP + CLI — vendor MCP servers for scoped live questions and
mb upload csvfor quick analysis. Gainsight and Planhat publish their own servers; Vitally does not, so a scripted REST export takes its place. - Join the neighbours — billing for revenue that reconciles, support for ticket history, and product usage for the behavior signals that make a health score testable.
Which dashboards should you build first?
- Customer health— risk tiers, ARR by tier, score movement, and coverage gaps.
- Renewal forecast — exposure by quarter, at-risk ARR, and forecast against outcome.
- Churn and retention — GRR and NRR by cohort, churn reasons, and leading signals.
- Subscription analytics — ARR movement, expansion, downgrades, and contract terms.
Common mistakes
Treating the vendor health score as a metric definition.→ It is an opaque composite that gets reweighted without notice, and every trend built on it inherits that silence. Re-derive the components in the warehouse and keep the vendor score as a labeled column beside your own.
Reporting retention from the CS platform's ARR.→ A CS platform holds a projection of CRM, billing, and product data. Reconcile against billing, and treat a gap as a pipeline bug rather than a rounding difference.
Publishing GRR above 100%.→ If it exceeds 100%, expansion has leaked into the numerator and you are looking at net revenue retention. Keep the two as separate models and label every card with which one it uses.
Measuring renewal forecast accuracy against a forecast that keeps moving.→ Snapshot the forecast at period start into its own table. A forecast that updates as outcomes land will always look accurate and will never be useful.
Charting health trends from current-state fields.→ Scores, phases, and renewal dates describe today. Without dated snapshots appended on a schedule, a trend line is just the same number repeated.
Validating health scores against nothing.→ A score that has never been tested against actual renewal outcomes is an opinion with a number attached. Backtest it — that comparison is the reason to build this in BI rather than read it off a platform dashboard.
Related
Integrations
Analytics
Dashboards
Terms
FAQ
What is customer success analytics?
Customer success analytics is the practice of turning the account record — health scores, renewals, CS activity, and subscription value — into governed, shareable business metrics. Where a CS platform answers "which account should my CSM call today?", customer success analytics answers "does health actually predict renewal, what is gross revenue retention by cohort, and which product behaviors precede churn?" In Metabase you build it on CS data from Gainsight, Vitally, or Planhat landed in a SQL warehouse and joined to product usage and billing.
How is customer success analytics different from support analytics?
They use different vocabularies because they answer different questions. Support analytics is ticket-shaped: volume, first response time, resolution time, backlog, CSAT per interaction — the health of a queue. Customer success analytics is account-shaped and revenue-weighted: health score, net revenue retention, renewal exposure, and churn risk — the health of a relationship and the dollars attached to it. Support data is one input into a health score; it is not the same practice. A team with a clean support dashboard and no retention model still cannot answer whether an account will renew.
Why build CS dashboards in a BI tool instead of the CS platform?
Three reasons. Joins: the interesting questions need health data next to product usage, support history, and invoiced revenue — tables that live in your warehouse, not in the CS tool. Governance: definitions like gross versus net revenue retention, or what counts as a churn event, become certified models everyone shares instead of per-view settings. Reach: finance, product, and leadership read the same dashboards without extra CS platform seats. The platform keeps doing what it is built for — playbooks, alerts, and the CSM's daily queue.
Which metrics should a customer success dashboard track?
Start with the retention core: gross revenue retention and net revenue retention as separate, clearly labeled metrics, plus churn rate stated as logo or revenue churn. Add customer health score once you can re-derive its components, renewal forecast accuracy once forecasts are snapshotted at period start, and time to value once the onboarding outcome event is defined.
What data do I need to get started?
Two tables: accounts with owner, segment, and ARR, and a dated health snapshot per account. That alone powers the customer health dashboard. Subscription or license rows with contract dates unlock the renewal forecast; billing data unlocks retention measured against invoiced revenue; product usage rollups turn the health score from an assertion into something testable.
Can I trust the health score my CS platform ships with?
As a signal, yes. As a metric definition, no. Vendor health scores are opaque composites, and they get reweighted or redefined without the analytics team hearing about it — which silently breaks every trend built on them. Re-derive the components in the warehouse, keep the vendor score beside your own as a labeled column, and validate both against what actually happened at renewal. That validation is the whole reason to build this in BI rather than read it off a platform dashboard.
Can I build CS dashboards without a data warehouse?
For a first pass, yes: pull a scoped account and scorecard slice through a vendor MCP server — Gainsight's CS server or Planhat's — and load it with the Metabase CLI (
mb upload csv). Vitally publishes no MCP server, so a scripted REST export plays the same role there. That works for spot-checks. Durable reporting wants the data in a warehouse: history, scheduled refreshes, and definitions people can trust. Every integration guide documents both routes.