Stripe Revenue Analytics: What Stripe Shows and What It Doesn't

Stripe's built-in dashboard is designed around payment operations: it shows gross payment volume, net volume after fees, your current balance, upcoming payouts, and a basic revenue chart broken down by day, week or month. If you use Stripe Billing, you also get subscriber counts, a simple churn number and a coarse MRR figure in the Billing section of the dashboard.

These native reports are useful for reconciling payouts and spotting obvious changes in volume, but they are not built for the specific questions a subscription business asks day to day, such as how much of this month's MRR growth came from new customers versus expansion, what the trailing twelve month churn rate looks like by cohort, or what a typical customer is worth over their lifetime. Answering those questions from the native dashboard usually means exporting raw data and building your own spreadsheet model.

Several metrics that matter most for running a subscription business are absent from Stripe's own reporting, or only partially available. This is the main reason dedicated Stripe revenue analytics tools exist alongside it.

• MRR movement broken into new, expansion, contraction, reactivation and churned revenue, which is essential for understanding whether growth is healthy or fragile. See what is MRR for the full definition.
• Cohort-based churn rate calculated consistently over time, rather than a single trailing figure. Read more in the guide to SaaS churn rate.
• Customer lifetime value and average revenue per user, which require combining subscription duration with average billing amounts. See customer lifetime value and ARPU.
• A ranked list of top customers by lifetime value rather than just recent transaction size.
• A clean split between recurring subscription revenue and one-off payments on a daily basis.
• Consolidated reporting across more than one Stripe account.
• A revenue-based valuation estimate, since Stripe has no reason to estimate what your business is worth.

None of this means Stripe's dashboard is deficient for its purpose. It is a payments platform first, and its reporting reflects that. The gap is simply that subscription businesses need a second, purpose-built layer of analytics on top of the raw payment data Stripe already holds.

A restricted API key is a Stripe API key that you configure to have access to only specific resources and only specific levels of access to each one, rather than the full account access that a standard secret key carries. This is the correct way to connect any third-party analytics tool to your Stripe account, because it limits what that tool can do even if the key were ever exposed.

You create a restricted key from Developers, then API keys, then Create restricted key inside the Stripe dashboard. Stripe presents a long list of resources, each with a dropdown you can set to None, Read or Write. For a revenue analytics dashboard, the correct configuration is read access on a small set of resources and none on everything else, including anything related to money movement, refunds, payouts or account configuration.

Recommended permission set

Once the key is created, Stripe shows it exactly once. Paste it into the analytics tool immediately, then treat it as a secret. If you ever need to disconnect the tool, revoke the key from the same Developers screen and it stops working immediately, with no need to change your live or publishable keys.

Handling a Stripe key safely comes down to a small number of consistent habits, whether you are connecting one tool or several. The goal is to minimise what any single key can do and to make it easy to cut off access quickly if something looks wrong.

• Always use a restricted key scoped to read-only access for analytics tools, never your main secret key.
• Confirm the tool transmits the key over HTTPS and states clearly how it is stored, ideally encrypted at rest.
• Give each connected tool its own restricted key rather than reusing one key everywhere, so you can revoke individually.
• Name keys descriptively in the Stripe dashboard, for example "Analytics dashboard, read-only", so old ones are easy to identify later.
• Review your list of active API keys periodically and revoke any you no longer recognise or use.
• Rotate keys on a schedule if your organisation has a policy for it, even without a specific incident.
• Never paste a Stripe key into chat tools, tickets, source control or shared documents.

A tool built specifically around restricted keys, such as Subscription Metric, is generally a lower-risk way to get analytics than exporting raw CSVs from Stripe and emailing them around, or building an internal script that stores a full secret key in a config file. The restricted key model means the analytics provider is structurally unable to move money or change your Stripe settings, regardless of what happens on their side.

Subscription revenue and one-off payments behave differently and should be analysed separately, because blending them distorts every core subscription metric. A single large one-off invoice can make MRR look like it jumped, when in fact recurring revenue did not move at all.

In Stripe's data model, recurring revenue generally comes from invoices tied to an active subscription object, billed on a fixed interval such as monthly or annually. One-off payments are typically charges or payment intents created directly, or invoices not linked to a subscription, such as a one-time setup fee or a professional services charge. A revenue analytics dashboard needs to classify every payment into one of these two buckets before it can calculate MRR correctly.

Worked example

Suppose in a given month your Stripe account processes the following: 200 dollars worth of recurring monthly subscriptions from 40 active customers billed at 5 dollars each, and a single 1,000 dollar one-off charge for a custom onboarding package. If these are blended, total revenue for the month looks like 1,200 dollars and could be mistaken for MRR. Correctly separated, MRR is 200 dollars and the 1,000 dollar charge is reported separately as one-off revenue. The difference matters enormously for valuation, since a revenue multiple should be applied to MRR annualised, not to total cash collected in a single month.

A daily chart that plots subscription revenue and one-off revenue as separate series makes this distinction visible at a glance, rather than requiring you to inspect individual transactions to work out why a particular day looks unusual.

Many growing businesses end up with more than one Stripe account, whether from running separate products, separate regions with different currencies and tax setups, separate legal entities, or an acquisition that brought in its own Stripe account. Stripe itself does not offer a way to view combined reporting across fully separate accounts unless you use Stripe Connect in a platform arrangement, which is a different setup from simply owning multiple independent accounts.

A multi-account capable analytics dashboard solves this by letting you connect a restricted read-only key from each Stripe account and then presenting both a combined view and per-account breakdowns. This matters for a few common situations:

• Reporting total company MRR to investors or a board, even though the underlying revenue sits in three separate Stripe accounts.
• Comparing churn rates between a US entity and a EU entity that bill in different currencies.
• Tracking overall valuation using combined MRR across products, rather than valuing each Stripe account in isolation.
• Keeping per-account detail available for finance or product teams who only need to see their own numbers.

When accounts use different currencies, a consolidation feature needs to convert amounts to a single reporting currency using a consistent exchange rate approach, otherwise combined MRR and ARPU figures will drift as rates move, even if underlying subscriber counts and prices have not changed.

Historical backfill means pulling in a Stripe account's full transaction and subscription history, not just data from the point a new analytics tool was connected, so that metrics such as churn cohorts and lifetime value are calculated correctly from day one rather than starting with an artificially short history.

This matters more than it might first appear. Churn rate calculated from only three months of data can look very different from churn calculated over three years, because early cohorts often behave differently to more mature ones, and short windows are more sensitive to one or two large customers churning. Lifetime value estimates are similarly unreliable without enough historical subscriber lifetime data to model realistic retention curves. A tool that can backfill and recompute metrics from the complete history available in your Stripe account, commonly cited as up to around 10 years for older accounts, gives a far more stable and trustworthy baseline than one that only looks forward from the connection date.

In practice, backfilling involves paginating through Stripe's list endpoints for customers, subscriptions, invoices and charges, going back as far as records exist, then reconstructing a month-by-month MRR movement history from that raw data. This is a reasonably heavy one-time processing job, which is why it is usually run automatically once when a Stripe key is first connected, rather than something you need to trigger manually.

Exporting Stripe analytics in multiple formats matters because different audiences need different things: a finance team wants raw numbers to manipulate further, a founder wants a chart to drop into a Slack update, and a board or investor wants a clean, static report they can read without logging into anything.

CSV exports

CSV exports are best for further analysis. A monthly MRR movement CSV, for example, with columns for new, expansion, contraction, reactivation and churned MRR by month, can be pulled directly into a spreadsheet model, joined with other internal data, or fed into a separate business intelligence tool without any manual reformatting.

JPG exports

JPG exports of individual charts are the fastest way to share a specific trend, such as a churn curve or an MRR growth chart, in a message or a slide, without needing the recipient to have access to the dashboard at all.

PDF exports

PDF exports typically combine several charts and headline numbers into a single formatted report, suitable for a monthly board pack or an investor update. Because a PDF is static, it also works well as an archived snapshot of your metrics at a particular point in time, which a live dashboard cannot provide once the underlying numbers change.

A complete Stripe revenue analytics dashboard should calculate a consistent set of core metrics from the same underlying subscription and invoice data, so that every number on the dashboard reconciles with every other number rather than being computed separately.

• MRR and MRR movement, covering new, expansion, contraction, reactivation and churned revenue each month. See how to calculate MRR in Stripe for the underlying formulas.
• Customer and revenue churn rate, both gross and net, tracked over time rather than as a single snapshot. See SaaS churn rate.
• Net revenue retention, which shows whether existing customers are expanding or contracting their spend over time regardless of new sales. See net revenue retention.
• Customer lifetime value and average subscriber lifetime, calculated from average monthly revenue per customer divided by churn rate. See customer lifetime value.
• Average revenue per user, both blended and broken out by plan. See ARPU.
• Top customers ranked by lifetime value, useful for account management and renewal prioritisation.
• Daily subscription versus one-off payment volume, as covered above.
• A rough valuation estimate using MRR multiplied by 60, equivalent to 5 times ARR. See SaaS valuation multiples for how this rule of thumb is typically used and its limitations.

Subscription Metric is a Stripe-only analytics dashboard built specifically to close the gap between what Stripe's native reporting shows and what a subscription business actually needs to track. It connects using a restricted read-only Stripe key with the permission set described earlier, and never requests write access to your account.

Once connected, it computes MRR movement, churn, net revenue retention, customer lifetime value, ARPU, average subscriber lifetime and a ranked list of top customers by LTV, all from the same underlying Stripe data, so the numbers stay consistent with one another. It separates daily subscription revenue from one-off payments automatically, rather than requiring manual tagging. It supports connecting and combining multiple Stripe keys for businesses that run more than one Stripe account, with both combined and per-account views. It backfills historical data going back as far as your Stripe account allows, commonly up to around 10 years, so churn and lifetime value figures are based on a full history rather than a short recent window. And it exports every chart and report in CSV, JPG and PDF formats, covering spreadsheet analysis, quick sharing and formal reporting from the same dashboard.

It is intentionally not a payments platform or an invoicing tool. It does not replace Stripe's own dashboard for managing charges, disputes or payouts, and it does not attempt to be a general-purpose business intelligence tool. It is scoped narrowly to subscription revenue analytics, which is also why the permissions it asks for from Stripe are correspondingly narrow.

If you want to see how these metrics look against your own numbers, you can connect a restricted read-only Stripe key and the dashboard will populate directly from your live Stripe data, with nothing to configure beyond generating the key itself.

Getting started with a Stripe revenue analytics dashboard is a short, low-risk process when the tool relies on restricted read-only keys, because there is nothing to migrate and nothing that can affect your live Stripe account.

• Create a restricted key in Stripe with read access to Customers, Subscriptions, Invoices, Charges and Products, and none elsewhere.
• Paste the key into the analytics dashboard when prompted, ideally into a tool that states its storage and encryption practices clearly.
• Let the initial backfill run so historical MRR, churn and lifetime value figures are based on complete data.
• Repeat the process for any additional Stripe accounts if you need consolidated reporting.
• Set up a regular export cadence, for example a monthly PDF for board reporting and CSV exports as needed for finance.
• Review your Stripe API key list periodically and revoke any keys tied to tools you no longer use.

From there, the dashboard should update automatically as new Stripe activity comes in, without any further manual work, giving you a continuously current view of MRR, churn, lifetime value and valuation alongside whatever reporting you already do inside Stripe itself.