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

Коротко

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

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

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

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

Знаменатель меняет историю

Фраза “ARPU за июнь” неполна без знаменателя. В подписочном B2B SaaS можно считать выручку на активный аккаунт, на платящий workspace или на всех клиентов с действующим договором. В игре — на активного игрока. В маркетплейсе — на покупателя, продавца или на обе стороны, но это уже будут разные метрики.

Выбери единицу, которая совпадает с тем, как продукт создаёт и получает ценность. Если один контракт обслуживает 50 сотрудников, ARPU по user_id может искусственно просесть при росте команды заказчика, хотя деньги и здоровье бизнеса не изменились. В таком продукте часто честнее смотреть revenue per account.

Один рост ARPU может скрывать две разные реальности

В условном примере ARPU растёт, а ARPPU постепенно снижается. Такое бывает, когда платить начинает больше людей, но средний платёж или состав покупок меняется. Это не автоматически плохой сценарий: возможно, новый недорогой тариф расширил рынок. Но точно не повод писать “монетизация улучшилась” без проверки маржинальности, retention и качества новых плательщиков.

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' 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 вырос на 12%” лучше написать: “Июньский ARPU вырос с 496 до 518 ₽. Рост дали новые пользователи базового тарифа: payer conversion поднялся, но ARPPU снизился. Доля возвратов и D30 этих когорт пока не изменилась. Следующий шаг — проверить маржу базового тарифа и retention новых плательщиков, а не повышать цену всем пользователям”.

Такой вывод связывает деньги с поведением, не делает лишних причинных выводов и оставляет команде ясный следующий вопрос. Для разложения входа в оплату пригодится воронка, а для оценки качества новых покупателей — когорты retention.