Юнит-экономика для аналитика:
5 формул,
которые надо знать

Юнит-экономика — это бухгалтерия одного юзера: сколько он приносит, сколько стоит, через сколько окупается. Это не финансы и не бизнес-модель, это аналитика принятия решений: «запускать ли рекламный канал», «стоит ли скидка лояльной аудитории», «можно ли инвестировать в onboarding-команду».

На собесах продуктового аналитика юнит-экономику спрашивают практически всегда. Не как теорию — как инструмент: дают кейс «у нас CAC вырос на 30%, LTV не меняется, что делать?» или «как ты оценишь экономику нового канала trafic'а?». Если ответ начинается с «давайте сначала разделим ARPU и ARPPU» — собеседование идёт правильно.

Достаточно пяти формул, чтобы провести любой такой разговор. Они связаны между собой: каждая следующая использует предыдущие.

Самая часто путаемая пара метрик. ARPU считается на всю базу, ARPPU — только на платящих.

В продуктах с freemium и подпиской разница огромная. Типичные цифры для мобильной игры: ARPU = $0.40 в день, конверсия в платное = 2%, ARPPU = $20 в день. У F2P-игр специально следят за обоими: рост ARPU говорит про общую монетизацию, рост ARPPU — про увеличение чека среди платящих. Это разные двигатели, и команды на них смотрят отдельно.

Где какую брать

LTV — это сколько денег принесёт юзер за всё время жизни в продукте. Он отвечает на главный вопрос юнит-экономики: сколько можно тратить на привлечение, чтобы не было убыточно. Три способа считать, и выбор между ними часто определяет, насколько глубоко аналитик понимает продукт.

Способ 1: Naive (быстрая прикидка)

Простая формула, годится для «на коленке». Работает плохо в двух случаях: (1) на «растущих» юзерах — когда churn зависит от возраста когорты (новые умирают чаще), middle меняется и формула врёт; (2) при быстром росте — когорты разного возраста мешаются и средний churn уходит.

Способ 2: Когортный (правда в моменте)

WITH first_purchase AS (
    SELECT user_id, DATE_TRUNC('month', MIN(created_at)) AS cohort
    FROM orders
    GROUP BY user_id
)
SELECT
    fp.cohort,
    COUNT(DISTINCT o.user_id) AS users_in_cohort,
    SUM(o.amount) AS total_revenue,
    SUM(o.amount) / COUNT(DISTINCT o.user_id) AS ltv_observed,
    DATE_TRUNC('month', o.created_at) AS revenue_month
FROM first_purchase fp
JOIN orders o USING (user_id)
GROUP BY fp.cohort, revenue_month
ORDER BY fp.cohort, revenue_month;

Считаем реальную сумму выручки от каждой когорты регистрации и делим на размер когорты. Получаем наблюдаемый LTV: сколько мы УЖЕ получили от когорты. Точно, проверяемо, не требует допущений. Главное ограничение — это backward-looking: для свежих когорт LTV будет занижен (они ещё не пожили).

Способ 3: Predictive (для свежих когорт)

Для свежих когорт когортный LTV слишком мал — мы видим только первый месяц. Чтобы оценить экономику нового канала уже сейчас, нужна модель.

На практике делается так: берёшь когортный retention за последние 12+ месяцев, фитишь к нему модель (часто sBG — shifted Beta-Geometric, либо простая экспонента retention(t) = a · b^t), экстраполируешь до желаемого горизонта (12 / 24 / 36 месяцев). На каждый месяц горизонта умножаешь на ARPU и маржу. Сумма — predicted LTV.

CAC — сколько денег ты тратишь на привлечение одного нового платящего пользователя. У формулы есть две версии, и они нужны для разных решений.

Marketing-only CAC

Используется для оптимизации каналов. Помогает ответить «какой канал выгоднее» и «стоит ли отключать слабую кампанию». Внутри маркетинговой команды это рабочая ежедневная метрика.

Fully-loaded CAC

Используется для стратегических решений: целевая маржа, payback period, оценка экономики продукта целиком. Когда CEO спрашивает «мы вообще прибыльные?» — это fully-loaded.

Per-user vs Per-cohort

Скользящий CAC по месяцу = «маркет расход в апреле / новые юзеры в апреле». Он удобен для дашборда, но врёт для продуктов с длинным циклом: реклама в апреле может конвертироваться в платных юзеров в мае-июне, и CAC за апрель окажется завышенным.

Когортный CAC по каналу = «весь маркет расход на привлечение когорты / число платных юзеров в этой когорте». Точнее, но видишь только после того, как когорта «созрела» (обычно 30–90 дней). На собесе спрашивают «как ты выберешь, какой считать» — ответ: для оптимизации каналов — скользящий, для бизнес-решений — когортный.

Payback — это время, за которое выручка от юзера (с учётом маржи) покрывает CAC. Это скорость возврата и главный регулятор того, насколько быстро можно вкладываться в рост.

Главное в этой формуле — это учёт маржи. ARPU без маржи даёт «выручку», а CAC возвращается только из прибыли. Если для тебя ARPU = ₽400, но себестоимость доставки + платёжная комиссия + поддержка = ₽160 на заказ, то реально на покрытие CAC идёт ₽240, не ₽400. Payback на самом деле в 1.67 раза дольше, чем кажется без маржи.

Что считать «нормальным»

Цифры зависят от стадии компании. Bootstrap-стартап целится в payback < 6 мес — нет денег ждать дольше. VC-поддержанная компания может позволить себе payback в 18–24 мес, потому что есть капитал на закрытие кэша до возврата.

Contribution margin (CM, маржинальная прибыль) — это выручка с одного юзера или заказа минус все переменные затраты, связанные с этим юзером. Это «жёсткая» метрика: её не накрутить ростом базы, и она первой реагирует на экономические сдвиги.

Часто записывают в процентах:

Что считать переменными затратами — главный вопрос. В типичном e-com: COGS, доставка, платежи, упаковка. В SaaS: затраты на серверы, поддержка, платежи. Аренда офиса, ЗП разработчиков, маркетинг — это не CM, это операционные затраты выше CM.

Зачем именно CM, а не «маржа»

Слово «маржа» используют для всего подряд: gross margin, operating margin, net margin, CM. Их легко перепутать. В юнит-экономике нужен именно contribution margin: только переменные затраты, привязанные к юзеру.

Почему — потому что только CM используется в формуле payback. Если в твоей «марже» 60% уже сидит распределённая аренда и ЗП дизайнеров (которые от количества юзеров не зависят), payback получится несравнимый с другими бизнесами. CM-выручка чистая, на ней можно сравнивать каналы и кампании.

Половина «странных» цифр в юнит-экономике — это не реальность бизнеса, а одна из этих четырёх ошибок. По частоте, с которой я их встречаю у менти на текущей итерации.

На собесах продуктового аналитика юнит-экономика — это обязательный минимум. Часто заходят через кейс: «у нас выросла выручка, но падает прибыль — что бы ты проверил». Правильный ответ — пройтись по пяти формулам и найти, где разрыв.