ARPU нельзя «улучшать» средним чеком. Если вы так пишете в отчёте — выводам нельзя доверять.
Классика: в эксперименте или после релиза средний чек вырос, и кто-то приносит радостный вывод «ARPU растёт». А потом внезапно LTV не сходится, выручка на пользователя не повторяется, а продукт ссорится с маркетингом. Цена ошибки простая: вы оптимизируете не тот рычаг и легко делаете хуже для бизнеса, даже если один показатель красиво зелёный.
Механика тут скучная, но беспощадная: ARPU — это выручка на пользователя, а средний чек — выручка на транзакцию. Между ними лежит как минимум то, сколько пользователей вообще платят, и как часто они платят. Средний чек может расти из‑за повышения цен или из‑за ухода «дешёвых» покупок, и во втором случае ARPU часто не растёт, а маскирует просадку в базе.
Минимальный стандарт диагностики: раскладывайте ARPU на компоненты и показывайте вклад каждого.
- Доля платящих: сколько пользователей сделали хотя бы одну оплату в период.
- Частота: сколько оплат в среднем на платящего (или на пользователя — но один вариант выберите и держите везде).
- Чек: выручка на оплату.
- Проверка композиции: одинаковые ли сегменты сравниваете (новые/старые, каналы, страны, платформы).
- Контроль «переезда» метрик: чек растёт из‑за цены, микса, скидок, минимального чека, отмен и возвратов — это разные истории и разные действия.
Шаблон формулировки вывода, который понимает продукт: «ARPU изменился из‑за: доля платящих +/-, частота +/-, чек +/-. Главный драйвер — X. Риск/побочка — Y (например, падение платящих при росте чека). Рекомендованное действие — Z (на какой рычаг давим и чем проверяем)».
Обычно спорят про то, что считать частотой и какой период брать. Это нормально. Ненормально — делать вид, что средний чек и ARPU одно и то же. Граница применимости простая: если у вас нет транзакций (подписка без событий оплат внутри периода), раскладка меняется, но принцип остаётся: сначала доля платящих, потом «интенсивность», и только потом «цена/чек».
