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

Запрос написан для учебной базы симулятора SQL-аналитика. Аудитория месяца — все, у кого было хотя бы одно событие; выручка — сумма amount из payments, в долларах. Возвратов в этой базе нет; в рабочем запросе их вычитает case. Аудитория и выручка считаются отдельно и соединяются по месяцу: пользователи без платежа остаются в знаменателе ARPU, а построчный left join оплат к активным потерял бы 49 из 642 августовских плательщиков — событий в августе у них нет. Из них 40 пришли в июне, а события пользователя в учебной базе записаны только 59 дней.

Результат: ARPU — 3,82 доллара в июне, 4,04 в июле и 3,84 в августе; ARPPU — 23,85, 24,93 и 24,59; доля плательщиков — 16,0%, 16,2% и 15,6%. ARPPU июля выше среднего чека, 24,59: шесть человек заплатили дважды, а ARPPU делит выручку на плательщиков, а не на оплаты. Август не закрыт: в выручке нет 31-го числа.

В вашей базе поля будут другими; правило — в согласованной логике: один период, одна единица пользователя и один способ учёта возвратов во всех отчётах.

with audience as (                -- зерно: месяц, активен — любое событие
  select cast(date_trunc('month', event_time) as date) as month,
    count(distinct user_id) as active_users
  from events
  group by 1
),
revenue as (                      -- зерно: месяц, возвратов в учебной базе нет
  select cast(date_trunc('month', paid_at) as date) as month,
    count(distinct user_id) as paying_users,
    sum(amount) as net_revenue
  from payments
  group by 1
)
select a.month, a.active_users,
  coalesce(r.paying_users, 0) as paying_users,
  coalesce(r.net_revenue, 0) as net_revenue,
  round(coalesce(r.net_revenue, 0) / a.active_users, 2) as arpu,
  round(r.net_revenue / nullif(r.paying_users, 0), 2) as arppu,
  round(100.0 * coalesce(r.paying_users, 0) / a.active_users, 1) as payer_conversion_pct
from audience a
left join revenue r on r.month = a.month
order by a.month;

Где 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 за два месяца проверьте не только формулу, но и денежный слой. Успешный платёж, возврат, отмена подписки и 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 ₽, хотя ни в одном канале он не изменился

Июньская и июльская точки с графика выше — 518 и 530 ₽. Разложите оба месяца по каналам привлечения, и рост перестанет быть ростом. В июне активных пользователей 10 000: organic 4 000, paid 5 000, referral 1 000. В июле их столько же, но состав другой: organic 4 230, paid 4 770, referral 1 000. Сегментный ARPU в оба месяца одинаковый — 750 ₽ у organic, 216 ₽ у paid, 1 100 ₽ у referral. Перемножьте и сложите: 3 000 000 + 1 080 000 + 1 100 000 = 5 180 000 ₽ в июне, 3 172 500 + 1 030 320 + 1 100 000 = 5 302 820 ₽ в июле. Те же 518 и 530 ₽ на пользователя.

Двенадцать рублей дал состав аудитории. Доля paid опустилась с 50,0% до 47,7%, доля organic поднялась с 40,0% до 42,3%, и общий средний сдвинулся в сторону более дорогого канала. Внутри каналов не изменилось ничего: ни цена, ни доля плательщиков, ни средний платёж. Тот же механизм, что арифметически поднимает ARPU при уходе редких бесплатных пользователей, работает и при закупке — только через числитель долей, а не через отток.

Чтобы не спорить на глаз, изменение общего среднего раскладывают на два слагаемых: поведение внутри сегментов и сдвиг их долей. Первое считается по долям базового месяца, второе — по сегментным ARPU текущего, и сумма точно равна наблюдённому изменению. В примере первое слагаемое равно нулю, второе даёт 0,023 × 750 − 0,023 × 216 = 12,3 ₽ — ровно ту разницу, которую видно на графике. Если поменять местами, какой месяц даёт веса, а какой средние, получится другое разбиение того же числа, поэтому правило фиксируют один раз и пишут рядом с таблицей.

Практический смысл разложения в том, что два слагаемых ведут к разным действиям. Сдвиг долей — это разговор с маркетингом о структуре закупки: он ничего не говорит о продукте и исчезнет в следующем месяце, если вернётся прежний микс. Изменение внутри сегмента — это разговор о цене, paywall или качестве трафика канала. Отчёт, в котором стоит только общий ARPU, в обоих случаях выглядит одинаково, и команда начинает искать продуктовую причину там, где менялась реклама.

У ARPPU тот же эффект живёт на других весах: его знаменатель — плательщики, а не пользователи. Возьмите июньский пример с долями оплаты 40% у organic, 30% у paid и 50% у referral. Плательщиков получается 1 600 + 1 500 + 500 = 3 600, и referral, дающий 10% аудитории, весит в знаменателе ARPPU почти 14%, а paid с половиной аудитории — 41,7%. После того же сдвига в 230 пользователей плательщиков становится 3 623, общий ARPPU поднимается с 1 439 до 1 464 ₽, а payer conversion — с 36,0% до 36,2%. Все три числа трио изменились, и ни одно изменение не вызвано поведением. Чтобы ARPPU при росте ARPU, наоборот, снижался, сдвиг должен идти в канал, где платят чаще, но меньше: знаменатель плательщиков тогда растёт быстрее выручки.

Запрос ниже считает то же на учебной базе; база сравнения — июль, первый месяц со всеми четырьмя каналами. ARPU упал с 4,04 до 3,84 доллара, а при июльских долях каналов август дал бы 3,96. Из 20 центов падения 12 — состав: доля платного поиска, где ARPU 1,81 доллара, выросла с 17,9% до 23,0%. Остальные 8 центов поведением считать рано: в августовской выручке нет 31-го числа, а средний день оплат — 13 центов на активного пользователя.

with audience as (                -- зерно: месяц + канал, активные пользователи
  select cast(date_trunc('month', e.event_time) as date) as month, u.channel,
    count(distinct e.user_id) as users
  from events e
  join users u on u.user_id = e.user_id
  group by 1, 2
),
revenue as (                      -- зерно: месяц + канал, оплаты
  select cast(date_trunc('month', p.paid_at) as date) as month, u.channel,
    sum(p.amount) as revenue
  from payments p
  join users u on u.user_id = p.user_id
  group by 1, 2
),
monthly as (
  select a.month, a.channel, a.users, coalesce(r.revenue, 0) as revenue
  from audience a
  left join revenue r on r.month = a.month and r.channel = a.channel
),
base as (                         -- доли базового месяца, сумма равна 1
  select channel,
    1.0 * users / sum(users) over () as weight
  from monthly
  where month = date '2026-07-01'
)
-- arpu_at_base_mix стоит на месте, пока меняются только доли каналов:
-- расхождение двух колонок и есть вклад микса
select m.month,
  round(sum(m.revenue) / sum(m.users), 2) as arpu_fact,
  round(cast(sum(b.weight * m.revenue / m.users) as numeric), 2) as arpu_at_base_mix
from monthly m
join base b on b.channel = m.channel
where m.month >= date '2026-07-01'   -- в июне платного поиска ещё не было
group by m.month
order by m.month;

Как сделать вывод, который можно обсуждать

Вместо «ARPU вырос на 12%» лучше написать (числа условные): «Июньский ARPU вырос с 496 до 518 ₽. Рост дали новые пользователи базового тарифа: payer conversion поднялся, но ARPPU снизился. Доля возвратов и D30 этих когорт пока не изменилась. Следующий шаг — проверить маржу базового тарифа и retention новых плательщиков, а не повышать цену всем пользователям».

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