Юнит-экономика: как считать прибыль на клиента и проверять масштабирование

Юнит-экономика: как считать прибыль на клиента и проверять масштабирование

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

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

Что считать юнитом в юнит-экономике

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

Хороший юнит отвечает четырем условиям:

• его количество можно надежно получить из учетной системы;

• доход можно отнести к этому же объекту;

• переменные расходы меняются вместе с числом юнитов;

• результат позволяет принять конкретное решение по цене, каналу, продукту или объему.

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

Как рассчитать юнит-экономику

Базовая логика проста:

`Вклад юнита = доход на юнит − переменные расходы на юнит − прямые расходы на привлечение и обслуживание юнита`.

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

Затем проверьте итог на уровне компании:

`Прибыль периода = сумма вкладов всех юнитов − постоянные расходы периода`.

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

Если продуктов несколько, не умножайте одну среднюю маржу на общий объем. Посчитайте вклад каждого сегмента отдельно, а затем сложите результаты. Так изменение продуктового микса не исчезнет внутри среднего показателя.

Какие расходы включать в расчет

Сначала зафиксируйте правило классификации, а потом собирайте цифры. Если команда каждый месяц по-разному относит зарплату, логистику или бонусы продавцов, сравнение периодов потеряет смысл.

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

Затраты на привлечение тоже нужно считать в одном разрезе. CAC по всему маркетинговому бюджету и всем новым клиентам может быть полезен для общей оценки. Для решения о канале нужна детализация по каналу и когорте. При этом расходы отдела маркетинга и разовая рекламная кампания могут вести себя по-разному при росте объема.

Постоянные расходы не стоит искусственно распределять на каждый юнит, если коэффициент распределения ничего не объясняет. Держите их отдельным блоком и проверяйте, покрывает ли совокупный вклад юнитов аренду, фиксированную часть фонда оплаты труда, разработку и административные функции.

Почему LTV и CAC могут дать ложный ответ

LTV и CAC полезны только при зафиксированных определениях. Одни команды называют LTV выручку клиента за весь срок отношений. Другие считают валовую или маржинальную прибыль. Сравнивать эти варианты между собой нельзя.

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

Есть еще проблема времени. Компания платит за привлечение сейчас, а доход получает несколько месяцев. Экономика клиента может быть положительной, но быстрый рост создаст нехватку денег. Поэтому рядом с LTV и CAC нужен срок окупаемости затрат на привлечение и прогноз денежного потока.

Проверяйте не только среднее значение, но и когорты. Клиенты, пришедшие после изменения цены или рекламного сообщения, могут покупать и уходить иначе. Если смешать их со старой базой, ухудшение станет заметно слишком поздно.

Как проверить масштабирование до роста бюджета

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

В крупной модели нужно быстро проверять каждое допущение. Optimacros использует in-memory OLAP и пересчитывает расчет в реальном времени. Финансовая команда может увидеть, как новая цена, конверсия или частота повторных покупок изменит вклад сегмента и итоговую прибыль до увеличения бюджета.

Перед решением пересчитайте хотя бы четыре сценария:

• базовый объем при текущих цене, конверсии и расходах.

• рост продаж без изменения эффективности канала.

• рост CAC или снижение конверсии после расширения аудитории.

• ограничение по складу, производству, доставке или команде.

• изменение повторных покупок и срока окупаемости.

• напряженный денежный сценарий с задержкой поступлений.

Смотрите на результат по продуктам и каналам. Общая экономика может улучшиться за счет одного сегмента, пока другой масштабирует убыток. Поэтому останавливать нужно не весь рост, а конкретную связку канала, предложения и операционного ограничения.

Когда таблицы перестают справляться

Таблица подходит для первой модели с несколькими продуктами и понятными правилами. Проблема начинается, когда маркетинг считает клиентов по каналам, продажи — по договорам, финансы — по статьям, а операционная команда — по заказам или SKU. Сверка справочников занимает больше времени, чем анализ.

Следующий сигнал — частые изменения логики. Команда меняет определение активного клиента, срок когорты или состав переменных расходов, но старые формулы остаются в копиях файлов. В итоге два отчета с одинаковым названием отвечают на разные вопросы.

Как внедрить юнит-экономику без долгого проекта

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

Рабочая последовательность выглядит так:

1. Выберите юнит и период расчета. 2. Зафиксируйте формулы и владельца каждого показателя. 3. Свяжите доход, переменные расходы и привлечение в одном разрезе. 4. Разделите клиентов или заказы на несколько значимых сегментов. 5. Сверьте расчет с прибылью периода и денежным потоком. 6. Проверьте сценарий роста и операционные ограничения. 7. Обновляйте модель по факту и отдельно объясняйте изменение драйверов.

Не пытайтесь сразу получить идеальный LTV на многолетнем горизонте. Для первого решения полезнее честный расчет по короткой зрелой когорте, чем точная на вид формула на слабых данных.

Что должно получиться в итоге

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

Рабочая модель соединяет три уровня: результат одного юнита, постоянные расходы компании и движение денег во времени. Если одного уровня нет, масштабирование остается ставкой на среднюю цифру. Если все три связаны, руководство может менять цену, канал и объем, понимая последствия до расходования бюджета.

11