ARPU, or average revenue per user, is total revenue in a period divided by the number of users in that period.
For a subscription app, the useful version is usually revenue per install for a cohort: what each new install earned over 14, 60 or 365 days, counting the people who never paid.
ARPPU (average revenue per paying user) divides the same revenue by payers only.
ARPU combines how many users pay and how much they pay, so it's the metric to watch when a paywall or price test moves those two in opposite directions.
Below: the formulas, the per-install vs per-active-user split, 2026 category medians, and the tests in our database that raised it.
ARPU definition and formula (ARPU vs ARPPU)
The basic formula is simple:
- ARPU = revenue in the period ÷ all users in the period
- ARPPU = revenue in the period ÷ paying users in the period
- Paying share = paying users ÷ all users
The three are linked: ARPU = ARPPU × paying share.
That identity explains most of what happens in app pricing tests.
A higher price usually raises ARPPU and lowers paying share, and ARPU tells you which effect was bigger.
ARPU vs ARPPU in one line: ARPU answers "what is a user worth?", ARPPU answers "what is a customer worth?"
You need both. A rising ARPPU with a falling ARPU means you're charging fewer people more and losing money overall.
Telecom and gaming teams use the same term, usually per month and per active subscriber or player.
Subscription apps borrow it, but the denominator matters more for apps because most installs never pay.
For the wider metric set, see our subscription metrics guide.
ARPU per install vs per active user
There are two common ways to count "users," and they give very different numbers.
Per install (cohort ARPU)
Take everyone who installed in a given week or month, then add up what that cohort paid over a fixed window.
RevenueCat reports this as revenue per install (RPI) at day 14 and day 60. It's the version you compare against cost per install, and it's the version most paywall tests should use, because the test assigns users at install or first paywall view.
Per active user (period ARPU)
Take revenue in a calendar month and divide by monthly active users.
This suits apps with ads or usage-based revenue, and it's the number finance teams often mean.
It mixes old and new users, so a change in acquisition volume can move it without any change in the product.
Pick one definition per report and write it down.
"ARPU went up 10%" is meaningless if one month used installs and the next used active users.
Which window to use
Short windows (day 7 or day 14) catch weekly plans and trial conversions but miss renewals.
Annual plans book their full price up front, so a short window can make annual-heavy paywalls look better than they will be after refunds and non-renewals.
When a test shifts plan mix, check day 60 or later, and pair it with an LTV estimate.
Worked example with the ARPU calculator
The calculator above takes revenue, users, paying users and an expected test lift. Here is the method it follows.
Say an app has a monthly install cohort of 10,000 users.
Over 60 days those users generate $4,000 in revenue, and 200 of them paid.
- ARPU = $4,000 ÷ 10,000 = $0.40 per install
- ARPPU = $4,000 ÷ 200 = $20.00 per payer
- Paying share = 200 ÷ 10,000 = 2.0%
Now enter a 17% test lift, close to the ARPU gain in the driver's test app paywall redesign below.
New ARPU = $0.40 × 1.17 = $0.468. Extra revenue = ($0.468 − $0.40) × 10,000 = $680 per 10,000 installs, or $8,160 a year at that install volume.
That is the number to weigh against the cost of building and running the test.
It also shows why small apps struggle to detect ARPU changes: revenue is concentrated in 2% of users, so you need large samples.
Check yours with the sample size calculator before you start.
Typical ARPU by app category
RevenueCat's State of Subscription Apps 2026 covers over 115,000 apps and more than $16 billion in revenue, using 2025 data.
Its median revenue per install figures are the closest public benchmark for subscription-app ARPU.
| Segment | Median RPI, day 14 | Median RPI, day 60 |
|---|---|---|
| All categories | $0.23 | $0.34 |
| Health & Fitness | $0.48 | $0.66 |
| Business | $0.31 | $0.50 |
| Education | $0.30 | not reported here |
| Gaming | $0.08 | $0.14 |
| North America | $0.38 | $0.55 |
| Western Europe | $0.25 | $0.33 |
| Hard paywall apps | $2.32 | $3.09 |
| Freemium apps | $0.27 | $0.38 |
The same report puts median first-year realized LTV per payer, which is close to a one-year ARPPU, at $35.64 for Health & Fitness, $35.48 for Business, $24.95 for Productivity, $22.82 for Education and $11.22 for Gaming.
The biggest gap in the table isn't category.
It's the business model: hard paywall apps earn several times more per install early on.
RevenueCat also reports median day-35 download-to-paid conversion of 10.7% for hard paywalls vs 2.1% for freemium, while noting that one-year retention ends up nearly identical.
We cover that tradeoff in hard vs soft paywalls.
Use medians as a sanity check, not a target.
Your price point, geography mix and trial length shift ARPU more than your category label does.
What raised ARPU in our database
Our app database tracks paywall, onboarding and pricing tests where the team reported ARPU, ARPPU or proceeds per user.
Most come from RevenueCat and Superwall case studies, so treat the numbers as vendor-reported. They fall into three groups.
Price tests
Raising the price was the most direct lever, and conversion often fell less than revenue per payer rose.
- Planner 5D tested two higher price tiers and saw +83% ARPU for the highest tier (Superwall case study).
- PropGPT raised its weekly price from $6.99 to $9.99 and got +47.5% proceeds per user.
- BuyBye raised the yearly price 50%: conversions fell 19%, but proceeds per user rose 25%. That's the ARPU = ARPPU × paying share identity in action.
- Mojo raised its yearly price 50% with only a minimal drop in free-to-paid conversion.
Price doesn't only go up. SellRaze lowered its annual price and got +10% ARPU, because more users bought.
Test both directions. More in our pricing tests.
Plan mix and anchoring
Which plans you show, and how you frame them, changes the average price paid without changing any price.
- Preu AI priced its annual plan against the monthly one and reported +80% proceeds per user and +22% trial conversion.
- Rash ID showed three plans with a best-offer badge: about +20% ARPU and over +50% conversion to paid.
- Stardust added a discount badge and a weekly-equivalent price: +50% conversion, +62.5% proceeds per user and +30% yearly share.
- Mojo showed only the yearly plan and raised yearly share by 15 to 20 percentage points.
A caution from the same app: Stardust's yearly-only paywall lost on both conversion and proceeds per user.
What works for one app's plan mix can fail for another. See more in plan tests.
Paywall design, trials and onboarding
- Fits found +19% ARPU for a toggle paywall over a timeline paywall.
- A driver's test app redesign by Vahe Baghdasaryan, a short paywall with a trial toggle, raised ARPU 17.02%.
- Vahe Baghdasaryan also reported that a $1.99 paid 30-day trial lifted day-90 ARPU from $2.23 to $2.89 (+30%) in health and fitness apps.
- Unchaind previewed premium features on the paywall: over +50% conversion and +64% estimated ARPU.
- Applica's onboarding rebuild for Five Minute Journal brought +20% ARPU, and its ASL Bloom work brought +12% ARPU alongside +15% trial conversion.
- AEZAKMI Group tested six onboarding flows for an LED controller app: conversion went from 0.8% to 1.29%, and ARPU from $0.12 to $0.14 (+16%).
Several of these were bundled changes, so you can't credit the lift to one element.
Browse all paywall tests and onboarding guidance for details.
Using ARPU as an A/B test metric
Conversion rate alone is a poor primary metric for paywall and price tests, because it ignores what each payer spends.
BuyBye's 19% conversion drop would have looked like a loss on conversion alone. ARPU captures both sides.
A few rules make it work:
- Use per-install or per-paywall-viewer ARPU, with every assigned user in the denominator, including those who never paid.
- Fix the window before launch (for example, day 30 revenue per user) and compare both variants over the same window.
- Watch for plan-mix effects. Annual plans front-load revenue. If a variant pushes annual share, check refunds and renewal before calling it, and report ARPPU and paying share next to ARPU.
- Expect noisy results. Revenue is skewed, so ARPU needs more users than a conversion test to reach significance. Run the significance calculator on the result, and don't stop the test early.
- Check retention afterward. TalkingParents raised its price with a new feature and about a quarter of customers churned, though it was better off financially overall. Track that with the churn rate calculator.
For the full setup, from tools to test durations, read our guide to A/B testing subscription apps.