Revenue over a period divided by active users. Not to be confused with ARPPU, per paying user, which can be twenty times higher.
In practice
The confusion to clear before anything else is with ARPPU, average revenue per **paying** user. On a freemium product the two can differ twenty-five fold — €0.80 and €20 in the same month — and both get called "ARPU", in different decks, in the same week. Which one is right depends on the decision: ARPU for judging acquisition spend, since you pay for sign-ups and only some convert; ARPPU for judging a price change, which free users are unaffected by. The second thing to know is that a rising ARPU is not a win in itself: lose your smallest users and the average of those remaining climbs without a euro being added. It is the same mechanical trap as the DAU/MAU ratio, and it has the same cure — publish the denominator beside it.
The formula
ARPU = (revenue over a period) ÷ (average active users over that period) — and ARPPU = the same revenue ÷ PAYING users only
- Revenue
Decide once whether this is recurring revenue only or everything, and never switch. Mixing a one-off setup fee into one month makes that month's ARPU a spike nobody can explain a quarter later.
- Users
Active users, not registered ones. Dividing by everyone who ever created an account produces a number that falls every month by construction, and says nothing about anything.
- Which of the two
ARPU answers "what is a new sign-up worth", which is what you compare acquisition spend against. ARPPU answers "what is a customer worth", which is what you compare a price change against. Both get called ARPU, in different decks, on the same week.
ARPU is a rate, LTV is a total: LTV ≈ ARPU × gross margin × average lifetime. A customer at €50 a month with an 80% margin who stays 33 months is worth about €1,320 — a total built from exactly this rate.
Worked example
Two numbers, twenty-five times apart
- A freemium tool: 100,000 active users, 4,000 of whom pay. Monthly revenue: €80,000.
- ARPU = 80,000 ÷ 100,000 = €0.80. ARPPU = 80,000 ÷ 4,000 = €20. Same month, same revenue, and a factor of twenty-five between the two.
- Now lift conversion from 4% to 5% without touching the price: 5,000 payers × €20 = €100,000. ARPU goes from €0.80 to €1.00, up 25%. ARPPU has not moved at all.
- Raise the price by 25% instead, with conversion unchanged: ARPPU goes to €25 and ARPU to €1.00 as well. Two completely different projects, identical in one number and distinguishable only by the other.
Quoting one of them without saying which is how a conversion win and a price rise end up reported as the same result. Say which, every time, and put the user count next to it.
Orders of magnitude
- ARPU varies by three orders of magnitude across categories — cents a month for a consumer app, thousands for enterprise software — so a cross-company comparison compares business models rather than performance. There is no useful table here.
- The comparison that means something is your own trend, decomposed. An ARPU up 10% can be a price rise, a conversion win, or simply a mix shift toward larger customers — three different results reported by one number, and only the decomposition tells them apart.
- A rising ARPU on a falling user count is usually small users churning, not a win. It is the same mechanical trap as the DAU/MAU ratio, and it is why neither is ever quoted without the denominator beside it.
How to improve it
- Say which of the two you mean, in the label, every time. "ARPU (paying)" costs one word and settles most of the arguments this metric causes.
- Decompose every movement into price, mix and conversion before reporting it. A number that moved for three reasons at once is not a result yet.
- Segment it. A blended ARPU over a base that contains both a €9 plan and a €900 plan describes neither, and the segment-level numbers are the ones a pricing decision actually needs.
- Publish it next to the active user count, always — the pair is what makes a rise readable as growth rather than as attrition.
In the Tour
Do you know your LTV, even roughly?
- Yes, a solid estimate20 pts
- A very rough guess7 pts
- No idea0 pts
The Tour asks whether you know your LTV, even roughly — 20 points for yes, 7 for an order of magnitude, 0 for no. ARPU is the first of the three inputs, and the easiest: most teams who cannot answer the LTV question could compute their ARPU this afternoon, because the revenue and the user count are both already in a dashboard. What is usually missing is the average lifetime, which needs a churn rate — which is why the 0-point answer here so often travels with a 0 on the retention questions.
Questions people ask
ARPU or ARPPU — which should I use?
Whichever matches the decision. Judging acquisition spend needs ARPU, because you pay to acquire sign-ups and only some of them convert. Judging a price change needs ARPPU, because free users are not affected by it. Using the wrong one makes a freemium product look either unaffordable to acquire or implausibly lucrative.
What is the difference with LTV?
ARPU is per period, LTV is over a lifetime: multiply ARPU by gross margin and by the average number of periods a customer stays. That makes ARPU the reliable half of the pair — it is measured, while the lifetime is projected, and the projection is where most LTV disagreements actually live.
Does a rising ARPU mean the business is growing?
Not on its own. Lose your smallest users and the average of those remaining rises without a single euro being added. Read it with the active user count and with total revenue: growth is all three moving the right way, and ARPU alone can move the right way while the other two do not.
Monthly or annual?
Monthly for steering, and stated as such. Where contracts are annual, the monthly equivalent is the comparable figure, and mixing an annual ARPU into a monthly series produces a twelve-fold step that reads like a spectacular quarter.