What Is ARPPU? Formula, ARPU Comparison, and Paying-User Analysis
Published:
Last Updated:
Category: Marketing Glossary, Marketing Budget & KPI
Authors: Shusaku Yosa
ARPPU is average revenue per paying user: defined payer revenue divided by unique paying users in the same period. Count people rather than transactions, align the revenue scope and dates, and report payer counts alongside the average. A higher ARPPU does not by itself prove higher total revenue or profit.
Define both payer revenue and a paying user
ARPPU stands for Average Revenue Per Paying User. It is useful for analyzing purchases in apps and other paid products. Someone making three purchases during a month is still one monthly paying user. Dividing by purchase count instead produces average transaction value.
AppsFlyer's ARPPU explanation distinguishes paying users and advertising revenue when comparing ARPPU with ARPU. This guide focuses on app purchase revenue. Do not silently replace that numerator with all revenue, cash receipts, or profit.
Definition | Example | Different measure |
|---|---|---|
Revenue scope | Purchase revenue after the agreed tax and refund adjustments | Advertising revenue, cash, or profit |
Paying user | A unique user with a qualifying valid purchase in the period | Transactions, free trials, or all users |
Period | One calendar month in the agreed time zone | A rolling window or cumulative cohort lifetime |
Deduplication | One count per defined user ID | Devices, logins, or payment methods |
Document how fully refunded buyers and refunds posted in a later month are treated. If there are no paying users, ARPPU is undefined. Report that condition with revenue and payer counts rather than converting it into an ordinary zero-revenue-per-payer result.
A purchase this month is different from an active paid subscription
An annual subscriber may have an active paid contract without making a payment this month. An MRR-based measure needs a corresponding subscriber population, not just buyers who transacted during the month.
Stripe Billing calls MRR divided by active subscribers ARPU. Therefore, ARPU does not universally include free users. Check the actual definition using ARPU, ARPPU, and ARPA comparisons before comparing app and SaaS dashboards.
When paying rate multiplied by ARPPU equals ARPU
Take a fictional app with 1,000 active users in one month. Of these, 200 are payers. Purchase revenue is ¥400,000 and advertising revenue is ¥100,000. Payers are a subset of the active-user population, and all figures use the same month and user definition.
Metric | Calculation | Result |
|---|---|---|
Purchase ARPPU | ¥400,000 ÷ 200 | ¥2,000 |
Paying rate | 200 ÷ 1,000 | 20% |
Purchase-only ARPU | ¥400,000 ÷ 1,000 | ¥400 |
ARPU including advertising | ¥500,000 ÷ 1,000 | ¥500 |
¥2,000 multiplied by 0.20 equals ¥400, matching purchase-only ARPU. It does not equal the ¥500 all-revenue ARPU. Under matching definitions, active users × paying rate × ARPPU equals purchase revenue; advertising revenue must be added separately.
This is an accounting identity between aligned metrics, not a causal forecast. A price change can affect payer counts as well as spending. For the distinction between revenue, cash, and profit, see revenue and cost-scope fundamentals.
A higher ARPPU can accompany lower revenue
The following is another fictional comparison. Active users remain at 1,000 in both months, but the payer population changes. Advertising revenue is excluded.
Measure | Before | After |
|---|---|---|
Paying users | 200 | 150 |
Purchase revenue | ¥400,000 | ¥330,000 |
ARPPU | ¥2,000 | ¥2,200 |
Paying rate | 20% | 15% |
ARPPU rises by 10%, while purchase revenue falls by 17.5%. Losing lower-spending payers can raise the average without demonstrating successful upselling. Separate new, continuing, and returning payers to determine whether spending changed within comparable groups. Pair the analysis with customer and revenue churn.
Inspect the payer distribution before choosing an action
A single average hides concentration. Break payers down by plan, spending band, acquisition cohort, and tenure. Report payer count, revenue, ARPPU, median spending, and the revenue share contributed by the highest-spending group. Make sure the segments do not overlap unintentionally.
- For lower spending among new payers, inspect introductory discounts, entry plans, and pricing clarity.
- For declining ARPPU among continuing payers, separate lower usage, downgrades, and refunds.
- For heavy concentration, assess the exposure if a few payers leave and the costs of serving them.
- When revenue and ARPPU rise, check delivery costs, support burden, retention, and customer satisfaction.
Spending is not a complete measure of customer quality. Evaluate whether an offer provides useful value at an appropriate price, rather than treating greater spending as the only objective.
Keep a monthly calculation checklist
- Record the purchase-revenue scope and treatment of taxes, refunds, and fees.
- Define a qualifying payer and verify user-ID deduplication.
- Calculate from revenue and payers in the same period; handle zero payers separately.
- Align the active-user population and revenue scope used in the paying-rate identity.
- Compare new, continuing, and returning groups alongside total revenue and costs.
Do not average daily ARPPU values to obtain monthly ARPPU. Deduplicate repeat purchasers across the month and recalculate from monthly revenue. When testing an improvement, define eligibility, duration, and cost first. Xtrategy's project and budget-versus-actual management features can help organize owners, plans, and implementation costs.
