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

Юнит-экономика почти всегда собирается из пяти «континентов»:

Продажи / транзакции

касса / банк / платёжный провайдер

CRM (счета, статусы, причина отказа)

маркетплейс-кабинеты (заказы, комиссии, возвраты)

Маркетинг

рекламные кабинеты (расходы, показы, клики, лиды)

UTM-метки и веб-аналитика (источник, кампания)

стоимость креативов, агентств, продакшна

Себестоимость и операционка

закупка/производство (COGS)

логистика/доставка/склад

упаковка, расходники, брак

поддержка/колл-центр (если переменная часть ощутима)

Повторяемость и удержание

повторные покупки в транзакциях

подписки/продления

активность пользователей (если продуктовый слой важен)

Финансы

комиссии, эквайринг, налоги (иногда как отдельные ставки)

постоянные расходы (для проверки “покрытия”)

Главная идея: всё, что влияет на вклад в покрытие и стоимость привлечения, должно быть видимо в данных.

Минимальный набор данных для первой честной модели

Если вы начинаете и хотите “считать уже завтра”, то вам достаточно вот такого набора:

дата

канал/источник (хотя бы грубо)

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

нетто-выручка (после скидок и возвратов)

себестоимость (COGS) на юнит или партиями

переменные комиссии/доставка/эквайринг

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

признак повторной покупки (или номер заказа клиента)

Это уже позволяет посчитать: вклад в покрытие, CAC/CPA, LTV “в первом приближении”, LTV/CAC, окупаемость.

Ключевой выбор: “по оплате” или “по отгрузке” (и почему это не мелочь)

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

Нужно выбрать базовую ось времени, иначе вы получите «пляшущую» маржу:

По оплате (cash basis): удобно для cashflow и окупаемости.

По отгрузке/оказанию услуги (accrual-ish): лучше отражает экономику продукта.

Для старта чаще выигрывает “по оплате” + отдельная корректировка на возвраты/отмены. Важно не идеальное, а стабильное правило, которое вы понимаете и соблюдаете.

Типовые ловушки данных (и как их обезвредить)

1) Возвраты и отмены живут отдельно от выручки

Если выручка считается брутто, а возвраты в другом месте – модель будет «слишком оптимистичной». Решение: считать нетто-выручку как базу или явно вычитать возвраты.

2) Комиссии и эквайринг учитываются дважды (или ни разу)

Маркетплейсы и платёжные провайдеры умеют запутывать. Решение: сделать таблицу “какая комиссия где уже включена”.

3) Канал привлечения теряется на полпути

Реклама даёт лиды, CRM видит сделки, а банк видит деньги – и это три разных вселенных. Решение: дисциплина UTM и единый идентификатор (хотя бы order_id / client_id).

4) “Средний чек” скрывает реальность ассортимента

Один товар прибыльный, другой убыточный, вместе они дают “среднее норм”. Решение: хотя бы раз в месяц смотреть юнит-экономику по группам SKU/услуг.

5) Переменные расходы маскируются под “просто операционку”

Поддержка, упаковка, обработка заказов – часто растут с объёмом и должны быть распределены на юнит. Решение: выделить переменную часть (пусть грубо) и включить в вклад в покрытие.

Контроль качества: правила, которые спасают модель от самообмана

Перед тем как доверять цифрам, полезны простые проверки:

Сверка с банком/кассой: нетто-выручка в модели должна “в целом” совпадать с реальными поступлениями (с поправкой на задержки).

Баланс юнитов: количество заказов в CRM ≈ количество оплат ≈ количество отгрузок (разницы объяснимы).

Диапазоны: стоимость доставки не может внезапно стать отрицательной, а комиссия – 40% там, где обычно 5% (аномалии почти всегда = ошибка данных).

Стабильность определения: если вы меняете, что считается “юнитом” или “выручкой”, это должно быть зафиксировано, иначе сравнение периодов становится фокусом.

ИИ здесь особенно полезен как автоматический “анти-бред фильтр”: он быстро ищет выбросы, несостыковки и логические дыры.

Как ИИ ускоряет сбор данных без магии

Важно: ИИ не достанет цифры из пустоты. Но он заметно ускоряет всё вокруг:

Составление списка полей: какие столбцы нужны для вашей модели (и какие лишние).

Нормализация: привести названия каналов к единому виду (“fb”, “facebook”, “meta” → “Meta Ads”).

Сопоставление: помочь связать таблицы по ключам и найти, где ключи ломаются.

Проверка формул: “если здесь считаем по заказу, то CAC тоже должен быть по заказу – иначе поправить”.

Сценарии: прогнать “что будет если” по вашим данным без ручной возни.

Если хотите метафору: ИИ – это стажёр-аналитик, который не устает, не спорит и обожает искать ошибки. Но взрослые решения всё равно на вас.