Дмитрий Ланецкий – Юнит-экономика для роста: модель, сценарии и контрольные пороги (страница 6)

Ритм обновления: как часто считать и что пересматривать

Юнит-экономика превращается в инструмент, когда у неё есть регулярность:

Еженедельно: расходы по каналам, CAC/CPA, вклад в покрытие, возвраты/отмены, аномалии.

Ежемесячно: LTV по когортам (насколько хватает горизонта), сравнение каналов, пересмотр себестоимости и логистики.

Ежеквартально: стресс-тесты (рост CAC, падение конверсии, рост возвратов), пересмотр допущений и структуры затрат.

И да, “считать раз в год” – это как проверять тормоза раз в год. Вроде иногда работает, но ставка некомфортная.

Артефакт: “Паспорт данных” для юнит-экономики (короткий шаблон)

Сделайте один документ (хоть в Google Docs), где зафиксировано:

Что является юнитом и как он считается

Источники данных (реклама, CRM, банк, склад…)

Поля/столбцы, которые обязательны

Правила очистки (как называем каналы, что делаем с пустыми значениями)

Как считаем выручку (брутто/нетто), как учитываем возвраты

Как считаем переменные расходы (что включаем/не включаем)

Частота обновления и ответственный

Это скучно ровно до того момента, пока у вас не сменится менеджер, не появится новый канал или не изменится комиссия – и внезапно вы будете благодарны себе за эту скуку.

Теперь у нас есть то, на чём держится модель: выбран юнит, определены метрики, понятны источники данных и правила их “приземления”. Следующий логический шаг – собрать всё это в работающую таблицу/модель и научить ИИ помогать с обновлением, проверками и сценариями так, чтобы юнит-экономика стала не разовой презентацией, а прибором на панели управления бизнесом.

Глава 5. Собираем модель: от «таблички» к инструменту принятия решений

К этому моменту у нас есть всё, что обычно скрыто в тумане: выбран юнит, определены метрики, понятно, где брать данные и какие ловушки не наступать. Теперь начинается самое прикладное – сборка модели. И тут важно одно: модель должна помогать принимать решения, а не просто выглядеть солидно.

Хорошая юнит-модель – это не «финансовая поэзия», а управленческий прибор. Она должна отвечать на вопросы вроде:

какой канал можно масштабировать;

где мы теряем маржу;

сколько мы можем платить за клиента/заказ;

что будет, если CAC вырастет, а конверсия упадёт;

где мы словим кассовый разрыв.

Принцип конструкции: модель = входные данные + правила + выводы

Есть соблазн строить модель как гигантскую простыню, где всё везде связано. Это красиво до первого изменения – и потом ломается как хрустальная люстра.

Практичнее мыслить тремя слоями:

Входные данные (Inputs) – сырые цифры из источников.

Правила расчёта (Model) – формулы, распределения, допущения.

Выводы (Dashboard / Decisions) – метрики и сценарии, которые ведут к действиям.

ИИ особенно полезен именно на границе слоёв: он помогает очистить inputs, проверяет логику model и переводит dashboard в решения.

Шаг 1. Стандартизируем входные данные (чтобы не жить в ручном аду)

Минимум, который стоит привести к единому формату:

Дата

Канал / источник (нормализованный)

Юниты (кол-во заказов/клиентов/подписок)

Выручка (нетто)

Себестоимость (COGS)

Переменные расходы (комиссии, эквайринг, доставка, упаковка, поддержка)

Маркетинг-расходы по каналам

Идентификатор клиента/заказа (если делаете LTV/повторы)

Как помогает ИИ

приводит «зоопарк названий» каналов к единому справочнику;

находит пропуски и странные значения;

подсвечивает несостыковки (например, заказы есть, а выручки ноль).

Если вы хоть раз руками исправляли “Facebook/FB/Meta/Meta Ads” – вы знаете, почему это важно.

Шаг 2. Делаем базовые расчёты на уровне юнита

На уровне каждой строки (дата+канал или дата+продукт – как вы решите) считаем:

Contribution Margin на юнит

= (Нетто-выручка − все переменные расходы) / кол-во юнитов

CAC/CPA/CPO (в зависимости от юнита)

= маркетинг-расходы / кол-во привлечённых клиентов/заказов

Contribution Margin после привлечения

= вклад в покрытие − CAC (если юнит = клиент)

или вклад в покрытие на заказ − CPO (если юнит = заказ)

Это место, где модель начинает говорить правду. Иногда неприятную. Зато полезную.

Шаг 3. Добавляем повторяемость: LTV и когорты (хотя бы в упрощении)

Если у вас есть повторные покупки или подписка, без LTV модель будет «однозубой» – она увидит только первую сделку и не увидит продолжение жизни клиента.

Простейший рабочий уровень:

выделить клиентов по дате первой покупки (когорта),

посчитать, сколько маржи они принесли за 30/60/90 дней,

сравнить это с CAC по каналу привлечения.

Да, 90 дней – это не «вся жизнь клиента». Но это уже честная опора для решений сегодня.

Как помогает ИИ