Все материалы
Продуктовая аналитикагайдстарт

ARPU и ARPPU: как считать выручку на пользователя

Как считать ARPU и ARPPU, выбрать корректный знаменатель, учитывать возвраты и скидки и не принять рост среднего чека за здоровую монетизацию.

КПКейсПрактика9 июля 2026 г.17 мин

Рост выручки звучит как хорошая новость, но для продуктовой команды этого часто недостаточно. Она хочет понять: люди стали платить чаще, платить больше, приходить более ценными или просто в этом месяце в базе меньше бесплатных пользователей? ARPU и ARPPU помогают разложить ответ, если заранее договориться, чью выручку и каких пользователей мы считаем.

Коротко

ARPU показывает среднюю выручку на пользователя за период. ARPPU — среднюю выручку только на платящего пользователя. Между ними лежит важный слой: доля плательщиков. Нельзя читать одну из этих метрик без двух соседних, иначе среднее легко расскажет красивую, но неполную историю.

  • ARPU = чистая выручка за период / выбранная аудитория за тот же период.
  • ARPPU = чистая выручка за период / число платящих пользователей.
  • Рядом почти всегда нужны payer conversion, количество платящих и retention платящих.
  • Одинаково учитывай скидки, возвраты, комиссии и налоги во всех периодах.

ARPU, ARPPU и payer conversion отвечают на разные вопросы

ARPU удобен для общей картины монетизации: сколько выручки в среднем приходится на активного пользователя или аккаунт. ARPPU показывает поведение уже платящей части базы. Payer conversion соединяет их и говорит, какая доля аудитории вообще дошла до оплаты. Вместе они помогают отличить рост цены от роста спроса.

Три метрики вместо одного среднего
МетрикаФормулаКакой вопрос задаёт
ARPUnet revenue / active usersСколько в среднем приносит выбранная активная аудитория?
ARPPUnet revenue / paying usersСколько в среднем тратит тот, кто уже платит?
Payer conversionpaying 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 за месяц, ₽ на пользователя

Условный пример. Рост ARPU при снижении ARPPU нужно читать вместе с долей плательщиков, ценой и составом тарифов.

ARPUARPPU

SQL для месячных ARPU и ARPPU

В этом примере ARPU считается на активных пользователей, которые сделали core action в месяце. Таблица payments содержит успешные списания и возвраты. Сначала приводим платежи к чистой выручке, затем присоединяем их к аудитории месяца. Так возвраты не исчезают из числителя, а пользователи без платежа остаются в знаменателе ARPU.

Статусы и поля в реальной базе могут отличаться. Главное правило не в названиях таблиц, а в согласованной логике: один и тот же период, одна единица пользователя и один способ учёта возвратов во всех отчётах.

ARPU, ARPPU и доля плательщиков по месяцам
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 плательщиков.

Как читать совместное изменение метрик
ARPUARPPUPayer 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.

Продолжить чтение
Вся библиотека