ARPU: Average Revenue Per User Explained

Average revenue per user, or ARPU, is the average amount of recurring revenue a subscription business earns from each paying customer over a set period, typically a month. It is calculated by dividing total recurring revenue by the number of active paying customers, and it condenses a company's entire revenue base into a single, comparable figure per customer.

ARPU matters because it sits at the intersection of pricing, product and growth strategy. A rising ARPU can mean customers are willing to pay more for what you offer, that your packaging is capturing more value, or that larger accounts are joining your customer base. A falling ARPU can mean discounting has crept in, new customers are smaller than historical ones, or churn is disproportionately affecting your higher-paying accounts. Because ARPU is simple to compute and easy to compare across time, it becomes one of the first metrics finance and product teams check when reviewing monthly performance, alongside monthly recurring revenue itself.

For a Stripe-only business, ARPU is particularly useful because Stripe already holds the ground truth data needed to compute it: subscription amounts, billing intervals, discounts, proration adjustments and customer counts. A dashboard connected via a restricted read-only Stripe key can therefore calculate ARPU continuously without any manual spreadsheet work, and can slice it by plan, currency or signup cohort using the same underlying data used for Stripe revenue analytics.

ARPU, ARPA and ACV are related metrics that are frequently confused, and picking the wrong one for your reporting can misrepresent how your business actually monetises customers.

• ARPU (average revenue per user) strictly refers to revenue per individual user or seat. This distinction matters in products where one paying account contains many users, such as a team plan with ten seats under a single Stripe customer.
• ARPA (average revenue per account) refers to revenue per paying account or Stripe customer, regardless of how many individual users sit inside that account. Most B2B SaaS companies bill at the account level, so ARPA is usually the more operationally relevant number even when teams label it ARPU in dashboards and board decks.
• ACV (annual contract value) is the annualised value of a single contract, commonly used in enterprise sales motions with annual or multi-year deals. ACV describes one deal, while ARPU or ARPA describe an average across many accounts. A company might report an average ACV of new enterprise deals alongside a blended ARPA across its entire base, including smaller self-serve customers.

The table below summarises the practical differences.

In practice, most dashboards, including Stripe-based ones, use "ARPU" loosely to mean "average revenue per paying Stripe customer", which is closer to ARPA. What matters more than terminology is being explicit about which denominator you are using, and keeping it consistent from month to month so trends are comparable.

The standard formula is: ARPU = total recurring revenue for the period divided by the number of active paying customers in that same period. In monthly terms, this is usually written as ARPU = MRR divided by number of active subscribers.

Worked example: suppose your Stripe account shows MRR of 45,000 dollars at the end of the month, and you have 300 active paying subscriptions. ARPU = 45,000 / 300 = 150 dollars per customer per month. If next month MRR grows to 50,000 dollars but the subscriber count also grows to 360, the new ARPU = 50,000 / 360 = 138.9 dollars. Even though total revenue grew, ARPU fell, which typically means new customers are, on average, buying smaller plans than the existing base. This is a common and often healthy pattern for a product expanding into a lower tier or a self-serve motion, but it is worth checking against expectations.

A few practical rules keep the calculation consistent:

• Use the same period for both the numerator and denominator. Comparing end-of-month MRR against an average subscriber count taken mid-month will distort the ratio.
• Decide whether trialling customers, paused subscriptions or free-plan customers count in the denominator. Most teams exclude non-paying accounts, since including them artificially deflates ARPU.
• Exclude one-off, non-recurring charges from the numerator unless you are deliberately calculating a separate blended revenue-per-customer figure that includes them. See how to calculate MRR in Stripe for the equivalent rules on the revenue side.
• Decide on customers versus subscriptions as your denominator. A single customer with two active subscriptions should usually be counted once if you are measuring account-level ARPU, or twice if you are measuring per-subscription revenue.

Because Stripe stores subscription items, billing intervals and proration data directly, a connected dashboard can automate this calculation exactly rather than approximating it from invoice totals, which avoids the common error of counting annual invoices as monthly revenue.

Annual and multi-currency subscriptions need to be normalised before they can be averaged meaningfully with monthly plans, because comparing raw invoice amounts across different billing intervals and currencies produces a misleading average.

For annual plans, convert the contract value to a monthly equivalent before including it in ARPU. A 1,200 dollar annual plan should contribute 100 dollars to monthly recurring revenue and therefore 100 dollars to the ARPU calculation, not 1,200 dollars in the month it renews and zero dollars for the following eleven months. Skipping this normalisation is one of the most common reasons ARPU appears to spike or crash month to month for businesses with a mix of monthly and annual billing.

For multi-currency businesses, all revenue figures should be converted to a single reporting currency, usually at a consistent exchange rate applied across the reporting period, before ARPU is calculated. Mixing currencies without conversion will produce a nonsensical average, and using a different exchange rate for each transaction date introduces noise that has nothing to do with underlying customer economics.

A Stripe-connected dashboard that already normalises annual plans into monthly recurring revenue and standardises currencies for MRR reporting can reuse that same normalised revenue figure as the numerator for ARPU, keeping both metrics consistent with each other.

Blended ARPU averages revenue across every paying customer regardless of plan, channel or company size, while segmented ARPU calculates the same ratio separately for each meaningful group of customers. Both are useful, but they answer different questions.

Blended ARPU is the simplest number to report to a board or investor because it reduces the entire customer base to one figure, but it can hide very different unit economics. Imagine a company with 200 customers on a 20 dollar starter plan and 20 customers on a 500 dollar enterprise plan. Blended ARPU = (200 x 20 + 20 x 500) / 220 = (4,000 + 10,000) / 220 = 63.6 dollars. That single figure describes neither segment well: starter customers pay a third of that, enterprise customers pay nearly eight times that.

Segmented ARPU breaks this down by plan, channel, region or company size, giving a much more actionable view. Useful segmentation dimensions include:

• Plan tier, such as starter, growth and enterprise
• Acquisition channel, such as self-serve signup versus outbound sales
• Company size band, such as under 10 employees versus 200 plus
• Geography or billing currency
• Signup cohort, such as customers acquired in a specific quarter

Segmented ARPU is particularly important when deciding where to invest in sales and marketing. If enterprise ARPU is eight times higher than self-serve ARPU but enterprise acquisition cost is only three times higher, that segment is more efficient to grow, even though it looks smaller in raw customer count.

Tracking ARPU by plan tier shows whether your packaging is guiding customers toward the value you intend, while tracking ARPU by signup cohort shows whether newer customers are becoming more or less valuable over time than earlier ones.

By plan, ARPU should roughly reflect list price adjusted for typical discounting. If your growth plan lists at 99 dollars a month but the plan's ARPU is consistently 70 dollars, that gap points to heavy discounting, grandfathered legacy pricing, or significant partial-month proration effects that are worth investigating individually rather than assuming they will average out.

By cohort, group customers by the month or quarter they first subscribed and track how each cohort's average revenue evolves over its lifetime. A cohort's ARPU rising over time indicates successful upselling and expansion within that group, sometimes called negative churn when expansion outweighs downgrades and cancellations. A cohort's ARPU falling over time, even before accounting for churned customers who drop out of the denominator entirely, points to downgrade pressure or plan fatigue.

Worked cohort example: a cohort of 50 customers acquired in January starts with ARPU of 80 dollars a month. Twelve months later, 40 of those customers remain and their combined revenue is 3,600 dollars, giving a cohort ARPU of 90 dollars. Revenue per surviving customer rose even though ten customers churned, which suggests the surviving customers expanded their usage or upgraded plans. Comparing this against churn rate for the same cohort gives a fuller picture of whether the cohort is healthy overall.

Expansion revenue, meaning additional revenue from existing customers through upsells, add-ons, seat growth or plan upgrades, increases ARPU without requiring a single new customer, and is usually the fastest and cheapest way to raise this metric.

Consider a customer who starts on a 200 dollar a month plan and, six months later, adds a 50 dollar premium analytics add-on and upgrades from 20 to 35 user seats at 5 dollars per seat. Their monthly revenue is now 200 + 50 + (15 extra seats x 5) = 325 dollars, a 62.5 percent increase without any change in customer count. If this pattern repeats across a meaningful share of the customer base, blended ARPU rises even if new customer ARPU stays flat.

This is why ARPU trends should always be read alongside net revenue retention. A rising blended ARPU driven mostly by expansion among existing customers is a strong signal of product-led growth and pricing power. A rising blended ARPU driven mostly by losing your smallest, lowest-paying customers to churn while retaining larger accounts is a very different story, and one that should prompt closer attention to churn rather than celebration of the ARPU number alone.

To separate these two causes, decompose the change in ARPU into new customer ARPU, expansion ARPU from existing customers, and the mix effect of which customers churned. Most Stripe-based dashboards that track daily subscription movement alongside churn can support this decomposition because they already record subscription changes at the event level, not just as period-end snapshots.

ARPU can be raised deliberately through pricing and packaging changes, and the most effective levers tend to align price more closely with the value a customer actually receives, rather than simply raising list prices across the board.

• Usage-based add-ons. Charging for consumption above a base allowance, such as extra API calls, storage or messages sent, lets high-usage customers pay proportionally more without penalising light users on the base plan.
• Per-seat pricing. Charging per active user rather than a single flat fee per account naturally raises ARPU as customer teams grow, and aligns your revenue with the size of the account you are serving.
• Feature-gated tiers. Packaging premium features, such as advanced reporting, SSO or priority support, into a higher tier gives customers a clear reason to upgrade rather than relying on discretionary upsell conversations.
• Annual contract incentives. Offering a modest discount, commonly in the region of 10 to 20 percent, for annual prepayment can raise realised revenue per customer over the year even at a lower headline monthly rate, while also improving cash flow and reducing monthly churn exposure.
• Price increases for new cohorts. Raising list price for new customers while grandfathering existing ones is lower risk than a blanket increase and gradually lifts new-customer ARPU without provoking existing-customer churn.
• Bundling complementary products. Combining two previously separate products or add-ons into a single higher-priced bundle can raise average deal size, provided the bundle genuinely reflects more value rather than forced packaging.

Each of these levers should ideally be tested on a subset of new signups or a specific segment before being applied to the whole base, and the resulting ARPU change should be tracked segment by segment rather than only at the blended level, so you can see clearly which lever is actually working.

ARPU is one of the two core inputs to customer lifetime value, alongside customer lifetime or churn rate, which makes it one of the most consequential metrics in the entire SaaS metrics stack because errors in it compound through downstream calculations.

The most common simplified formula is:
LTV = ARPU divided by monthly churn rate.
An equivalent version, using average customer lifetime directly, is:
LTV = ARPU multiplied by average customer lifetime in months.

Worked example: if ARPU is 150 dollars a month and monthly churn rate is 2 percent, LTV = 150 / 0.02 = 7,500 dollars. If churn rises to 4 percent with ARPU unchanged, LTV halves to 3,750 dollars, illustrating why churn reduction and ARPU growth are usually discussed together rather than in isolation. See customer lifetime value for a fuller treatment of this formula and its variants, including versions that incorporate gross margin.

Because LTV is frequently compared against customer acquisition cost to produce the LTV to CAC ratio, a commonly cited rule of thumb is to look for a ratio of roughly 3 to 1 or higher as a sign of a sustainable acquisition motion, though this varies by industry and growth stage and should not be treated as a strict pass or fail threshold. Since ARPU sits directly in the numerator of LTV, even a modest miscalculation, such as including one-off setup fees in ARPU, can overstate LTV and make an unprofitable acquisition channel look sustainable on paper.

ARPU also interacts with ARPU-adjacent metrics like the broader SaaS metrics glossary defines, and should always be checked for consistency against MRR and active customer counts rather than calculated from a separate, disconnected data source.

ARPU does not appear directly in most simple SaaS valuation formulas, which are typically based on annual recurring revenue multiples, but it strongly influences the multiple a business commands by shaping perceptions of customer quality, retention and growth efficiency.

A commonly cited rule of thumb for early-stage or bootstrapped SaaS valuation is roughly 3x to 5x annual recurring revenue, which can be approximated as monthly recurring revenue multiplied by 36 to 60. Subscription Metric uses a 5x ARR approach, calculated as MRR multiplied by 60, as a straightforward reference point. Under this approach, a business with 40,000 dollars in MRR would be valued at roughly 40,000 x 60 = 2,400,000 dollars as a starting estimate, before adjusting for growth rate, churn, concentration risk and margin. See SaaS valuation multiples for more detail on how these ranges are typically applied and adjusted.

Where ARPU comes in is as a quality signal layered on top of the headline multiple. Two businesses with identical MRR of 40,000 dollars can look very different once ARPU is examined:

Business A's low ARPU but broad customer base suggests resilience to any single customer churning, but may signal limited pricing power or a highly price-sensitive market. Business B's high ARPU suggests strong monetisation per account but leaves the business more exposed if a handful of top accounts leave, which is why reviewing top customers by lifetime value is a standard part of due diligence conversations even when the headline MRR multiple looks identical.

In practice, buyers and investors often apply a discount to the simple MRR x 60 reference point when ARPU is concentrated in a small number of accounts, and a premium when ARPU is rising steadily across a broad, diversified base with strong net revenue retention.

Most ARPU tracking errors come from inconsistent denominators, mixed billing periods or including revenue that should not count as recurring, and each of these can be avoided with a few consistent rules.

• Mixing paying and non-paying accounts. Including free-tier or trialling users in the denominator without also including their zero revenue in the numerator artificially deflates ARPU and understates monetisation.
• Counting annual invoices as full monthly revenue. An annual invoice landing in a single month will spike that month's apparent ARPU unless it is normalised to a monthly equivalent, which then drops sharply the following month with no real change in the underlying business.
• Including one-off charges. Setup fees, one-time consulting invoices or hardware sales processed through the same Stripe account should generally be excluded from ARPU, since ARPU is meant to reflect the ongoing subscription relationship rather than one-time transactions.
• Reporting only blended ARPU. Relying on a single blended figure hides plan mix shifts, channel differences and cohort trends that matter far more for decision-making than the headline number.
• Ignoring currency effects. For businesses billing customers in multiple currencies, failing to convert consistently before averaging produces a distorted figure that has more to do with exchange rate movement than customer behaviour.

Automating ARPU calculation directly from Stripe subscription and invoice data, rather than reconstructing it manually in a spreadsheet each month, removes most of these errors because the underlying data, including proration, discounts and billing intervals, is already structured and consistent at source.

ARPU should be monitored monthly as part of a standard recurring revenue review, segmented by plan and cohort at least quarterly, and recalculated immediately after any significant pricing change to measure its effect.

A practical monitoring routine looks like this: review blended ARPU alongside MRR movement and active customer count every month to catch sudden shifts early; review ARPU by plan tier and by acquisition channel quarterly to check whether packaging and go-to-market motions are performing as intended; and review ARPU by cohort at least twice a year to see whether customer value is growing or shrinking over the customer lifecycle. Combining this with churn reduction efforts gives a fuller picture of revenue health than either metric alone, since a business can have rising ARPU and still be losing overall revenue if churn among its remaining customers accelerates.

Because ARPU depends entirely on accurate, up-to-date subscription and revenue data, the most reliable way to track it is directly from your payment processor rather than from periodic manual exports. A dashboard connected to Stripe through a restricted read-only API key can compute ARPU continuously, segment it automatically by plan and cohort, and export the results as CSV, JPG or PDF for board reporting, keeping the calculation consistent every single month without manual recalculation.