RevenueCat × Metabase

How to build RevenueCat subscription dashboards in Metabase

RevenueCat manages your in-app subscriptions across the App Store, Google Play, and web, and unifies them into one subscriber and revenue model. Metabase is where you turn that data into shared, trustworthy dashboards — and join it with product, ads, and attribution data RevenueCat's own charts can't see. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync RevenueCat into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.

Heads up: Metabase connects to SQL databases and warehouses — it does not ship a native RevenueCat connector. For dashboards that need history and reliability, use RevenueCat's data exports or REST API v2 to sync into a database first (covered below).

How do you connect RevenueCat to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native RevenueCat connector. So connecting RevenueCat to Metabase means one thing: run a small pipeline that copies RevenueCat data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from RevenueCat data in Metabase?

  • MRR and active subscriptions — recurring revenue now and its monthly movement
  • Trials and conversion — trial starts and trial-to-paid conversion by product and store
  • Churn and retention — voluntary vs. billing (failed-renewal) churn, retention by cohort
  • LTV and ARPU — cumulative revenue and value per subscriber by cohort
  • Store and platform mix — App Store vs. Play vs. web, by country
  • Refunds — refund rate and its impact on net revenue

Which RevenueCat dashboards should you build in Metabase?

For: Founders, growth

MRR & subscriptions

Recurring revenue from mobile and web subscriptions.

  • MRR and active subscriptions right now (number + trend)
  • MRR movement: new, renewal, churn (waterfall)
  • Active subscriptions by product and store (bar)
  • Paid vs. trial subscriptions (stacked area)
For: Growth, lifecycle

Trials & conversion

How well free trials and intro offers convert to paid.

  • Trial starts and trial-to-paid conversion rate (line)
  • Conversion by product, store, and country (bar)
  • Time-to-convert distribution (histogram)
  • Intro-offer vs. full-price cohorts (table)
For: Growth, RevOps

Churn & retention

Where subscription revenue leaks and how well you keep it.

  • Subscription retention by cohort (heatmap)
  • Voluntary vs. billing (failed-renewal) churn (bar)
  • Grace-period and billing-retry recovery (line)
  • Churn by product and store (table)
For: Finance, leadership

LTV & cohorts

Does each install/signup cohort pay back?

  • Cumulative revenue (LTV) by install cohort (line)
  • ARPU and ARPPU by product (table)
  • Revenue by store, country, and platform (bar)
  • Refund rate and its revenue impact (number)

How do you build the RevenueCat → Metabase pipeline?

For dashboards that need history and reliability, land RevenueCat data in a database first, then connect Metabase to that database.

No paid tool required. A fully free stack: a small dlt or hand-written script (extract) → a free Postgres database like Neon or Supabase (load) → a scheduler such as GitHub Actions cron (host) → Metabase (visualize). For hosting and scheduling details, see our data pipeline guide.

Connector options

  • REST API v2 (free, raw) — paginate customers, subscriptions, and purchases into your own pipeline when you need custom shaping.
  • Webhooks (free, events) — stream subscription lifecycle events into a table for near-real-time dashboards.
  • Scheduled data exports (first-party) — RevenueCat drops transaction/event exports to S3, GCS, Azure, or directly into BigQuery, so you build on modeled tables.

Notes

  • Land raw exports first, then build clean models on top.
  • Prefer RevenueCat's price_in_usd / proceeds fields so revenue is already in one currency.
  • Timestamps often arrive as epoch milliseconds — convert once in a model layer.
  • MRR is derived, not stored: build it from active subscriptions and normalized product prices.

Can you generate a RevenueCat dashboard with AI?

Yes — and once RevenueCat data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Metabase MCP

Best for
Chat clients (Claude, Cursor, Codex)
Enable
Admin → AI → MCP
Endpoint
https://<your-metabase>/api/metabase-mcp
Auth
OAuth handled by Metabase

Metabase CLI

Best for
Terminal agents, scripts, and CI
Install
npm install -g @metabase/cli
Auth
Browser OAuth (v62+) or an API key
Docs
@metabase/cli

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

ClaudeClaude Code CLI
# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp
Cursor~/.cursor/mcp.json or .cursor/mcp.json
{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

Install & authenticateshell
# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the RevenueCat Subscription Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Prompt for creating a RevenueCat Subscription Overview dashboard
Create a polished Metabase dashboard for RevenueCat subscription analytics
using the available RevenueCat tables in this database.

Goal: Help founders and growth leaders understand mobile/web subscription
revenue, trials, conversion, churn, and LTV from RevenueCat data.

First, inspect the schema and identify the available RevenueCat tables (often a
transactions/events export plus customer aliases). Do not assume exact table
names. Map the raw data into these analytical concepts where possible:
Customers/subscribers, Subscriptions, Entitlements, Products, Transactions
(purchases, renewals, trials, refunds), Store, and Country.

Important:
- Build the dashboard from durable database/warehouse tables (RevenueCat data
  exports or REST API v2).
- Compute MRR from active subscriptions, normalizing every product to a monthly
  amount (annual / 12, weekly, etc.) and using proceeds/price in a single
  reporting currency (RevenueCat provides price_in_usd fields — prefer them).
- Separate voluntary churn from billing (failed-renewal) churn.
- Treat trials and intro offers as non-revenue until they convert.
- Exclude refunds from net revenue and show their impact separately.
- Do not claim Metabase connects natively to RevenueCat unless that is explicitly
  true in this environment.

Dashboard title: RevenueCat Subscription Overview

Sections:
1. Executive summary (KPI cards): MRR; Active subscriptions; Net new MRR this
   month; Trial-to-paid conversion %; Subscription churn %; Refund rate %.
2. Subscriptions & MRR: MRR movement by month; Active subscriptions by product
   and store.
3. Trials & conversion: Trial starts; Trial-to-paid conversion by product, store,
   and country; Time-to-convert.
4. Churn & retention: Subscription retention by cohort; Voluntary vs. billing
   churn; Grace-period recovery.
5. LTV & cohorts: Cumulative revenue by install cohort; ARPU/ARPPU; Revenue by
   store, country, and platform.

Filters: Product, Store (App Store/Play/Stripe), Country, Platform, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_rc_subscriptions, modeled_rc_transactions, and modeled_rc_mrr (a monthly
per-subscription MRR model).

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available schema. Reconcile totals against
RevenueCat Charts. Keep it practical, dense, and executive-readable. Avoid
vanity metrics.

How should you model RevenueCat data in Metabase?

Core tables

ConceptGrainKey columns
customersone row per subscriberapp_user_id, original_app_user_id, first_seen_at, country
subscriptionsone row per subscriptionapp_user_id, product_identifier, store, purchase_at, expiration_at, auto_renew_status
transactionsone row per purchase/renewalapp_user_id, product_identifier, price_in_usd, is_trial_period, is_refunded, purchase_at
entitlementsone row per grantapp_user_id, entitlement_id, product_identifier, expires_at

Modeling advice

  • Build a modeled_rc_mrr table: one row per subscription per month with a normalized monthly amount in USD — the backbone of every revenue chart.
  • Use original_app_user_id to stitch a subscriber's aliases into one identity across devices and stores.
  • Treat trials and intro offers as non-revenue until conversion; flag them explicitly.
  • Separate store/platform (App Store, Play, web) so tax and fee differences are visible.
  • Reconcile modeled MRR against RevenueCat Charts before anyone trusts the numbers.

Which RevenueCat metrics should you track in Metabase?

MetricDefinitionNotes
MRRSum of active subscriptions' normalized monthly amount.Use price_in_usd; exclude trials until converted.
Trial-to-paid conversionTrials that convert ÷ trials started.Segment by product, store, and country.
Subscription churn rateCanceled/lapsed ÷ active at period start.Split voluntary vs. billing (failed-renewal).
Net revenue retentionCohort MRR including renewals and upgrades.Watch resubscribes and win-backs.
LTVCumulative revenue per subscriber by cohort.Use proceeds (after store cut) for a true figure.
Refund rateRefunded transactions ÷ transactions.Store policies differ; segment by store.

What SQL powers RevenueCat dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect). Adjust identifiers to match your export schema.

Current MRR and ARRPostgreSQL

Sum a monthly per-subscription MRR model in USD.

-- Requires a monthly MRR model built from RevenueCat subscription data
SELECT
  ROUND(SUM(mrr_usd), 2)        AS mrr_usd,
  ROUND(SUM(mrr_usd) * 12, 2)   AS arr_usd,
  COUNT(*)                      AS active_subscriptions
FROM modeled_rc_mrr
WHERE month = date_trunc('month', CURRENT_DATE);
Trial-to-paid conversion by productPostgreSQL

How well trials convert across your product catalog.

-- Trial-to-paid conversion by product
SELECT
  product_identifier,
  COUNT(*) FILTER (WHERE is_trial_period)                        AS trials_started,
  COUNT(*) FILTER (WHERE converted_to_paid)                      AS converted,
  ROUND(100.0 * COUNT(*) FILTER (WHERE converted_to_paid)
    / NULLIF(COUNT(*) FILTER (WHERE is_trial_period), 0), 1)     AS conversion_pct
FROM revenuecat_transactions
WHERE purchase_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY product_identifier
ORDER BY trials_started DESC;
Refund rate by storePostgreSQL

Refunded transactions as a share of all transactions.

SELECT
  date_trunc('month', purchase_at)                    AS month,
  store,
  COUNT(*)                                            AS transactions,
  COUNT(*) FILTER (WHERE is_refunded)                 AS refunds,
  ROUND(100.0 * COUNT(*) FILTER (WHERE is_refunded)
    / NULLIF(COUNT(*), 0), 2)                         AS refund_rate_pct
FROM revenuecat_transactions
GROUP BY 1, store
ORDER BY 1, refund_rate_pct DESC;

What are common mistakes when analyzing RevenueCat in Metabase?

Running dashboards off a one-time CSV export.→ Schedule the sync so data stays fresh — a manual export goes stale the moment someone acts on it.
Counting trials as revenue.→ Trials and intro offers aren't paid yet — exclude them from MRR until they convert.
Ignoring the store's cut.→ App Store and Play take a commission — use proceeds (net) for LTV, not list price.
Double-counting subscribers across devices.→ Stitch aliases with original_app_user_id so one person isn't several subscribers.
Blending voluntary and billing churn.→ Separate cancellations from failed-renewal churn — the fixes are completely different.
Never reconciling with RevenueCat Charts.→ Sanity-check modeled MRR against RevenueCat's own charts before trusting them.

Related analytics

Related metrics

Related integrations

FAQ

Does Metabase connect natively to RevenueCat?
No. Metabase reads SQL databases and warehouses. Sync RevenueCat into a database first (scheduled data exports, the REST API v2, or webhooks), then connect Metabase to that database.
Why use Metabase if RevenueCat already has charts?
RevenueCat Charts are great for subscription KPIs. Metabase lets you join that data with product usage, ad spend, and attribution to answer questions RevenueCat can't — like LTV by acquisition channel — and to govern shared dashboards.
Should I use list price or proceeds for revenue?
Use proceeds (net of the store commission) for LTV and net revenue. RevenueCat exposes price and proceeds fields — pick one consistently and label it.