ARPU: How to Calculate and Interpret Average Revenue per User
ARPU compresses revenue and audience size into one comparable rate. The formula is simple, but the result is useful only when the revenue scope, user definition, reporting window, and currency stay consistent.
What ARPU means
Average revenue per user, or ARPU, is the revenue attributed to a defined user population during a period divided by the number of users in that same population and period. It answers a narrow question: how much revenue did the average included user generate during this measurement window?
ARPU is a rate, not a complete statement about profitability or user quality. It can rise because more users pay, payers spend more, ad monetization improves, low-value users leave, or the denominator was redefined. Teams need the underlying counts before deciding which explanation is true.
Numerator
Choose gross billings, recognized revenue, developer proceeds, or another documented revenue basis. Include refunds and platform fees consistently.
Denominator
Choose registered, subscribed, paying, active, or cohort users. Deduplicate them at the same reporting grain as the numerator.
Window
Fix the day, week, month, or cohort age. A monthly ARPU cannot be compared directly with a daily or lifetime value.
Google Analytics provides one concrete implementation: its ARPU metric uses total revenue, including purchase, subscription, and ad revenue less refunds, divided by active users. See the official Analytics dimensions and metrics reference. That definition is useful, but it is not permission to assume every dashboard uses the same revenue or user scope.
The ARPU formula and measurement contract
Core formula
ARPU = revenue in the period / users in the period
Write a measurement contract beside the formula. It should name the reporting timezone, currency and conversion rule, revenue sources, treatment of taxes, store fees and refunds, user identity, activity rule, period, and late-data policy. Without that contract, two correct calculations can produce numbers that should not be compared.
| Decision | Example choices | Why it changes ARPU |
|---|---|---|
| Revenue basis | Customer sales, recognized revenue, or developer proceeds | Taxes, platform commissions, deferred revenue, chargebacks, and refunds can sit on different sides of the numerator |
| Revenue streams | Purchases, subscriptions, advertising, commerce, or all included streams | An ad-supported app and an IAP-only report are not measuring the same monetization surface |
| User population | All registered users, active users, subscribers, or an acquisition cohort | A smaller denominator can lift ARPU even when total revenue does not change |
| Identity | Account, device, app instance, or analytics user ID | One person can appear as multiple devices or app instances, while shared accounts can hide multiple people |
| Time grain | Daily unique users, monthly unique users, or a fixed cohort age | The sum or average of daily ratios is not generally equal to one ratio calculated over unique monthly users |
Store reports deserve special care. Apple distinguishes customer sales from developer proceeds and defines paying users by Apple Account. Its usage data also covers users who agreed to share diagnostics and usage information. A ratio that mixes Apple sales, proceeds, active devices, and your own account-based users without a reconciliation step is not a stable ARPU.
Primary reference: Apple's sales metric definitions explain sales, proceeds, paying users, and refunds. The broader App Store Connect Analytics guide explains active-device coverage and proceeds per paying user.
A worked mobile app example
Suppose a mobile game reports $72,000 of purchase and subscription revenue after refunds, $18,000 of ad revenue, and 120,000 unique active users during one calendar month. Under that stated contract:
Revenue
$90,000
purchases plus advertising
Users
120,000
monthly unique active users
Monthly ARPU = $0.75 per active user
The result does not mean every user generated $0.75. Most users may have paid nothing, a small payer group may have generated most purchase revenue, and ad exposure may vary widely. Keep the numerator components and the distribution available alongside the average.
ARPU vs. ARPPU, ARPDAU, and LTV
Adjacent monetization metrics differ mainly by denominator and time horizon. Renaming one ratio does not make the underlying populations comparable.
| Metric | Typical denominator | Best question | Main trap |
|---|---|---|---|
| ARPU | All defined users in the period | How much period revenue is generated per included user? | The user and revenue definitions vary between companies and tools |
| ARPPU | Users who paid in the period | How much purchase revenue is generated per payer? | It hides payer conversion and usually excludes non-purchase revenue |
| ARPDAU | Daily active users | How much revenue is generated per active user per day? | Averaging daily ratios differs from period ARPU based on unique users |
| LTV | A cohort or modeled customer population | How much value is realized or expected across a customer lifetime? | Forecast assumptions, margins, retention, and horizon can dominate the estimate |
| MRR per subscriber | Active paid subscriptions | How much recurring subscription revenue exists per active subscription? | It excludes free users and may count subscriptions rather than people |
Google's AdMob glossary illustrates the period issue directly: ARPDAU uses daily active users, while a summary-period ARPU uses cumulative unique users across the selected date range. The two can differ even when they come from the same underlying activity. See the official AdMob metric glossary.
What makes ARPU move
Treat ARPU as the output of several systems. For a hybrid app, one diagnostic decomposition is purchase revenue per user plus ad revenue per user. Purchase revenue per user can then be examined through payer conversion, purchase frequency, price, refunds, and mix. Ad revenue per user depends on eligible activity, ad exposure, fill, format, geography, and realized price.
Monetization mix
A shift from ad-supported users toward subscribers can change total ARPU even if neither segment changes internally.
Audience mix
Countries, platforms, acquisition sources, lifecycle stages, and product versions can have different payer and ad economics.
Retention and activity
More retained users can expand future revenue, while a denominator surge from low-intent acquisition can temporarily lower period ARPU.
Price and offer design
Price changes, bundles, trials, promotions, and merchandising can affect conversion, spend, refunds, and retention in opposite directions.
For ad-supported apps, inspect the monetization path in the ad mediation guide rather than treating a higher ad load as a guaranteed ARPU gain. More impressions can change experience and retention, so revenue needs to be read with product outcomes.
How to interpret ARPU correctly
There is no universal good ARPU. A meaningful comparison holds the contract steady, compares similar products or cohorts, and connects the rate to acquisition cost, gross margin, retention, and the time required to recover spend.
Compare cohorts, not only calendar totals
Group users by acquisition date and inspect revenue at the same cohort age. This avoids giving older users more time to monetize.
Separate mix from within-segment change
Report ARPU by country, platform, channel, campaign, version, and monetization model, then show how each segment's share changed.
Show the denominator next to the rate
A rising ARPU with shrinking active users can coexist with falling total revenue. Rates, counts, and totals belong together.
Reconcile to finance
Analytics estimates and store reports may use different timing, currency, fees, taxes, refunds, and identity. Document any expected gap.
Averages can hide concentration
Two apps can report the same ARPU while one has broad, modest spending and the other depends on a small group of high spenders. Add payer conversion, ARPPU, revenue percentiles, ad viewer share, refund rate, and retention to understand the distribution and its durability.
When comparing campaigns, use a defined attribution model and the same maturity window. The attribution modeling guide explains why credit rules can move channel-level revenue without changing the company's total revenue. For acquisition planning, connect the result to the workflow in app promotion.
A practical ARPU workflow
Use the same sequence for a recurring report, a pricing change, or an acquisition review. The discipline matters more than adding another dashboard tile.
- 01
Write the contract
Define revenue, refunds, fees, currency, users, identity, timezone, window, and data-latency rules before querying data.
- 02
Reconcile inputs
Tie source revenue to store, ad-network, and finance totals at an agreed tolerance. Check missing events and duplicate identities.
- 03
Calculate totals and rates
Publish total revenue, included users, ARPU, payer conversion, ARPPU, ad revenue per user, and retention together.
- 04
Segment the movement
Decompose the change by platform, market, acquisition source, campaign, app version, lifecycle stage, and revenue stream.
- 05
Form one testable hypothesis
Choose the mechanism that best explains the movement, such as conversion, price, ad exposure, mix, or retention.
- 06
Measure the wider outcome
For a product or monetization experiment, predefine guardrails for retention, refunds, engagement, latency, and user experience.
Do not optimize the ratio in isolation
Removing low-spend users can increase ARPU while reducing total revenue and future growth. Raising prices can lift near-term revenue while worsening conversion or retention. Use ARPU as a diagnostic outcome inside a broader unit-economics decision.
ARPU FAQ
What does ARPU mean?
ARPU means average revenue per user. It divides the revenue attributed to a defined user population during a defined period by the number of users in that same population and period.
How do you calculate ARPU?
Divide revenue for the reporting period by the users included in that period. Before calculating, document whether revenue is gross or net, which revenue streams and refunds are included, what counts as a user, and whether users are deduplicated across the full period.
What is the difference between ARPU and ARPPU?
ARPU includes every user in the chosen denominator, including non-payers. ARPPU includes only users who paid during the period and usually includes purchase revenue rather than advertising revenue. When both use the same revenue scope and payers are a subset of users, ARPPU is higher, but the two metrics answer different questions.
Is ARPU the same as ARPDAU?
No. ARPDAU is revenue per daily active user and is calculated at a daily grain. A period ARPU often uses unique active users across the entire selected range. Averaging daily ARPDAU values can produce a different result from dividing period revenue by period-level unique users.
What is a good ARPU?
There is no universal good ARPU. A useful target depends on the product, market, platform, revenue scope, user definition, acquisition cost, retention, margins, and measurement window. Compare like-for-like cohorts and evaluate whether unit economics improve without harming retention or user experience.