Quick definition: Average revenue per user (ARPU) is revenue earned during a stated period divided by a clearly defined user population for that same period.
What is ARPU?
ARPU connects monetization to people rather than to orders. It asks how much revenue the average member of a defined population generated, including people who generated no revenue. That makes it a useful compact measure for subscriptions, apps, media, marketplaces, and freemium products where purchase conversion and purchase amount both matter.
The abbreviation is deceptively broad. “User” can mean everyone assigned to an experiment, registered users, monthly active users, customers eligible to pay, or paying users. Revenue per paying user is often called ARPPU and is a different metric: it removes non-payers from the denominator. Neither is intrinsically better, but they answer different questions. Always put the population and time period in the metric name, such as “30-day net revenue per assigned eligible user.”
ARPU is also distinct from average order value. AOV divides by orders; ARPU divides by users. One person can place many orders or none at all, so the two metrics can move in opposite directions.
ARPU formula and denominator choices
The core formula is:
ARPU = recognized or collected revenue in period / unique users in the defined population
For an experiment, the most decision-safe denominator is often every eligible unit assigned to each variant, including non-purchasers. This is an intent-to-treat measure: it reflects the revenue impact of offering the experience, not just the behavior of people who later paid. Do not condition the denominator on a post-exposure outcome such as “users who viewed the paywall,” because the treatment may change who reaches it.
| Metric name | Denominator | Question answered |
|---|---|---|
| Revenue per assigned user | All randomized eligible users | What is the incremental monetization effect of the variant? |
| Monthly ARPU | Monthly active users | How effectively is the active audience monetized? |
| Revenue per registered user | Registered users | How much revenue does the owned base generate? |
| ARPPU | Paying users only | How much does the typical payer spend? |
Choose recognized revenue, cash collected, gross revenue, or net revenue based on the business question. Subscription businesses may use recognized revenue for financial reporting and cash collected for payment operations. Product experiments often need net revenue after discounts, refunds, credits, and payment failures. State the currency conversion method and handling of taxes and one-time fees.
ARPU in A/B testing
ARPU is a valuable primary outcome for pricing, paywall, ad-load, checkout, subscription, and feature-access tests because it incorporates conversion and spending. A paywall can produce a higher ARPPU by losing low-spending buyers; revenue per assigned user reveals whether the business gained money across all exposed users. It can likewise identify a small conversion decline that is outweighed by a larger increase in purchase value.
Revenue has a heavy-tailed distribution. Most users may contribute zero, while a handful generate large purchases. The arithmetic mean remains meaningful for total revenue forecasting, but its uncertainty may be wide and sensitive to outliers. Report raw totals, user counts, mean difference, and a confidence interval. Pre-specify any winsorization, log transform, or robust analysis; never introduce a transformation only after seeing an unwelcome result. More detail is available in the revenue-metric transformation guide.
ARPU is rarely sufficient on its own. Price increases can lift short-run revenue while increasing churn, refunds, chargebacks, support demand, or complaints. Monitor those as guardrails and, where feasible, retain a holdout long enough to measure retention and renewal. Read how to set A/B test duration before concluding from a metric that needs maturation.
Worked ARPU calculation
A streaming service tests a new annual-plan offer among 15,000 trial-eligible users per arm. During a 30-day observation period, control collects $21,000 net of refunds; treatment collects $24,750 net of refunds.
control ARPU = $21,000 / 15,000 = $1.40treatment ARPU = $24,750 / 15,000 = $1.65difference = $1.65 - $1.40 = +$0.25 per assigned user
At 200,000 comparable eligible users per month, the point estimate implies $50,000 additional first-30-day revenue. The team then decomposes it: treatment conversion rose from 3.0% to 3.2%, while revenue per payer increased because more buyers selected the annual plan. That is promising, but annual plans may create more refunds or change renewal patterns. The rollout decision should use the estimate’s interval and longer-term retention rather than extrapolating the point estimate as guaranteed cash.
Data-quality caveats
The numerator and denominator commonly arrive from different systems: billing records, app analytics, ad networks, and identity services. Join revenue to the assigned identity using a stable key and account for delayed payment settlement, refunds, subscription upgrades, and currency conversion. If one user can have multiple accounts, decide whether the analysis unit is the person, account, household, or workspace before aggregation.
Be alert to revenue leakage in tracking. Client-side purchase events can be blocked, duplicated after refresh, or triggered on failed payments. Prefer reconciled server-side transaction records for the primary numerator. Reconcile experiment exposure totals to the eligible population; an implausible zero-revenue share or sudden numerator jump may be an instrumentation issue, not a product effect.
Seasonality and acquisition mix also matter. A treatment allocated more users from a high-value country or campaign can show higher ARPU without a causal product effect. Randomization reduces this risk, but verify balance and investigate implementation changes before publishing a result.
Practical guidance
- Name the metric completely: revenue definition, user population, unit, and window.
- For experiments, calculate revenue per assigned eligible user and retain payer-level diagnostics separately.
- Predefine treatment of refunds, credits, taxes, trials, and currency conversions.
- Show total revenue, number of users, conversion, revenue per payer, and ARPU together so the mechanism is clear.
- Use retention, refund, margin, and customer-experience guardrails before changing price or access.
Common mistakes
- Leaving “user” undefined: active, registered, assigned, and paying populations are not interchangeable.
- Calling ARPPU ARPU: removing zero-revenue users makes the result look larger and answers another question.
- Analyzing only purchasers: this conditions on a behavior the variant may change.
- Ignoring extreme values: inspect outliers and intervals rather than trusting a point estimate alone.
- Using immature revenue: early collections can reverse after refunds and churn.
Frequently asked questions
Is ARPU calculated monthly or annually?
Either, as long as the period is explicit. Monthly ARPU supports operating monitoring; annual or cohort ARPU can suit subscriptions and lifecycle analysis.
What is the difference between ARPU and ARPPU?
ARPU includes non-paying users in the denominator. ARPPU includes only payers and measures spend conditional on payment.
Should an A/B test use gross or net ARPU?
Use the version tied to the decision. Net revenue after material refunds and credits is often safer for rollout decisions; label a gross early read as provisional.
Can ARPU be negative?
Yes. If refunds, credits, or chargebacks exceed revenue for the population and period, net ARPU is negative.
Why report conversion with ARPU?
ARPU alone does not reveal whether a change came from more payers, higher payer spend, or both. Conversion explains the mechanism.
Summary
ARPU measures revenue across a defined user population, including non-payers. Its usefulness depends on a precise denominator, a reconciled revenue definition, and a stated observation window. In A/B tests, revenue per assigned user captures the total monetization effect, but decisions should also consider uncertainty, refunds, retention, margin, and customer harm.
Sources
- U.S. Securities and Exchange Commission: Annual-report filing example
- Recurly: SaaS metrics guide
- NIST: What are confidence intervals?