All Things ARPU (and Why Most Teams Use It Wrong) - Issue 303
When to use ARPU, when to avoid it, and how it quietly breaks A/B tests and profitability assumptions
Welcome to the Data Analysis Journal, a weekly newsletter about data science and analytics.
Today’s issue is all about ARPU - what it’s good for, where it fails, and how people often misuse it.
ARPU shows up everywhere - in experiments, forecasting, and profitability estimations, and it’s easy to treat it as a simple, universal metric. But when I point out problems with ARPU, it often doesn’t go over well, especially with growth marketing. People trust ARPU more than they should. So I’m putting everything an analyst needs to know about ARPU in one place, so we can link to it instead of arguing about it every time..
If your team uses ARPU to judge experiment impact or estimate profitability, consider sharing this. The goal isn’t to force anyone to change how they work, but it’s to make the tradeoffs clear and keep ARPU from being used as the one answer for every decision.
Why do we need ARPU?
ARPU is a finance metric that gives a high-level view of revenue by combining 3 things into one number: (1) revenue, (2) number of customers, and (3) the average value per customer:
Most tools and providers use the same basic definition:
Stripe: What is average revenue per user? Why it matters and how to calculate it
Appsflyer: Average revenue per user (ARPU)
Chargebee: What is Average Revenue Per User?
Amplitude: What Is Average Revenue Per Customer (ARPU)? How To Calculate It
RevenueCat: Realized LTV per Customer Chart (being different, huh)
Appnomix: A Guide to ARPU: The App World’s Most Underrated Revenue Metric
All of them say the same thing:
The problem is that in real life, it’s rarely that simple. There are many valid versions of ARPU depending on choices like:
What is the “time period”? (day, week, month, cohort window, billing cycle?)
Which dates define revenue? (purchase date, recognition date, refund date, renewal date?)
Which dates define users? (signup date, trial start, conversion date, renewal date?)
What counts as “revenue”? (gross vs net, refunds, chargebacks, taxes, discounts, promos, upgrades? See why not all revenue is created equal.)
Who counts as a “user”? (all users, trials, paid users, refunded, discounted users?)
So the “standard” ARPU formula usually hides a lot of decisions. Picking the right version for your product is hard, and it should be defined with finance, not invented separately by marketing or product.
The irony, though, is that marketing and product teams often rely on ARPU more than finance does. Finance usually has better revenue metrics already. ARPU becomes a shortcut metric for teams that need a single number to track performance.
That’s why, over the last decade, every payment, analytics, and growth tool built “default ARPU” calculations so non-finance teams could measure it without deep modeling.
That part is helpful, but it created a new problem: people started using ARPU for everything - onboarding tests, paywall tests, forecasting, growth projections, retention, prioritization, even LTV, often without understanding what ARPU is actually measuring.
And ARPU is easy to game by accident. Averages can go up when the denominator goes down. If an experiment reduces the number of paying customers but keeps a few high spenders, ARPU can rise even while total revenue falls. That means an “ARPU lift” doesn’t automatically mean the experiment was good.
I saw this firsthand at MAU, mobile app AdTech and MarTech conference in Vegas last year: a well-known growth consultant opened with a claim like “I’ve run 3,670+ monetization experiments, each with 60%+ lift in ARPU”. But if you understand the math, that statement is a big red flag: either many of those tests hurt volume, or the metric was being used in a misleading way. In other words, he was effectively saying that either he ran 3K failed revenue tests, or he has no clue what he is talking about.
To summarize, ARPU is worth tracking, but it’s increasingly overused and overtrusted. It’s not a one-size-fits-all decision metric, and it can point you in the wrong direction if you don’t define it carefully.
