ARPU и ARPPU: как считать выручку на пользователя
Как считать ARPU и ARPPU, выбрать корректный знаменатель, учитывать возвраты и скидки и не принять рост среднего чека за здоровую монетизацию.
Содержание статьи
Рост выручки звучит как хорошая новость, но для продуктовой команды этого часто недостаточно. Она хочет понять: люди стали платить чаще, платить больше, приходить более ценными или просто в этом месяце в базе меньше бесплатных пользователей? ARPU и ARPPU помогают разложить ответ, если заранее договориться, чью выручку и каких пользователей мы считаем.
Коротко
ARPU показывает среднюю выручку на пользователя за период. ARPPU — среднюю выручку только на платящего пользователя. Между ними лежит важный слой: доля плательщиков. Нельзя читать одну из этих метрик без двух соседних, иначе среднее легко расскажет красивую, но неполную историю.
- ARPU = чистая выручка за период / выбранная аудитория за тот же период.
- ARPPU = чистая выручка за период / число платящих пользователей.
- Рядом почти всегда нужны payer conversion, количество платящих и retention платящих.
- Одинаково учитывай скидки, возвраты, комиссии и налоги во всех периодах.
ARPU, ARPPU и payer conversion отвечают на разные вопросы
ARPU удобен для общей картины монетизации: сколько выручки в среднем приходится на активного пользователя или аккаунт. ARPPU показывает поведение уже платящей части базы. Payer conversion соединяет их и говорит, какая доля аудитории вообще дошла до оплаты. Вместе они помогают отличить рост цены от роста спроса.
| Метрика | Формула | Какой вопрос задаёт |
|---|---|---|
| ARPU | net revenue / active users | Сколько в среднем приносит выбранная активная аудитория? |
| ARPPU | net revenue / paying users | Сколько в среднем тратит тот, кто уже платит? |
| Payer conversion | paying users / active users | Какая доля аудитории вообще стала платящей? |
Знаменатель меняет историю
Фраза “ARPU за июнь” неполна без знаменателя. В подписочном B2B SaaS можно считать выручку на активный аккаунт, на платящий workspace или на всех клиентов с действующим договором. В игре — на активного игрока. В маркетплейсе — на покупателя, продавца или на обе стороны, но это уже будут разные метрики.
Выбери единицу, которая совпадает с тем, как продукт создаёт и получает ценность. Если один контракт обслуживает 50 сотрудников, ARPU по user_id может искусственно просесть при росте команды заказчика, хотя деньги и здоровье бизнеса не изменились. В таком продукте часто честнее смотреть revenue per account.
ARPU = ARPPU × payer conversionФормула работает, только если у ARPU и payer conversion одинаковая база пользователей и одинаковый период.
Один рост ARPU может скрывать две разные реальности
В условном примере ARPU растёт, а ARPPU постепенно снижается. Такое бывает, когда платить начинает больше людей, но средний платёж или состав покупок меняется. Это не автоматически плохой сценарий: возможно, новый недорогой тариф расширил рынок. Но точно не повод писать “монетизация улучшилась” без проверки маржинальности, retention и качества новых плательщиков.
Условный пример. Рост ARPU при снижении ARPPU нужно читать вместе с долей плательщиков, ценой и составом тарифов.
SQL для месячных ARPU и ARPPU
В этом примере ARPU считается на активных пользователей, которые сделали core action в месяце. Таблица payments содержит успешные списания и возвраты. Сначала приводим платежи к чистой выручке, затем присоединяем их к аудитории месяца. Так возвраты не исчезают из числителя, а пользователи без платежа остаются в знаменателе ARPU.
Статусы и поля в реальной базе могут отличаться. Главное правило не в названиях таблиц, а в согласованной логике: один и тот же период, одна единица пользователя и один способ учёта возвратов во всех отчётах.
with active_users as (
select distinct user_id, date_trunc('month', occurred_at)::date as month
from events
where occurred_at >= date_trunc('month', current_date) - interval '6 months'
and occurred_at < date_trunc('month', current_date)
and event_name in ('report_viewed', 'report_created')
),
user_revenue as (
select user_id, date_trunc('month', paid_at)::date as month,
sum(case
when payment_type = 'refund' and payment_status = 'succeeded' then -amount
when payment_status = 'succeeded' then amount
else 0
end) as net_revenue
from payments
where paid_at >= date_trunc('month', current_date) - interval '6 months'
and paid_at < date_trunc('month', current_date)
group by 1, 2
)
select a.month, count(*) as active_users,
count(r.user_id) filter (where r.net_revenue > 0) as paying_users,
sum(coalesce(r.net_revenue, 0)) as net_revenue,
round(sum(coalesce(r.net_revenue, 0)) / nullif(count(*), 0), 2) as arpu,
round(sum(coalesce(r.net_revenue, 0)) / nullif(count(r.user_id) filter (where r.net_revenue > 0), 0), 2) as arppu,
round(count(r.user_id) filter (where r.net_revenue > 0)::numeric / nullif(count(*), 0), 3) as payer_conversion
from active_users a
left join user_revenue r on r.user_id = a.user_id and r.month = a.month
group by 1
order by 1;Где ARPU начинает врать
ARPU особенно легко улучшить арифметически. Если из активной базы ушли редкие бесплатные пользователи, знаменатель уменьшится и ARPU вырастет, хотя бизнес не заработал больше. То же происходит, когда команда случайно исключает возвраты, считает gross вместо net revenue или объединяет разовую продажу и регулярную подписку без пояснения.
- Не сравнивай gross revenue с net revenue между месяцами.
- Не меняй знаменатель с активных пользователей на всех зарегистрированных без явной подписи.
- Отделяй разовые платежи, подписки, upsell и возвраты, если у них разные причины изменения.
- Смотри распределение: несколько крупных плательщиков могут сильно сдвинуть среднее.
- Проверяй ARPU по когортам и каналам, особенно после изменения цены или закупки трафика.
ARPU нужно разложить на плательщиков и чек
ARPU — среднее по всей выбранной аудитории, поэтому его изменение удобно разложить на две части: сколько пользователей платит и сколько в среднем платит каждый из них. Если ARPU вырос, а ARPPU почти не изменился, основной вклад дала payer conversion. Если ARPPU вырос при стабильной доле плательщиков, ищи изменение цены, набора тарифов, количества покупок или состава аудитории.
Это разложение не доказывает причину само по себе. Рост payer conversion может прийти из скидки, более качественного трафика или изменения paywall. Снижение ARPPU может быть полезным, если продукт успешно перевёл аудиторию на дешёвый стартовый тариф, и опасным, если дорогие клиенты ушли. Поэтому рядом с двумя средними нужны распределение платежей и cohort retention плательщиков.
| ARPU | ARPPU | Payer conversion | Первая гипотеза |
|---|---|---|---|
| растёт | стабилен | растёт | больше пользователей дошло до оплаты |
| растёт | растёт | стабильна | изменился чек, цена или mix тарифов |
| падает | растёт | падает | остались крупные плательщики, массовая конверсия ухудшилась |
| стабилен | падает | растёт | расширилась дешёвая платящая база; проверить маржу |
Период, возвраты и деньги должны совпадать
Перед сравнением ARPU за два месяца проверь не только формулу, но и денежный слой. Успешный платёж, возврат, отмена подписки и chargeback могут приходить в разные даты. Если июльский возврат вычитается из августовской выручки, месяцы становятся несопоставимыми. В отчёте нужно явно описать, используешь ли cash basis, дату первоначального платежа или признание выручки по другой бухгалтерской логике.
В международном продукте добавляется валюта и таймзона. Суммируй деньги после согласованной конвертации, а не округляй каждую транзакцию отдельно. В B2B отдельно проверь, не делишь ли ты один счёт на всех пользователей аккаунта: для решения о цене может быть важнее revenue per account или per workspace.
- Определи, что считается выручкой: gross, net или contribution revenue.
- Зафиксируй дату, к которой относятся платежи и возвраты.
- Приведи валюты и таймзоны к единому правилу.
- Проверь единицу расчёта: user, account, workspace или order.
- Покажи медиану и квантили, если несколько крупных плательщиков искажают среднее.
Сегментный ARPU помогает принять решение
Средний ARPU всего продукта часто слишком грубый для действия. Раздели его хотя бы по каналу, тарифу, платформе и когорте. После изменения цены сравнивай не только текущий месяц, но и одинаковый возраст когорт: новые пользователи могли ещё не дойти до повторной оплаты. Для подписки добавь churn и renewal rate, для разовых покупок — повторный заказ и возвраты.
Рабочий вывод должен связывать деньги с поведением. Например: “ARPU вырос за счёт тарифа Starter и Android, но ARPPU снизился, а D30 retention новых плательщиков не изменился. Сигнал похож на расширение платящей базы, а не на готовность повышать цену. Сначала проверяем маржу и повторную оплату по когорте”. Такой текст оставляет пространство для проверки, а не превращает среднее число в приказ.
- Сравнивай одинаковые когорты и одинаковый горизонт.
- Проверяй ARPU вместе с payer conversion, ARPPU и retention.
- Отделяй изменение mix от изменения поведения внутри сегмента.
- Для pricing-решения добавляй маржу и долю возвратов.
Как сделать вывод, который можно обсуждать
Вместо “ARPU вырос на 12%” лучше написать: “Июньский ARPU вырос с 496 до 518 ₽. Рост дали новые пользователи базового тарифа: payer conversion поднялся, но ARPPU снизился. Доля возвратов и D30 этих когорт пока не изменилась. Следующий шаг — проверить маржу базового тарифа и retention новых плательщиков, а не повышать цену всем пользователям”.
Такой вывод связывает деньги с поведением, не делает лишних причинных выводов и оставляет команде ясный следующий вопрос. Для разложения входа в оплату пригодится воронка, а для оценки качества новых покупателей — когорты retention.
Материалы по теме

LTV: как считать ценность пользователя по когортам
Как считать LTV по когортам, связать его с ARPU и retention, сравнить каналы и не выдать грубую оценку за пожизненную ценность пользователя.
Unit-экономика продукта: CAC, LTV и срок окупаемости
Как связать стоимость привлечения, маржинальную выручку и поведение когорт: разбираем CAC, LTV, payback period и типичные ошибки в unit-экономике.
Декомпозиция метрики: как найти, из чего сложился рост или падение
Практический метод декомпозиции метрик: пользователи, конверсия, средний чек, сегменты и вклад компонентов для продуктовых и бизнес-решений.