For a while I looked at "average order value" and called it my per-user revenue. It felt close enough. It wasn't — because AOV is per order, not per person, and it hides the fact that most of my users weren't buying at all.
The metric that fixed my thinking was ARPU. This post covers what ARPU actually is, how it differs from ARPPU, and why the denominator matters more than people think.
TL;DR
- ARPU = revenue ÷ all users. Non-buyers count. That's the whole point
- ARPPU = revenue ÷ paying users only. Always higher than ARPU because the denominator is smaller
- ARPU = CVR × ARPPU — so when ARPU is low, you can tell whether it's a conversion problem or a spend-per-buyer problem
- Use ARPU for channel investment decisions, ARPPU for unit economics
- ARPU benchmarks vary wildly by business type — compare within your quadrant, not across industries
1. What ARPU actually is
ARPU (Average Revenue Per User) divides revenue by total users in a period:
ARPU = Revenue ÷ Total Users
¥3M monthly revenue, 1,000 users → ARPU is ¥3,000. Buyers, window shoppers, free members — everyone is in the denominator. That's what makes it useful: when ARPU drops, you decompose it.
ARPU = CVR × ARPPU
This decomposition tells you whether the problem is "not enough people buying" or "each buyer spending too little." That distinction drives completely different fixes.
2. ARPU vs ARPPU — the denominator is different
ARPPU (Average Revenue Per Paying User) narrows the denominator to paying users only:
ARPPU = Revenue ÷ Paying Users
Same ¥3M revenue, 200 paying users → ARPPU is ¥15,000. That's 5× the ARPU of ¥3,000, and the multiplier is exactly the inverse of CVR (20%). The ARPU = CVR × ARPPU relationship in action.
When to use which:
- Channel investment → ARPU: it captures conversion differences between channels
- Unit economics → ARPPU: it isolates spend per buyer, better for measuring cross-sell effects
- Growth tracking → both: if ARPU rises, was it CVR or ARPPU or both?
One thing that tripped me up: "average order value" (AOV) ≠ ARPPU. AOV is per order; ARPPU is per person. If someone orders twice in a month, they diverge. In my case, one product category had an AOV of ¥8,000 but ARPPU was ¥12,000 because repeat buyers were averaging 1.5 orders per month. I was underestimating the value of that segment until I looked at the per-person number.
The practical rule: use ARPU when you're deciding which channels deserve more budget (it bakes in conversion rate). Use ARPPU when you're working on increasing spend per buyer (cross-sell, bundles, upsell). Use both when you want to understand why overall revenue per user changed.
3. ARPU benchmarks depend on business type
There's no universal "good ARPU." What determines the benchmark is product price, repeat frequency, and monetization model. I've seen ARPU range from ¥200 for a low-ticket accessories store to ¥15,000+ for a subscription cosmetics brand — comparing them directly would be meaningless.
Four patterns:
- High price × high repeat (supplements, cosmetics subscriptions): highest ARPU. Subscription LTV drives it
- High price × low repeat (electronics, furniture): big per-order but infrequent, so monthly ARPU is moderate
- Low price × high repeat (food, daily necessities): small orders add up. Moderate to low ARPU
- Low price × low repeat (sundries, accessories): lowest ARPU. CVR improvement is the priority
Borrowing someone else's industry average is a trap. Figure out which quadrant you're in and benchmark against similar types. The only legitimate comparison is between businesses in the same quadrant — a subscription supplement brand benchmarking against a one-off electronics store is comparing apples to furniture.
To raise ARPU, there are only two levers: raise CVR (get more visitors to buy) or raise ARPPU (get each buyer to spend more). Knowing which quadrant you're in tells you which lever has more headroom.
4. Getting ARPU by channel with SQL
If you want to compare ARPU across acquisition channels, you need revenue and user counts per channel. Here's a query that produces ARPU, ARPPU, and CVR in one pass:
WITH channel_stats AS (
SELECT
utm_source AS channel,
COUNT(DISTINCT user_id) AS total_users,
COUNT(DISTINCT CASE WHEN has_purchase THEN user_id END) AS paying_users,
SUM(revenue) AS total_revenue
FROM sessions
WHERE session_date >= '2026-05-01' AND session_date < '2026-06-01'
GROUP BY utm_source
)
SELECT
channel,
total_revenue / NULLIF(total_users, 0) AS arpu,
total_revenue / NULLIF(paying_users, 0) AS arppu,
paying_users::FLOAT / NULLIF(total_users, 0) AS cvr
FROM channel_stats
ORDER BY arpu DESC;
The ARPU = CVR × ARPPU relationship holds in the output. When a channel has low ARPU, you can immediately see whether it's a CVR problem (lots of visitors, few buyers) or an ARPPU problem (buyers aren't spending much). That distinction points you to completely different fixes — acquisition optimization vs. upsell/cross-sell.
5. 3 steps to measure your own ARPU
Step 1: Pull last month's revenue
Start with total revenue from your ecommerce platform or GA4's ecommerce report. If you can break it out by channel, do — the differences show up in the next step.
Step 2: Divide by user count
Divide revenue by total users to get ARPU. Also divide by paying users to get ARPPU alongside it. The gap between the two numbers is your CVR effect. In GA4, "Active users" is the closest metric for the denominator.
Step 3: Decompose with ARPU = CVR × ARPPU
Identify whether the bottleneck is low CVR or low ARPPU. If you run this per channel (using the SQL above or your analytics tool), you'll see which channels convert revenue effectively and which ones just bring traffic.
6. Why this is hard to see in GA4
GA4 is session-centric. Ecommerce purchase amounts are available, but to see "how many users came, how many bought, and how much per user" by channel, you need exploration reports with careful filter configuration. Switching between "all users" and "paying users only" adds more filter overhead. And if you want to track ARPU over time by channel, you're rebuilding that exploration report every month. The SQL approach above works if you have the data in a warehouse, but most small ecommerce teams don't have that pipeline set up.
That's the problem I'm working on with RevenueScope — it lines up RPS (revenue per session) and AOV by channel from actual revenue data, so the "is it a CVR problem or a unit economics problem" decomposition becomes straightforward.
When you look at per-user revenue, do you use all users as the base — or just buyers?
(Sorry if my English sounds a bit off — Japanese native. I used Google translate.)