ARPU explained simply

Why ARPU matters

ARPU (Average Revenue Per User) is one of the load-bearing metrics of any product with monetization. Multiply it by users and you get total revenue. Combine it with churn and you get LTV. It shows up on every investor deck, every growth review, and roughly 80% of junior-to-mid product analyst interviews at companies like Stripe, Notion, and DoorDash. If you can't define it in one sentence and compute it in five lines of SQL, the screen is over.

The most common trap is the one that makes recruiters cringe: ARPU is computed over all users — including the ones who pay nothing. ARPPU, the close cousin, is computed only over paying users. Mix them up and your number is off by 10-50x. On the job, that mistake leads to a worse decision: a rising ARPU might mean more people are paying (genuinely good) or it might mean the existing payers were nudged into a higher tier (defensible but not the same thing). Conflating the two hides which lever is actually moving.

This post is a complete reference: the formula, a worked example, ARPPU contrast, benchmark ranges by product type, the SQL snippet, and the pitfalls interviewers love to set up. No formulas before the intro is over, no fluff after it.

The formula and a worked example

The definition is simple:

ARPU = Total Revenue / Total Users

"Average revenue per user" — averaged over everyone in the denominator, paying or not. The denominator choice is where most reasoning errors hide, so we'll come back to it twice.

Worked example. You run a freemium app with 100,000 monthly active users, and 5% of them pay $12/month for the Pro plan. The rest pay zero.

• Revenue: 5,000 paying users × $12 = $60,000/month
• Total users in the denominator: 100,000
• ARPU: $0.60 per user per month
• ARPPU: $12.00 per paying user per month

The gap between $0.60 and $12 is a factor of 20 — exactly the inverse of the 5% paying conversion rate. That is not a coincidence; it is the algebra:

ARPU = ARPPU × (paying users / total users)
ARPU = ARPPU × paying conversion rate

A nuance worth flagging: the denominator should match the question. For growth reports, monthly active users is usually fine. For unit economics versus CAC, the denominator is normally the cohort of acquired users in that period — not the total active base.

ARPU vs ARPPU

The two metrics answer different questions and deserve different reviews.

ARPU answers: how good is our monetization across the entire user base. It moves when conversion to paid moves, when free-tier users churn at different rates, or when pricing changes for new payers. It is the right number to compare to CAC for blended unit economics, and the right number on the investor deck.

ARPPU answers: how much does a payer pay us. It moves when you ship a higher tier, raise prices, push annual plans, or get expansion seats in B2B. It is the right number for pricing experiments and packaging work. If ARPPU rises while ARPU stays flat, you are extracting more from existing payers without growing the paying base — sometimes intentional, sometimes a leak.

Benchmarks by segment

Treat these as order-of-magnitude anchors, not industry truth. Real numbers vary heavily with geography, tier mix, and how aggressively a free plan is gated.

ARPU and LTV

For a subscription business with a stable churn rate, the back-of-envelope LTV is:

LTV = ARPU / churn_rate

A worked example. ARPU is $25/month, monthly churn is 5%. Then LTV is $25 / 0.05 = $500 per user. If you can lift ARPU 10% via upsell while holding churn constant, LTV also rises 10% to $550. That is why ARPU is treated as a growth lever, not just a reporting metric — the leverage is linear and compounds with retention.

The formula has two assumptions that bite. First, churn must be stable; cohorts with declining churn over time will have a much higher real LTV than this calculation suggests, and a contractual LTV model (Kaplan-Meier or a geometric series with declining hazard) is needed. Second, ARPU here means ARPU of a paying-equivalent unit — for B2C freemium, you usually want ARPPU × paying probability, not raw ARPU mashed into the denominator.

How to compute ARPU in SQL

The vanilla query is short:

SELECT
  DATE_TRUNC('month', period_start) AS month,
  SUM(revenue) / NULLIF(COUNT(DISTINCT user_id), 0) AS arpu
FROM monthly_user_revenue
GROUP BY 1
ORDER BY 1;

Two details earn the points. NULLIF(..., 0) guards against zero-user months in newly launched products. COUNT(DISTINCT user_id) matters when a user contributes multiple revenue rows in a month — without DISTINCT, ARPU is silently understated because the denominator is inflated.

If you want ARPU by acquisition cohort — the version a growth PM actually cares about — you join in the acquisition month:

WITH user_cohort AS (
  SELECT user_id, DATE_TRUNC('month', signup_at) AS cohort_month
  FROM users
),
cohort_revenue AS (
  SELECT
    uc.cohort_month,
    DATE_TRUNC('month', mur.period_start) AS revenue_month,
    SUM(mur.revenue) AS revenue,
    COUNT(DISTINCT uc.user_id) AS users
  FROM user_cohort uc
  LEFT JOIN monthly_user_revenue mur USING (user_id)
  GROUP BY 1, 2
)
SELECT
  cohort_month,
  revenue_month,
  revenue / NULLIF(users, 0) AS arpu
FROM cohort_revenue
ORDER BY cohort_month, revenue_month;

The LEFT JOIN is the difference between an honest cohort ARPU and an inflated one. If a cohort member earned zero revenue, you still want them in the denominator. An INNER JOIN here silently drops non-paying users and turns ARPU into ARPPU.

How to lift ARPU

There are five clean levers. Each lifts a different sub-component of ARPPU × paying conversion, so naming the lever matters when you propose the work.

Upsell — push existing payers to a higher tier. Lifts ARPPU. Lowest risk, but ceiling is set by your tier ladder. Cross-sell — sell adjacent products to existing customers (e.g. Notion AI on top of Notion). Lifts ARPPU and, if priced well, raises retention. Expansion in B2B — more seats, more usage, larger storage. Lifts ARPPU; in NDR-driven businesses this is usually the biggest contributor. Tightening the free tier — gate features behind paid plans. Lifts paying conversion but risks free-user growth and brand goodwill if done too aggressively. Premium feature shipping — new paid-only capabilities that justify a higher tier. Lifts both ARPPU and conversion if the feature is genuinely differentiated.

If you want to drill metric definitions, formula gotchas, and SQL questions like these every day, NAILDD ships 500+ analytics interview problems built around exactly these patterns.

Common pitfalls

The first pitfall is conflating ARPU and ARPPU. The two metrics differ by a factor of 1 / paying conversion, which for most consumer apps is 10x-50x. Candidates who quote a single number for "ARPU" without clarifying the denominator lose the question. Always state explicitly: "ARPU over all monthly active users" or "ARPPU over paying subscribers."

The second pitfall is reporting ARPU without accounting for gross margin. ARPU is a top-line metric — for unit economics versus CAC, you want contribution-margin ARPU, which subtracts variable costs (hosting, payment processing, content licensing). A streaming service with ARPU of $12 and 30% gross margin produces $3.60 of contribution per user per month, not $12. Skipping this step is how teams end up with LTV/CAC ratios that look healthy and a business that loses money.

The third pitfall is averaging across segments that should be split. Enterprise customers can have ARPU 100x higher than SMB. Mobile-only users behave nothing like desktop. International users in price-discriminated regions can pay 60% less than the home market. Reporting a single blended ARPU hides where the leverage is. Always cut by segment first; report the blended number second with the cuts attached.

The fourth pitfall is using a lifetime ARPU rather than a periodic one. As a company grows, the user base changes, pricing changes, mix changes. An "ARPU since inception" number is dominated by historical artifacts and is useless for forecasting. Use monthly or quarterly ARPU and look at the trend. Plot it with cohort breakdowns and the picture sharpens fast.

The fifth pitfall is picking the wrong denominator — usually monthly active users when the question wanted all registered users, or vice versa. The MAU denominator gives the higher number (smaller denominator), which feels good on a slide but answers a different question. Decide upfront: are you measuring monetization of active users, of the whole base, or of acquired cohorts? Then never mix the three in one chart.

Related reading

• How to calculate ARPU in SQL
• How to calculate ARPPU in SQL
• Churn explained simply
• CAC explained simply
• Product metrics: DAU, MAU, ARPU, LTV explained
• SQL window functions interview questions

FAQ

Which is asked more often in interviews — ARPU or ARPPU?

ARPU shows up more often because it sits closer to top-line revenue and is the number on the investor deck. But mid-level and senior product analyst interviews almost always test the contrast: they ask for ARPU first, then push on "what if I cared about just the payers?" to force the ARPPU definition. Knowing both, with the algebraic link ARPU = ARPPU × paying conversion, is what separates a confident answer from a memorized one.

Should ARPU be reported in local currency or normalized to USD?

Both, depending on audience. Internally, report ARPU in each market's local currency to avoid noise from FX moves masquerading as monetization changes. For executive and investor reports, normalize to USD using a fixed rate (often the start-of-year rate) so cross-region comparisons stay clean. Mixing the two on one chart causes month-over-month interpretation to break.

ARPU is up but total revenue is down — how can that happen?

The user base shrunk faster than ARPU rose. If you lost 20% of users but ARPU went up 10%, total revenue is 88% of the previous period. This is a common pattern after a pricing increase that pushes price-sensitive users out: average revenue per remaining user looks healthy, but the absolute revenue is shrinking. The fix is to always pair ARPU with the user count and to look at revenue retention by cohort.

Should I compute ARPU monthly or quarterly?

Monthly is the default for SaaS, mobile apps, and most subscription products — the cadence matches billing and shows changes fast. Quarterly is more common for B2B with annual contracts, where monthly numbers are noisy from contract renewal timing. Retail and e-commerce often use monthly with a 13-week trailing variant to smooth seasonality. Match the cadence to the natural cycle of the business, not to whatever Excel defaults to.

How does ARPU change with annual versus monthly billing mix?

A shift toward annual billing usually raises ARPU on a billed-basis (the user pays 12 months upfront) but the ARPU on a normalized monthly basis stays roughly flat or drops slightly, because annual plans are often sold at a 15-20% discount. Always report ARPU normalized to a monthly equivalent — divide annual revenue by 12 and add it to the monthly bucket. Otherwise December looks like a hero month every year purely from annual renewals.

Is ARPU still useful when most users are on a free tier?

Yes, but its sensitivity changes. With a 1% paying conversion, ARPU equals ARPPU divided by 100, so most of the variance comes from conversion, not from price. In that regime, a 10% lift in paying conversion is worth roughly a 10% lift in ARPU — much more than a 10% pricing change applied only to that 1%. Use ARPU as the headline number, but instrument paying conversion and ARPPU separately so you know which lever the team should pull.