A pricing change lifts average spend, so the monetization dashboard looks healthier. But total revenue slips because fewer people pay. This is the trap ARPPU can create when an app team treats one useful metric as the whole business outcome.
ARPPU means average revenue per paying user. Calculate it by dividing revenue from paying users during a defined period by the number of unique paying users in that same period; it shows how effectively an app monetizes people who actually spend.
This guide explains the formula, denominator rules, cohort analysis, and practical ways to improve ARPPU without losing sight of payer conversion, retention, or total revenue.
What is ARPPU, and what does it measure?
ARPPU isolates the spending behavior of paying customers. Non-paying users are excluded from the denominator, so the metric answers a focused question: *among the people who paid during this period, how much revenue did each generate on average?*
That makes ARPPU useful for apps built around subscriptions, paid downloads, and in-app purchases. A product or growth team can use it to compare:
- subscription plans, bundles, and price points;
- countries, platforms, and app versions;
- acquisition campaigns and install cohorts;
- new, repeat, and reactivated payers;
- 7-day, 30-day, or monthly monetization performance.
Adjust’s ARPPU definition excludes ad revenue because ads are generated by paying and non-paying users. If an app combines purchases with advertising, use ARPU or ARPDAU for the blended revenue view and ARPPU for direct payer revenue.
ARPPU is an average, not a description of a typical customer. A small group of high spenders can pull it upward even when the median payer spends much less. Pair the mean with payer counts and a spend distribution when revenue concentration matters.
How to calculate ARPPU correctly
The ARPPU formula is:
ARPPU = revenue from paying users in period / unique paying users in periodSuppose an app records $36,000 in qualifying purchase revenue from 1,200 unique paying users during July:
ARPPU = $36,000 / 1,200
ARPPU = $30The app generated an average of $30 per payer in July. It does not mean that every payer spent $30 or that a payer will be worth $30 over their lifetime.
Define the revenue numerator
Decide whether the numerator represents gross sales or net proceeds, then keep that definition consistent. Gross sales are useful for pricing and customer-spend analysis. Net proceeds are better for contribution and profitability analysis because they account for relevant deductions.
Store dashboards make this distinction explicit. Apple defines Sales as the amount billed to customers and Proceeds as the amount after applicable taxes and Apple’s commission. Its reporting also separates refunded sales and refunded proceeds. Similarly, Google Analytics defines purchase revenue as purchases, in-app purchases, and subscriptions minus refunds.
Document these choices beside the metric:
- included revenue streams;
- gross sales or net proceeds;
- refund and chargeback treatment;
- reporting currency and exchange-rate source;
- timezone and period boundaries.
Do not compare gross ARPPU for one platform with net ARPPU for another. The formula may be identical, but the result is not comparable.
Define the paying-user denominator
Count unique users who completed at least one paid transaction during the period. Count a repeat buyer once, not once per order. A free-trial user does not become a payer until a charge succeeds.
Apple’s reporting defines a paying user as a unique Apple Account that paid for an app or an in-app purchase. Your cross-platform analytics may use a different identity, such as an internal account ID. Choose one durable identifier and deduplicate purchases across devices where the available data permits.
Use the same window for numerator and denominator. Dividing July revenue by June payers, or 30-day cohort revenue by all-time payers, produces a number with no stable meaning.
ARPPU vs. ARPU, ARPDAU, LTV, and CPV
Similar acronyms answer different questions. The denominator and time window determine what each one can tell you.
| Metric | Basic calculation | Best question it answers |
|---|---|---|
| ARPPU | Direct payer revenue / unique payers | How much does each payer spend on average? |
| ARPU | Total selected revenue / all users | How well does the app monetize its whole user base? |
| ARPDAU | Daily revenue / daily active users | How did daily monetization respond to a release, event, or campaign? |
| LTV | Cumulative value over a user or cohort lifetime | How much value can acquisition generate over time? |
| CPV | Video campaign cost / paid views | How much did each qualifying video view cost? |
The ARPDAU formula uses daily active users, whether or not they pay. ARPPU uses only payers and can use a day, week, month, or fixed cohort window. Unity’s IAP reporting reference lists ARPPU alongside payer conversion rate, ARPDAU, new spenders, refunds, country, platform, and purchase channel—useful context for interpreting a movement.
CPV meaning is unrelated to user revenue: it is an acquisition-cost metric for video advertising. The CPV formula can help evaluate what traffic cost, but it cannot show what a payer spent after installing. Connect acquisition cost to cohort revenue or LTV before changing campaign budgets.
Period ARPPU vs. cohort ARPPU
Period ARPPU includes everyone who paid inside a calendar window, regardless of when they installed. It is useful for monitoring current monetization and spotting sudden changes.
Cohort ARPPU groups users by a shared starting point—such as install week, first purchase month, campaign, creative, country, or app version—and gives every cohort the same revenue window. AppsFlyer’s cohort ARPPU guidance frames the calculation as revenue generated in one period by users acquired in another, divided by paying users acquired in that cohort.
For a fair 30-day comparison, calculate each install cohort after it has had a full 30 days to mature. Do not compare a cohort with 30 days of revenue against one with only 12 days. RevenueCat’s cohort documentation flags incomplete periods for this reason and calculates realized value using cohort revenue minus refunds.
Use period ARPPU to detect a change. Use cohort ARPPU to find where it came from.
Why a higher ARPPU can still be bad news
ARPPU can rise because customers spend more. It can also rise because lower-spending payers stop buying, leaving a smaller group of high spenders in the denominator.
Consider a price test across 10,000 monthly active users:
| Metric | Control | New price |
|---|---|---|
| Paying users | 500 | 400 |
| Payer conversion | 5.0% | 4.0% |
| Purchase revenue | $10,000 | $9,600 |
| ARPPU | $20 | $24 |
ARPPU increases 20%, but payer conversion falls and total purchase revenue declines 4%. Keeping the new price because ARPPU “won” would optimize the wrong outcome.
Read ARPPU with at least:
- unique payers and payer conversion rate;
- total purchase revenue and net proceeds;
- refund and chargeback rate;
- repeat purchase or renewal rate;
- payer retention and overall retention;
- ARPU or ARPDAU for whole-audience monetization;
- cost per payer, ROAS, and cohort LTV for acquisition decisions.
How to improve ARPPU without shrinking revenue
The goal is durable revenue, not the largest isolated average. Treat ARPPU as one measure in an experiment scorecard.
1. Establish a reproducible baseline
Choose a fixed definition, currency, timezone, and comparison window. Break out platform, country, product, subscription plan, and acquisition cohort. Record both ARPPU and the guardrails above before changing anything.
Small payer samples create noisy averages. Add the actual payer count to every chart and avoid reacting to a daily spike caused by one large transaction.
2. Test prices instead of guessing
Price changes affect both average spend and willingness to buy. Test one clear hypothesis, define the primary outcome and guardrails before launch, and let the test gather enough data.
Google Play’s official price-experiment guidance recommends waiting for statistical significance and reports ARPPU beside buyer ratio, buyers, orders, and revenue. That wider result set helps distinguish a genuine monetization gain from a thinner payer base.
3. Build a useful value ladder
Offer clear steps between entry, standard, and premium value. For a game, that might mean consumable packs at distinct use moments. For a subscription app, it could mean monthly and annual options or tiers tied to real product benefits.
Watch for cannibalization: a new high-priced bundle may raise its own average order value while pulling buyers away from a more profitable offer. Evaluate the whole product set, not only the new SKU.
4. Earn the second purchase or renewal
Improving repeat behavior is often more durable than forcing a higher first transaction. Reduce failed checkouts, make entitlements reliable, communicate renewal terms clearly, and give paying users a reason to return before their next purchase or renewal.
Segment first-time, repeat, reactivated, and lapsing payers. Their spending patterns and product needs are different, and a blended ARPPU can hide the segment that actually changed.
5. Compare acquisition cohorts by payer quality
Campaign A may acquire more payers while Campaign B attracts fewer payers who spend more. Compare cost per payer, payer conversion, fixed-window cohort ARPPU, and LTV before reallocating budget.
Deeplinkly’s app attribution platform connects installs and downstream events to the campaign or deep link that drove them. Pair those attributed cohorts with verified purchase revenue so ARPPU becomes a campaign-quality diagnostic rather than a blended account average.
6. Keep an experiment scorecard
For each monetization test, record:
- hypothesis and affected audience;
- control and treatment dates;
- payer count and conversion;
- gross and net ARPPU;
- purchase revenue and proceeds;
- refunds, retention, and support signals;
- cohort maturity and statistical result;
- keep, iterate, or roll back decision.
This creates a decision trail and reduces the chance that seasonality, traffic mix, or a delayed renewal is mistaken for product impact.
Frequently asked questions
What does ARPPU stand for?
ARPPU stands for average revenue per paying user. It measures direct revenue generated per unique user who paid during a defined period.
What is the ARPPU formula?
Divide revenue from paying users in a period by the number of unique paying users in the same period. State whether revenue is gross or net and whether refunds, taxes, fees, and chargebacks are included.
What is a good ARPPU?
There is no universal good ARPPU. A useful target is based on comparable cohorts, products, platforms, countries, and time windows, and it improves total revenue or long-term value without damaging payer conversion or retention.
Does ARPPU include ad revenue?
Usually no. ARPPU is intended to isolate direct payments from payers, while ad revenue can come from non-paying users. Use ARPU or ARPDAU for a blended view that includes advertising.
Can ARPPU increase while total revenue falls?
Yes. If low-spending customers stop paying, the remaining payer group can have a higher average even while payer count and total revenue decline. Always review ARPPU with conversion, payer count, and total revenue.
How often should ARPPU be measured?
Monitor period ARPPU weekly or monthly for changes, depending on transaction volume. Use fixed and fully matured windows such as 30-day cohort ARPPU for comparisons across campaigns, releases, or acquisition months.
Conclusion: use ARPPU as a diagnostic, not a target
ARPPU tells you how effectively an app monetizes its paying users. It becomes decision-grade only when the revenue definition, unique-payer denominator, window, and cohort are consistent.
Start with one stable segment and calculate gross ARPPU, net ARPPU, payer conversion, and total revenue for the same period. Then test one pricing or packaging hypothesis and keep it only if the wider scorecard—not just the average—improves.