ARPU: How to Calculate Average Revenue Per User

ARPU (average revenue per user) is total revenue divided by the number of users in the same period. That is the whole calculation: take revenue booked in a month, divide it by the users active in that month. Most disagreements about ARPU come from what counts as revenue and who counts as a user, not from the division.

The figure is a ratio, not a goal in itself. It tells you what an average user is worth over a defined window, which lets you compare cohorts, channels and pricing changes on one number. It says nothing about whether that revenue is profitable.

The ARPU formula and what goes in each part

The basic formula is revenue divided by users, but each side needs a definition you write down before you compute anything.

On the revenue side, use the money your business actually keeps from users: store payouts after platform commission, minus refunds and chargebacks, plus ad revenue net of the ad network's share. Gross bookings overstate ARPU, sometimes by 30% or more, depending on the platform cut.

On the user side, pick one base and keep it fixed:

• DAU for daily ARPU, useful for spotting short-term shifts in spending or ad yield.
• MAU for monthly ARPU, the standard for reporting and for comparing games with different session patterns.
• New users in a cohort for cohort ARPU, which tracks whether recent installs monetize better or worse than older ones.

The denominator has to match the revenue window. Monthly revenue over daily active users produces a number with no meaning.

Step-by-step: calculating ARPU for a game or app

1. Set the period. Calendar month is the common choice. Keep it consistent so month-over-month figures are comparable.
2. Pull net revenue. Export the payout report from each store and ad network, then subtract refunds. If you have in-app purchases and ads, sum both.
3. Count unique users. Count distinct user IDs active at least once in the period, not sessions and not installs.
4. Divide and record the inputs. Write the period, the revenue figure and the user count next to the result, so anyone can audit it later.
5. Segment before you conclude. Recompute by platform, country and acquisition channel. A single blended ARPU hides large gaps.

Keep the raw exports. If a store revises a payout or a chargeback lands late, you will want to restate the figure rather than guess.

How ARPU relates to ARPPU and conversion

ARPU averages over everyone, including the majority who never pay. ARPPU (average revenue per paying user) divides revenue by payers only. The bridge between them is the payer conversion rate.

ARPU roughly equals ARPPU multiplied by the share of users who pay. If 2% of users pay and those payers spend $10 on average, ARPU is about $0.20. This matters for diagnosis: a falling ARPU can come from lower conversion, lower payer spend, or more free users entering the base. Only the ARPPU and conversion split tells you which.

Ad-supported apps need a variant. Ad ARPU is ad revenue divided by active users, often called ARPDAU when measured daily. Report it separately from purchase ARPU so you can see which stream is moving.

Worked example with illustrative numbers

These figures are made up to show the mechanics.

Divide $36,000 by 180,000 and monthly ARPU is $0.20. If 3,600 of those users paid, conversion is 2% and ARPPU is $10 before ads. Now split by platform: suppose iOS users generate $0.35 and Android users $0.12. The blended $0.20 is accurate but useless for decisions, because the two audiences need different pricing and ad load.

Mistakes that make ARPU misleading

Mixing gross and net. Teams often compare their net ARPU against industry benchmarks quoted on a gross basis. The result looks like underperformance when the gap is just commission.

Changing the user base mid-series. Switching from MAU to DAU in month three breaks the trend line. Pick one and annotate any change.

Treating installs as users. Installs include people who opened the app once and left. They dilute ARPU and make engagement look healthier than it is.

Counting revenue in the wrong month. Recognize purchases when they are booked, not when the store pays out, and apply the same rule to every period.

Reporting a single global number. An app live in several markets with different price tiers needs a per-market view, or pricing decisions will be made on an average that no user actually experiences.

One more: ARPU can rise while the business shrinks. If free users leave faster than revenue falls, the ratio improves. Always pair ARPU with absolute revenue and user counts.

Using ARPU alongside LTV and CAC

ARPU is an input to lifetime value, not a substitute for it. A simple LTV estimate multiplies daily ARPU by average days retained, or monthly ARPU by average lifetime in months. That estimate assumes retention and monetization stay flat, which they rarely do, so treat it as a ceiling rather than a forecast.

Compare LTV against customer acquisition cost. If LTV is three times CAC, paid acquisition has room; if it is barely above CAC, a price or retention problem needs fixing before you spend more. ARPU feeds this because it sits inside LTV, so an error there propagates.

For payment-side planning, remember that store payout timing affects cash flow but not ARPU, as long as you recognize revenue consistently. For tax treatment of that revenue, rules differ by country and by how you operate. General information, not financial, legal or tax advice.

Practical takeaway: a repeatable ARPU routine

Define net revenue and your user base in writing, compute ARPU monthly from the same exports, and segment by platform, market and channel before drawing conclusions. Track ARPPU and conversion next to it so you can tell which lever moved. When the number changes, check absolute revenue and user counts before celebrating or panicking, because a ratio can improve while the business gets smaller.