What is revenue analytics, and how do you build it in Metabase?
Revenue analytics turns the activity in your billing system — subscriptions, invoices, payments, and cancellations — into shared metrics about how your recurring revenue grows, leaks, and compounds. In Metabase, you build it by syncing your billing tool into a database, modeling a small set of clean tables (especially a monthly MRR model), and standing up dashboards anyone can read.
What does revenue analytics measure?
It measures the health and trajectory of recurring revenue — not just a single top-line number. The durable, leader-friendly questions are:
- How much recurring revenue do we have, and is it growing? (MRR, ARR, net new MRR)
- Where does revenue leak? (gross vs. net churn, voluntary vs. involuntary)
- Do we keep and expand customers? (net revenue retention)
- What is a customer worth? (LTV, ARPU, payback)
- How much revenue is at risk from failed payments? (failed-payment rate)
Avoid vanity metrics (cumulative signups, gross transaction counts). They're easy to grow and rarely change a decision.
Which tools feed revenue analytics?
The same pattern applies to every billing platform. Per-tool setup lives on each integration page:
| Tool | Best for | MCP for AI-assisted analysis |
|---|---|---|
| Stripe | Developer-first subscriptions and payments | Official remote server |
| Chargebee | Flexible subscription billing and dunning | Official site-specific server |
| Paddle | Merchant-of-record billing with tax handled | Official server (live + sandbox) |
| Recurly | Subscription management and recovery | Community server (read-only) |
| RevenueCat | Mobile in-app subscriptions across stores | Official remote server |
| Stigg | Pricing, packaging, and entitlements | Official remote + local server |
| Polar | Merchant-of-record billing for developers | Official server (live + sandbox) |
| Alguna | CPQ and usage-based billing (quote-to-cash) | Official remote server (via bridge) |
| PayPal | Payments: volume, refunds, disputes, fees | Official server (remote + local) |
| Square | Payments and POS sales across locations | Official remote server |
| Adyen | Enterprise payments: auth rate, settlement | Official local server (alpha) |
| Razorpay | Payments and settlements (UPI, cards, more) | Official server (local + remote) |
| Dodo Payments | Merchant-of-record payments and subscriptions | Official server (remote + local) |
| Zuora | Enterprise subscriptions and revenue recognition | Official server (tenant-specific setup) |
| Maxio | Subscription billing plus SaaS metrics | Official server (scoped tokens) |
| Lago | Open-source metering and usage-based billing | Official local server (agent toolkit) |
| QuickBooks | Accounting: invoiced revenue, AR, cash flow | Intuit server (local preview) + community |
What is the shared revenue data model?
Almost every subscription tool maps onto these entities. Model them as clean tables, not raw connector JSON:
| Concept | Common terms | Used for |
|---|---|---|
| Customer | Customer, account | LTV, ARPU, cohorts |
| Subscription | Subscription | MRR, active base, churn |
| Plan / price | Price, plan, item price | Normalizing to monthly |
| Invoice | Invoice | Billed amounts, AR |
| Transaction | Charge, payment, transaction | Payments, failures, recovery |
| Adjustment | Refund, credit note, dispute | Net revenue |
The single most important derived table is a monthly MRR model— one row per subscription per month with a normalized monthly amount, in one reporting currency. With it you can compute MRR movement, churn, retention, and cohorts consistently. Without it, every chart re-derives MRR differently and the numbers drift.
Which revenue metrics matter most?
Define each one once and reuse the definition everywhere:
- MRR (and ARR) — sum of active subscriptions' normalized monthly amount. ARR is MRR × 12. Exclude one-time charges and tax.
- Churn rate — churned MRR ÷ starting MRR (revenue churn), and lost customers ÷ starting customers (logo churn). Report both.
- Net revenue retention (NRR) — (starting MRR + expansion − contraction − churn) ÷ starting MRR. Over 100% means expansion beats churn.
- LTV — ARPU × average customer lifetime (1 ÷ churn rate). It's sensitive to churn, so treat it as a range.
- ARPU — MRR ÷ active customers (or accounts). Pick a grain and keep it.
- Failed-payment rate — failed charges ÷ attempted charges; the main driver of involuntary churn.
How do you connect a billing tool to Metabase?
Metabase reads from SQL databases, not SaaS APIs, so connecting any billing tool comes down to one thing: run a pipeline that syncs the tool into a database on a schedule, then point Metabase at it. Use a managed connector (Airbyte, Fivetran) where one exists, or a free, code-based sync with dlt or the tool's API — then build durable dashboards on a monthly MRR model. Per-tool setup lives on each integration page.
Once the data lands, you can also point an AI assistant at Metabase's MCP server for quick, exploratory lookups. Treat that as ad-hoc exploration, not governed reporting — it keeps no history, so it can't compute MRR movement or cohorts on its own.
Which dashboards should you build first?
- MRR / ARR — recurring revenue now, plus new/expansion/contraction/churn movement as a monthly waterfall.
- Churn & retention — gross and net retention, revenue vs. logo churn, and voluntary vs. involuntary churn.
- Subscriptions — active base, plan mix, trials, and trial-to-paid conversion.
- Failed payments / dunning — declines, recovery rate, and at-risk revenue by age.
- Cohort revenue — revenue retention and cumulative LTV by signup-month cohort.