Юнит-экономика для разработчиков: считаем CAC, LTV и payback

Bright_Anton

New member
Когда я только пришёл в продуктовую разработку, любые споры с продактом выглядели примерно так: я говорю, что фича сложная и на неё уйдёт месяц, а в ответ слышу, что клиенты её очень просят и без неё мы потеряем рынок. Аргументы заканчивались на уровне ощущений, и проигрывал тот, кто громче говорил. Перелом случился в момент, когда я впервые сел и посчитал юнит-экономику нашей новой воронки. Оказалось, что за красивыми цифрами спроса прячется дыра, которую видно только в числах. С тех пор я не спорю на пальцах, а открываю табличку и считаю.

Начну с CAC, потому что это самое понятное и самое часто замалчиваемое. CAC, или стоимость привлечения клиента, это все деньги, которые вы потратили на маркетинг, продажи, бонусы и скидки за период, делённое на количество новых клиентов в этом периоде. Самая частая ошибка разработчика и продукта в том, что в CAC не включают зарплаты отдела продаж, партнёрские отчисления и стоимость промо. Я всегда настаиваю на полной картине, потому что неполный CAC искажает вообще всё. Если вы посчитали только рекламный бюджет, вы будете думать, что привлекаете клиента за 500 рублей, а на самом деле за 2500. И вся экономика развалится в тот день, когда маркетинг придёт за реальным бюджетом.

Дальше LTV, или пожизненная ценность клиента. Это сумма денег, которую клиент приносит за всё время работы с вами, минус прямые расходы на его обслуживание. Тут кроется главная ловушка: LTV нельзя измерять за месяц, если у вас не подписка с ежемесячной оплатой. Его нужно считать по когортам, то есть по группе клиентов, пришедших в один период, и смотреть, как они платят через три, шесть, двенадцать месяцев. Если у вас нет данных за такой срок, честно скажите об этом и стройте прогноз с явными допущениями. Прогноз с допущениями лучше, чем красивая цифра из воздуха.

Отдельно про payback, срок окупаемости. Это количество месяцев, за которое клиент возвращает свой CAC. Формула простая: CAC делим на среднюю маржу с клиента в месяц. Мой любимый пример из практики: мы добавили в продукт бесплатный пробный период на тридцать дней вместо четырнадцати. Конверсия выросла, продукт радовался, а payback уехал с четырёх месяцев до девяти. Мы начали привлекать больше клиентов и одновременно сжигать больше денег в моменте. Когда я показал график, где payback пересекает отметку в двенадцать месяцев, разговор сразу стал предметным: пробный период сократили до двадцати одного дня и добавили онбординг.

Что я советую разработчикам, которые хотят участвовать в таких разговорах. Первое: заведите себе простую табличку или дашборд, где раз в месяц обновляете четыре числа: новые клиенты, все затраты на привлечение, средняя маржа с клиента и срок жизни. Второе: всегда фиксируйте, какие допущения вы использовали, иначе через полгода никто не вспомнит, откуда взялась цифра. Третье: не пытайтесь быть единственным носителем истины, ваша задача не победить продакта, а найти с ним общий язык фактов. Когда вы показываете, что при текущем payback фича X окупится за четырнадцать месяцев, а фича Y за пять, разговор перестаёт быть про амбиции и становится про приоритеты.

Ещё один практический момент, который я выстрадал. Считайте юнит-экономику по сегментам, а не только в среднем. Средний CAC по компании часто скрывает, что один канал привлекает клиентов за адекватные деньги, а другой сжигает бюджет с нулевой отдачей. Я однажды защищал техническую задачу по оптимизации онбординга тем, что мы снизим нагрузку на поддержку, и это выглядело слабо. Когда я пересчитал те же данные через снижение стоимости обслуживания и улучшение payback у сегмента малого бизнеса, разговор занял пять минут. Метрики не делают вас бюрократом, они делают вас убедительным.

И последнее, что хочу подчеркнуть. Юнит-экономика не заменяет продуктовое чутьё и стратегию, она его уточняет. Бывают ситуации, где мы осознанно входим в минус ради захвата рынка, и это нормальное решение, но только если оно принято явно, а не случайно. Разница между стратегическим убытком и случайной дырой в бюджете ровно в одном: в первом случае есть расчёт и срок, во втором его нет. Разработчику полезно уметь показывать эту разницу, потому что технические решения влияют на конверсию, отток и стоимость поддержки сильнее, чем многим кажется.

А теперь вопрос к вам, коллеги: а вы считаете юнит-экономику в своей команде или пока живёте на ощущениях и красивых слайдах? Поделитесь, какие метрики прижились у вас и как вам удалось договориться с продуктом на языке цифр, будет интересно сравнить подходы.
 
Назад
Вверх