Вы читаете книгу «Юнит-экономика для роста: модель, сценарии и контрольные пороги» онлайн
Глава 1. Почему юнит-экономика «болит» и как ИИ снимает этот симптом
Юнит-экономика начинает болеть обычно в тот день, когда бизнес вроде бы «растёт», команда занята, лидов всё больше, выручка бодро ползёт вверх, а на счёте почему-то по-прежнему сквозняк. В этот момент предприниматель впервые чувствует, что бухгалтерская прибыль и реальная устойчивость компании живут в разных квартирах и общаются записками через дверь.
Бухгалтерия отвечает на вопрос «что было по итогам периода». Юнит-экономика отвечает на вопрос куда более практичный и, честно говоря, более нервный: «что происходит на уровне одной сделки, одного заказа, одного клиента – и можно ли это безопасно масштабировать». Когда вы понимаете экономику одной единицы, рост перестаёт быть азартной игрой и превращается в управляемую систему.
От бухгалтерской прибыли к экономике одной сделки: зачем это нужно бизнесу
Бухгалтерская прибыль любит итоговые суммы. Она терпеливо складывает доходы и расходы, распределяет амортизацию, закрывает периоды, отражает налоги. Это полезно, иначе государство и инвесторы будут смотреть на вас как на загадочное природное явление.
Юнит-экономика менее терпелива. Её интересует механика: сколько приносит один юнит и сколько он стоит. В простейшем виде это выглядит как разговор о маржинальном доходе и затратах на привлечение, но с правильной детализацией. Вы берёте не «продажи за месяц», а «один заказ», не «реклама за квартал», а «стоимость привлечения клиента в конкретном канале», не «прибыль компании», а «вклад одного клиента за весь срок жизни».
Если у юнита экономика «в плюс», вы имеете право масштабироваться. Если у юнита минус, рост превращается в ускоритель убытков: чем быстрее, тем громче.
Проблема «розовых очков»: почему мы склонны занижать расходы и завышать доходы
Юнит-экономика пугает не формулами. Она пугает тем, что заставляет признавать собственные когнитивные привычки.
Мы склонны:
записывать выручку полностью, а расходы частично;
считать «среднего клиента», забывая, что средний клиент часто не существует;
радоваться «дешёвому лиду» и не смотреть на долю оплат и возвраты;
закладывать удержание так, будто клиенты привязываются навсегда;
забывать про стоимость денег во времени, особенно когда возврат инвестиций растягивается.
Откуда берутся розовые очки? Из нормальной человеческой психики. Мы живём внутри своих надежд, и бизнес у нас тоже внутри надежд. Юнит-экономика снимает эти очки не грубо, а просто фактами: куда реально уходят деньги, какие клиенты реально остаются, какие каналы реально окупаются.
ИИ как инструмент беспристрастного аудита: цифры не имеют чувств
Здесь и появляется практичная роль ИИ. Он не заменяет финансового директора и не магически делает модель истинной. Он делает другое: превращается в «адвоката дьявола», который системно ищет дырки в допущениях.
ИИ полезен, когда вы:
сводите данные из разных источников и боитесь пропустить переменную;
пытаетесь честно разнести расходы по каналам и продуктам;
проверяете логику формул и взаимосвязей в модели;
хотите быстро перебрать сценарии и увидеть, где модель ломается.
У ИИ нет самолюбия. Ему не обидно, что ваш любимый канал убыточен. Ему не нужно защищать прошлые решения. Он спокойно показывает: «Если считать вот так, получается вот это».
Скорость расчёта: почему ручной сбор данных в Excel убивает актуальность
Excel сам по себе не виноват. Виноват процесс, когда таблица становится местом археологических раскопок: каждый раз вы вручную вытаскиваете цифры из рекламных кабинетов, CRM, банковских выписок, складской системы, а потом долго спорите с командой, почему «в этом месяце конверсия странная».
Ручная юнит-экономика почти всегда опаздывает. А когда модель опаздывает, бизнес начинает принимать решения по прошлому. Рынок уже поменялся, ставки в рекламе уже другие, логистика уже подорожала, возвраты уже выросли, а вы ещё сводите табличку.
ИИ не обязан жить внутри Excel. Он может ускорять сбор и проверку: подсказать, какие поля нужны, где несостыковки, какие значения выбиваются из нормы. Скорость важна не ради красоты отчёта. Она нужна, чтобы управлять на текущих данных, а не по воспоминаниям.
Роль ИИ в поиске «скрытых» переменных, которые мы забываем учесть
Почти каждая первая модель юнит-экономики выглядит слишком хорошо. Обычно потому, что в неё забыли положить часть расходов или «сложные» события.
Часто забывают:
возвраты, отмены, невыкуп, рекламации;
комиссии, эквайринг, платёжные шлюзы, сборы маркетплейсов;
переменную часть поддержки и операционных процессов;
скидки, промокоды, бонусы и их влияние на маржу;
влияние ассортимента: часть товаров тащит прибыль, часть – тянет вниз;
перераспределение постоянных затрат, когда объём падает.
ИИ хорош тем, что умеет задавать неприятные вопросы. Он может пройтись по списку типовых статей, сопоставить с вашей моделью и сказать: «Эти строки отсутствуют. Они точно не нужны?» В половине случаев они нужны.
Почему юнит-экономика – это не «разовый расчет», а непрерывный процесс
Бизнес, который делает юнит-экономику один раз, похож на человека, который один раз взвесился и решил, что теперь можно больше никогда не смотреть на весы. Экономика меняется постоянно: каналы выгорают, конверсия плавает, продукт развивается, конкуренты меняют цены, меняются налоги и тарифы поставщиков.
Поэтому юнит-экономика – это не документ, а система наблюдения. У неё должен быть ритм: еженедельная проверка ключевых показателей, ежемесячный пересмотр допущений, квартальные стресс-тесты сценариев. ИИ помогает сделать этот ритм реалистичным, потому что снижает цену рутины.
ИИ-детектор: когда бизнес масштабирует убытки вместо прибыли
Самая опасная ситуация выглядит так: вы видите рост, команда чувствует драйв, рекламные кабинеты светятся цифрами, продажи идут, а прибыль не растёт. Иногда она даже падает.
Классические признаки масштабирования убытков:
доля платного трафика растёт, а маржа «проседает»;
средний чек держится, но возвраты и отмены растут;
стоимость привлечения повышается, а удержание не улучшается;
окупаемость растягивается, кассовые разрывы становятся нормой;
«лучшие» клиенты уходят быстрее, чем вы успеваете это заметить.
ИИ здесь полезен как система раннего предупреждения. Он может отслеживать динамику показателей и подсвечивать моменты, когда один параметр начинает незаметно разрушать всю конструкцию. Не потому что он мистический пророк, а потому что он дисциплинированно смотрит на цифры без усталости.
Юнит-экономика для не-математиков: как ИИ переводит формулы на язык решений
Формулы пугают, пока они выглядят как заклинания. Когда вы связываете их с управленческими решениями, страх уменьшается.
Например:
CAC – это не «расходы на рекламу». Это цена права познакомиться с клиентом.
LTV – это не «красивая оценка будущего». Это предел того, сколько вы можете позволить себе тратить на привлечение и обслуживание.
Маржинальность – это не «процент для отчёта». Это кислород, которым дышит рост.
ИИ можно использовать как переводчика: «Объясни, что будет с окупаемостью, если CAC вырастет на 20%», «покажи, какая метрика даёт самый сильный эффект», «какой параметр нужно улучшить первым, чтобы модель стала устойчивой». В этот момент формулы начинают работать на вас, а не против вас.
Визуализация разрывов: где заканчивается маркетинг и начинается реальная маржа
Одна из причин, почему юнит-экономика кажется конфликтной, в том, что маркетинг любит верх воронки, а финансы любят низ. У первых язык лидов и кликов, у вторых язык маржи и денежного потока.
Визуализация разрывов помогает прекратить спор и начать видеть систему. Полезно рисовать не таблицы ради таблиц, а цепочку:
клик → лид → оплата → валовая маржа → переменные расходы → вклад в покрытие → окупаемость.
На этой цепочке сразу видно, где происходит магия самообмана: лиды дешёвые, но оплаты редкие; оплаты есть, но возвраты съедают маржу; маржа вроде бы нормальная, но доставка и комиссии превращают её в тонкую плёнку. ИИ может помогать строить такие цепочки и объяснять, где именно провал.
Артефакт: «Тест на адекватность» – готов ли ваш бизнес к расчету юнита
Перед тем как строить модель, полезно пройти короткий тест. Он не про идеальность данных, он про то, сможете ли вы отличить реальность от желания.
Пройдите по пунктам и ответьте честно «да» или «нет»:
Вы можете назвать, что именно является вашим юнитом: заказ, клиент, подписка, проект, поездка, урок.
У вас есть понятная формула выручки на юнит и вы знаете, где взять цифры без ручной охоты по чатам.
Вы понимаете переменные расходы на юнит: себестоимость, логистика, комиссии, эквайринг, упаковка, бонусы, поддержка.
Вы можете посчитать CAC не «в целом», а по основным каналам, хотя бы грубо, с включением сопутствующих затрат.
Вы знаете, что происходит после первой покупки: повторные покупки, продления, апсейлы, отток.
Вы учитываете возвраты, отмены и невыкуп как нормальную часть модели, а не как «в этот раз не повезло».
Вы готовы пересматривать допущения раз в месяц и не воспринимаете модель как разовую презентацию.
Вы согласны увидеть неприятные числа и менять решения, а не только формулировки в отчёте.
Вы можете назвать один показатель, который сейчас вызывает у вас наибольшее сомнение.
У вас есть владелец процесса: человек, который отвечает за модель, обновление и выводы, а не «у нас у всех по чуть-чуть».
Если у вас много «нет», это не приговор. Это стартовая диагностика. Слабые ответы показывают не «плохой бизнес», а то, где вы пока действуете на ощупь. И это как раз тот случай, когда ИИ может стать ускорителем: помочь собрать недостающие переменные, привести данные в порядок, проверить логику и превратить юнит-экономику из пугающего документа в спокойный прибор на панели управления.
Юнит-экономика перестаёт болеть, когда вы перестаёте от неё прятаться. Она не требует гениальности. Она требует честности, регулярности и готовности заменить надежду на систему.
Глава 2. Выбираем «юнит»: один объект, который объясняет весь бизнес
Юнит-экономика начинается не с формул, а с выбора того, что именно вы считаете. Это неожиданно философский момент: вы выбираете единицу реальности, через которую будете смотреть на бизнес. Ошиблись – и дальше можно идеально считать идеально бессмысленное.
Юнит – это минимальная «единица сделки/ценности», которую можно посчитать, сравнить и масштабировать. Идеальный юнит должен быть:
повторяемым (таких событий много),
связанным с выручкой (в нём живут деньги),
связанным с затратами (в нём живут реальные издержки),
достаточно стабильным, чтобы не менять определение каждую неделю.
Юнит ≠ продукт: где часто путаются
Продукт – это то, что вы продаёте. Юнит – это то, как продаётся и как потребляется ценность.
Пример: вы продаёте «курс». Юнитом может быть:
клиент (окупаемость привлечения и жизнь клиента),
продажа курса (одна транзакция),
месяц подписки (если курс в подписочной модели),
урок/занятие (если важна нагрузка и себестоимость преподавателя),
когорта (если вы запускаете потоки и сравниваете их между собой).
Если выбрать юнит «продажа курса», вы хорошо увидите маржу на сделку. Если выбрать «клиент», вы увидите, сколько денег приносит человек за весь цикл (докупает ли он, остаётся ли, возвращается ли). Для решения «масштабироваться или нет» часто важнее именно клиент, а не транзакция.
Типовые юниты по бизнес-моделям
Чтобы не изобретать велосипед с квадратными колёсами, вот рабочие варианты:
E-commerce / розница
заказ (order) – классика для маржи и логистики;
клиент – если есть повторные покупки;
SKU/товарная единица – если ассортимент сильно влияет на прибыльность.
Маркетплейсы
заказ и продавец как две оси: экономика может быть плюсовой на заказ, но минусовой на привлечение и удержание продавцов (или наоборот).
SaaS / подписка
аккаунт/компания (account) – особенно в B2B;
пользователь (seat) – когда цена за место;
месяц подписки – когда важно удержание и churn (отток).
Услуги / агентства / консалтинг
проект или часы (billable hours);
иногда клиент – если есть повторяемость проектов.
Доставка / логистика / такси
поездка/доставка – естественный юнит;
иногда курьер/водитель как отдельный «юнит поставки» (если узкое место – исполнители).
EdTech
студент (LTV по человеку);
курс/поток (когортный анализ);
урок/занятие (себестоимость преподавания и нагрузка).
Контент / медиа
подписчик;
показ / тысяча показов (CPM-юнит) – если монетизация рекламная;
лид (если медиа – воронка).
Как понять, что вы выбрали неправильный юнит
Есть несколько симптомов (почти как у простуды, только лечится не чаем, а сменой модели):
Юнит не бьётся с кассой. По модели «всё отлично», а денег нет – значит вы считаете не то событие или упускаете крупную статью затрат.
Юнит слишком крупный. «Юнит = бизнес-направление» – это не юнит, это отчёт на совете директоров.
Юнит слишком мелкий. «Юнит = клик» – красиво для маркетинга, но от клика до денег слишком длинная цепь, вы теряете экономический смысл.
Юнит не повторяется. Если каждый юнит уникален (как снежинка), сравнивать и оптимизировать сложно.
Юнит не управляем. Если на ключевые параметры юнита вы не можете влиять решениями, модель превращается в гадание.
Один бизнес – несколько юнитов: когда это нормально
Иногда нужен «основной» юнит и пара вспомогательных.
Пример: подписочный сервис. Основной юнит – аккаунт/месяц подписки, но вам также может понадобиться:
лид (для анализа воронки),
запрос в поддержку (для оценки операционной нагрузки),
активный пользователь (для продуктовых метрик).
Главное – не превращать модель в зоопарк. Один главный юнит должен оставаться центром: именно на нём вы принимаете решения «куда вкладывать деньги» и «что масштабировать».
ИИ-метод: как быстро найти правильный юнит без религиозных споров
Спор о юните часто выглядит так: маркетинг хочет считать лид, продажи – сделку, финансы – клиента, продукт – активного пользователя. Все правы, но по-своему.
ИИ можно использовать как «модератора здравого смысла»:
Сформулировать цель решения: что мы хотим оптимизировать (прибыль, рост, окупаемость, cashflow).
Попросить ИИ предложить 3–5 вариантов юнита и объяснить, какие управленческие решения каждый поддерживает.
Для каждого варианта попросить список обязательных данных (что нужно измерять).
Выбрать юнит, по которому данные реалистично собирать регулярно, а выводы будут напрямую влиять на действия.
Важный момент: ИИ не должен «угадывать за вас». Он ускоряет перебор вариантов и проверку логики, но выбор юнита – это управленческое решение, связанное с вашей моделью монетизации.
Мини-чеклист: «Юнит выбран правильно, если…»
Юнит выбран хорошо, если вы можете честно ответить «да» на эти утверждения:
По юниту можно посчитать выручку и переменные затраты без шаманства.
По юниту можно посчитать стоимость привлечения (CAC) или хотя бы связать с маркетинговыми затратами.
Юнит имеет понятный жизненный цикл (покупка → повтор → отток/завершение).
Юнит сопоставим между периодами и каналами.
Улучшение метрик юнита приводит к улучшению реальных денег, а не только отчётов.
Артефакт: «Матрица выбора юнита» (быстрый шаблон)
Сделайте табличку (на бумаге, в Notion, в Excel – не важно) с колонками:
Вариант юнита
Что он объясняет лучше всего
Какие решения поддерживает
Какие данные нужны
Где взять данные
Риски/слепые зоны
И заполните для 3–4 кандидатов. Обычно после этого спор заканчивается сам, потому что становится видно: один вариант «красивый», но данных нет; другой «не модный», зато управляемый и связанный с деньгами.
Если первая глава была про то, почему юнит-экономика вообще важна, то эта – про правильный «объектив камеры». В следующей логике мы уже пойдём в базовые метрики (выручка, маржа, CAC, LTV) и то, как ИИ помогает собрать их так, чтобы модель не разваливалась при первом столкновении с реальностью.
Глава 3. Каркас юнит-экономики: метрики, без которых модель – фанфик
Юнит выбран. Отлично. Теперь нужно построить каркас – набор метрик, которые удерживают модель в реальности, как ребра удерживают грудную клетку (романтично, но полезно). Проблема большинства «юнит-табличек» не в том, что люди не умеют делить одно на другое. Проблема в том, что они считают не те вещи или считают их не в том месте воронки.
Каркас юнит-экономики – это несколько базовых величин и связи между ними. Они кажутся банальными, пока вы не начнёте принимать решения на миллионы, опираясь на цифры, которые «примерно похожи».
Скелет: из каких блоков состоит юнит-экономика
В любой модели почти всегда есть четыре слоя:
Выручка с юнита: сколько денег приходит.
Переменные затраты на юнит: сколько денег уходит из-за этого юнита.
Стоимость привлечения / продажи: сколько стоит получить юнит (или клиента).
Повторяемость / удержание: как долго юнит «живёт» и сколько раз повторяется.
Вокруг этих слоёв строятся остальные метрики и все «а давайте масштабироваться».
Выручка: не «сколько мы продали», а «сколько остаётся после реальности»
Для начала: выручка в юнит-экономике – это не всегда то же самое, что выручка в отчёте. Потому что нас интересует чистая выручка, которая реально привязана к юниту.
Что часто нужно учитывать сразу:
скидки и промокоды;
бонусы/кэшбек как недополученная выручка;
возвраты и отмены (лучше считать нетто).
Если вы считаете «грязную» выручку, а возвраты живут в другой вкладке, модель начнёт врать так уверенно, что ей можно будет выдавать паспорт.
Валовая маржа и вклад в покрытие: два разных зверя
Валовая маржа (Gross Margin) – это выручка минус себестоимость (COGS: cost of goods sold).
В e-commerce сюда обычно входят закупка/производство товара, упаковка, переменная логистика (иногда спорно), комиссии, эквайринг – в зависимости от вашей трактовки.
Но для управления часто важнее вклад в покрытие (Contribution Margin):
это выручка минус все переменные расходы, которые возникают из-за юнита.
Почему это важно? Потому что вклад в покрытие показывает, сколько денег остаётся, чтобы оплатить постоянные расходы (команда, офис, аренда, разработки) и всё-таки заработать.
Типичная ошибка: считать только валовую маржу и радоваться, не заметив, что переменные комиссии/доставка/поддержка съели половину.
CAC: стоимость привлечения (и почему она всегда выше, чем хочется)
CAC (Customer Acquisition Cost) – стоимость привлечения клиента.
Иногда считают CPA (cost per action) или CPO (cost per order) – стоимость заказа. Это нормально: зависит от того, ваш главный юнит – клиент или заказ.
Главная проблема CAC: люди включают туда только рекламный бюджет. А потом удивляются, что «по модели окупаемся», хотя реальная экономика как-то не согласна.
Что часто забывают в CAC:
зарплаты маркетинга и агентств (хотя бы частично);
расходы на креативы/продакшн;
CRM, коллтрекинг, сервисы;
скидки «на первую покупку» (это тоже цена привлечения, просто замаскирована);
работа отдела продаж, если он участвует (особенно B2B).
Практичное правило: если расход существует только потому, что вы привлекаете клиентов – он должен попасть в CAC/CPA (или хотя бы в отдельную строку, чтобы не терялся).
LTV: сколько ценности приносит клиент, пока не исчезнет в туман
LTV (Lifetime Value) – жизненная ценность клиента: сколько валовой/вкладной маржи приносит клиент за весь срок жизни.
Есть два популярных подхода:
исторический LTV: считаем по фактическим данным когорты (лучше, но нужен срок наблюдения);
прогнозный LTV: строим модель на удержании, среднем чеке, частоте покупок (быстрее, но легко самообмануться).
Важный нюанс: LTV бывает по выручке и по марже. Управленчески полезнее LTV по марже, потому что именно маржа платит зарплаты и аренду, а не красивая выручка.
LTV/CAC и срок окупаемости: два лаконичных теста на здравомыслие
Когда модель уже собрана, есть два сверхпрактичных теста:
LTV/CAC – отношение жизненной ценности к стоимости привлечения.
Если у вас LTV/CAC < 1, вы покупаете клиентов дороже, чем они приносят. Это не «стратегия», это просто способ быстро потерять деньги.
Payback Period – срок окупаемости привлечения.
Даже если LTV высокий, он может быть размазан по времени так, что бизнес умрёт от кассового разрыва раньше, чем «окупится в теории».
Люди часто фокусируются на LTV/CAC и забывают про окупаемость. А cashflow, как водится, не читает ваши презентации.
Retention и churn: удержание и отток как гравитация модели
Retention – доля клиентов, которые остаются/возвращаются.
Churn – доля, которые уходят.
Для подписки churn – король. Для e-commerce важнее частота повторных покупок и «окно» возвращения клиента.
ИИ полезен здесь тем, что может:
быстро строить когортные таблицы (если дать данные);
находить аномалии: «почему у когорты ноября retention резко хуже?»;
предлагать гипотезы (но не путать с фактами): сезонность, изменения цены, качество, логистика.
Конверсия воронки: от клика до денег (и где исчезает магия)
Юнит-экономика рушится, когда вы считаете CAC на клике, а LTV на клиенте, и между ними пустота. Нужна воронка:
показы → клики → лиды → квалифицированные лиды → оплаты → повтор → удержание.
В каждом шаге есть конверсия. Маленькое падение на раннем этапе может уничтожить экономику целиком.
ИИ может быть «детектором протечек»: он помогает визуально и логически проверить, что числа связаны правильно и нигде не подставлена конверсия «из головы».
Переменные vs постоянные: почему важно не путать
Юнит-экономика в строгом виде любит переменные расходы. Но бизнес живёт ещё и постоянными, поэтому нужен мостик:
вклад в покрытие на юнит
× количество юнитов
= покрытие постоянных + прибыль
Если вклад в покрытие маленький, вам нужно слишком много юнитов, чтобы просто выйти в ноль. И это важный вывод: иногда проблема не в маркетинге, а в самой структуре продукта/себестоимости.
ИИ как «проверяльщик логики»: типовые ошибки формул
Вот ошибки, которые ИИ может ловить почти автоматически, если вы даёте ему модель или таблицу:
смешали выручку брутто и нетто в разных местах;
посчитали маржу на заказ, а CAC – на клиента, не связав повторные заказы;
забыли возвраты/отмены или учли их дважды;
учли комиссию маркетплейса и эквайринг одновременно, хотя эквайринг уже внутри комиссии (бывает);
берёте среднее по больнице вместо когорт (LTV выходит «красивым», но неработающим);
не разделили каналы: один канал тянет модель вверх, другой вниз, а в среднем «норм».
ИИ не волшебник, но он отличная «машина для нахождения несостыковок».
Артефакт: минимальный набор метрик для первой рабочей модели
Если вы строите модель впервые, не нужно сразу пытаться объять вселенную. Достаточно собрать минимальный комплект:
Цена / средний чек (AOV) или ARPU (выручка на пользователя)
Нетто-выручка (с учётом скидок и возвратов)
COGS / себестоимость на юнит
Переменные комиссии/логистика/эквайринг/поддержка
Вклад в покрытие на юнит
CAC (или CPA/CPO) по основным каналам
Повторяемость: частота покупок или retention/churn
LTV по марже (хотя бы грубо)
LTV/CAC
Payback period
С этим набором вы уже сможете ответить на главный вопрос: каждый новый юнит делает нас богаче или беднее?
Эта глава – про «скелет». Дальше обычно начинается самое интересное: данные и реальность. Следующая логика – как собрать входные данные, не утонуть в хаосе источников, и как с помощью ИИ автоматизировать часть рутины так, чтобы модель обновлялась регулярно, а не по праздникам.
Глава 4. Данные: где взять цифры и как не построить модель из воздуха
Юнит-экономика ломается не потому, что формулы сложные. Она ломается потому, что входные данные – грязные, неполные, из разных миров и часто противоречат друг другу. И это нормально: бизнес – не лаборатория, а живой организм, который постоянно что-то меняет, забывает и делает «как получится».
Задача этой главы – превратить «хаос источников» в понятный поток: что именно собирать, откуда, как часто и с какими проверками, чтобы модель оставалась в реальности.
Три уровня данных: идеал, рабочий минимум и “хоть что-то”
Есть соблазн сказать: «Сначала настроим идеальную аналитику, потом посчитаем юнит». Это ловушка. Вы не обязаны быть NASA, чтобы понять, прибыльны ли вы.
Удобно мыслить тремя уровнями зрелости:
Рабочий минимум – хватает, чтобы принимать решения по каналам и продуктам.
Хороший уровень – можно оптимизировать удержание, когорты, сезоны, точнее прогнозировать.
Идеал – красиво, автоматизировано, почти без ручного труда. Но это не стартовая точка.
Самый полезный принцип: сначала модель на минимуме, потом улучшение точности там, где это влияет на решения.
Карта источников: где обычно лежат нужные цифры
Юнит-экономика почти всегда собирается из пяти «континентов»:
Продажи / транзакции
касса / банк / платёжный провайдер
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 тоже должен быть по заказу – иначе поправить”.
Сценарии: прогнать “что будет если” по вашим данным без ручной возни.
Если хотите метафору: ИИ – это стажёр-аналитик, который не устает, не спорит и обожает искать ошибки. Но взрослые решения всё равно на вас.
Ритм обновления: как часто считать и что пересматривать
Юнит-экономика превращается в инструмент, когда у неё есть регулярность:
Еженедельно: расходы по каналам, 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 дней – это не «вся жизнь клиента». Но это уже честная опора для решений сегодня.
Как помогает ИИ
быстро строит когорты и расчёты (если дать выгрузку);
находит аномальные когорты и предлагает гипотезы причин;
