Написать эту статью я решил после того, как увидел ожесточенные споры о юнит-экономике в паре тематических чатов в Телеграме, а потом еще и наткнулся на целые консалтинги и курсы по этой самой юнит-экономике. И на калькуляторы еще. Вообще у меня складывается стойкое ощущение, что многие зачем-то усложняют всю историю с юнит-экономикой и спорят в основном о терминах, хотя для абсолютного большинства эти тонкости и терминологические споры ни к чему и только усложняют понимание.
При этом понимать, что такое юнит-экономика и уметь ее считать, конечно, полезно. Так уж сложилось, что о ней говорят в основном в стартап мире, так что, надеюсь, статья облегчит понимание хабровчанам — применимо это все не только для стартапов, но и для собственных pet-проектов да и вообще для понимания — вот что сейчас делать: вкидывать больше денег в рекламу или тормозить продвижение, дорабатывать продукт, переосмысливать бизнес-модель и т.д.
Если коротко:
Юнит-экономика характеризует, сколько бизнес зарабатывает или теряет на одном юните.
Юнит — это базовая единица, генерирующая доход, и у каждого бизнеса она своя.
Как посчитать юнит-экономику
Определить юнит.
Посчитать, сколько прибыли или убытков этот юнит принес. Важно учесть все расходы и доходы, связанные с юнитом.
Вот и всё, этого достаточно.
Дальше — несколько деталей для иллюстрации.
Что такое юнит
Зависит от бизнеса. Не ищите общих правил и не смотрите на других. Ориентируйтесь на здравый смысл и особенности именно вашего бизнеса.
Очень мне хотелось привести какой-то универсальный и при этом актуальный для Хабра пример, но понял, что не получится — нюансы есть, а вот сложного ничего нет. Главное понять, что:
Юнит — базовая, генерирующая доход единица, которую вы можете и хотите масштабировать.
Если производите и продаете товар, юнит — это единица продукции. Если подписная модель или частые повторные покупки, юнит — клиент. Консалтинговые услуги — контракт. Аутсорс/аутстафф с продажей ресурсов по часам — человеко-час. И т.д.
Тут могут быть нюансы, потому что бизнесы разные. Предположим, вы производите и продаете оборудование, причем само оборудование продаете в убыток, а зарабатываете на услуге пусконаладки. В таком случае юнитом будет контракт на поставку оборудования с сервисом.
Если же заключаете договор на обслуживание оборудования с ежегодной пролонгацией, то логичнее будет в качестве юнита взять клиента.
Так юнит — предмет сделки или клиент?
Можно заметить, что все случаи классифицируются на два подхода:
Юнит — предмет сделки.
Юнит — клиент: покупатель или пользователь.
Подход 1. Юнит — предмет сделки
В этом случае расчет юнит-экономики сводится к расчету маржинальной прибыли. Маржинальная прибыль — разница между выручкой от продажи единицы продукции и затратами на производство/закупку и продажу этой единицы. Так мы понимаем: прибыльно ли продаем один юнит?
Подход 2. Юнит — клиент
В таком случае юнит-экономика — отношение прибыли, которую принесет клиент за все время, к стоимости привлечения этого клиента. То есть здесь речь об LTV (lifetime value, пожизненная ценность клиента) и CAC (customer acquisition cost, стоимость привлечения клиента). Так мы понимаем: приносит ли клиент прибыли больше, чем мы тратим на его привлечение?
Если внимательно посмотрите на картинки выше, поймете: принципиальных отличий между ними нет — они об одном и том же. Просто в первом случае расходы на маркетинг сразу учли в расчете маржинальной прибыли, а во втором — вынесли их отдельно и назвали CAC. В транзакционной модели проще все включить в транзакцию, а в клиентской — смотреть отдельно, так как они разнесены по времени. Во втором случае это еще и помогает оценить разницу во временной стоимости денег, так как затраты на привлечение клиента мы понесли сегодня, а «отобъем» их только через несколько месяцев.
В любом случае существенных различий в расчетах нет — всегда считаем все расходы и доходы, напрямую связанные с юнитом. Отличается скорее итоговое представление: маржинальная прибыль или отношение LTV/CAC.
Выбирайте, как вам больше нравится, но принципиально первый подход более актуален для оффлайновых бизнесов с физическим продуктом, а второй — для цифровых продуктов, подписок, частых повторных покупок, сервисных моделей с предсказуемым сроком жизни клиента и прибылью.
Звучит сложнее, чем на самом деле. Руководствуйтесь здравым смыслом, и все будет понятно.
Считаем расходы и доходы, связанные с юнитом
Вне зависимости от подхода, в расходы включаем все затраты, напрямую ассоциированные с юнитом. В доходы — выручку, которую он нам принес.
Не забываем про привлечение клиентов. Сколько денег тратим, чтобы привлечь покупателя, продать ему что-то. Предположим, мы производим и продаем некие девайсы, то есть юнит — этот девайс. Придется сколько-то денег вложить в продвижение, чтобы девайс продать: в рекламу, SEO, комиссии партнерам и пр. Если продаем девайсы в оффлайне, нужен магазин или арендованное место в чужом магазине, а также продавцы.
Чтобы девайсы продать, нужны и сами девайсы, а значит, необходимо их произвести. Чтобы произвести, потребуется арендовать помещение, закупить компоненты, оплатить труд конструкторов, инженеров, разработчиков, тестировщиков, упаковать, где-то эти девайсы хранить. А потом еще доставить, настроить и запустить и т.д.
Это что касается расходов. А с доходами вроде все понятно, расписывать не буду.
Главное не забывайте: если в «транзакционной» модели выручку и, соответственно, прибыль мы считаем от одной транзакции, то в «клиентской» прибыль берем за все время жизни клиента.
В общем, открываете Эксель и вносите туда все расходы и доходы бизнеса на один юнит. Вот это и есть юнит-экономика. Все просто.
То есть речь о постоянных и переменных затратах?
Действительно, в расчет принимаем переменные затраты, то есть те, которые изменяются в зависимости от объема производства и реализации.
Но помните, что точной классификации затрат на постоянные и переменные не существует: что для одного бизнеса переменные, то для другого — постоянные.
Поэтому я рекомендую думать не о терминах, иначе можно уйти в терминологические размышления и споры, а о сути — относится ли конкретный расход в вашем конкретном случае к юниту, или нет.
Боюсь уйти в неинтересные и ненужные детали, поэтому более детально о терминах, постоянных и переменных затратах и расчете маржинальной прибыли — в расширенной версии статьи.
А как же ARPU, ARPA, MRR, ARR, ACV, AOV, COGS и прочие умные слова, которыми кишат статьи о юнит-экономике?
Не парьтесь :) Если коротко, то это разные показатели, отражающие указанное выше и/или раскладывающее его на составляющие. Они нужны не для понимания и расчета юнит-экономики, а чтобы говорить на одном языке с другими, но, если вы считаете для себя, это не столь принципиально.
Опять же не стоит фокусироваться на терминах, иначе можно уйти в споры об их трактовке. Например: а надо ли относить аренду производственного помещения к COGS (себестоимость проданной продукции) или не надо, ну и т.д.
Не думайте о терминах, а руководствуйтесь целями и здравым смыслом. Заносите все расходы и доходы, напрямую связанные с юнитом. Возможно, это не будет формально корректно, зато будет отражать вашу реальность.
Но стоит помнить некоторые нюансы расчета юнит-экономики:
Экономика разная для разных каналов и сегментов. Запросто может произойти (и, как правило, происходит), что на трафике из Фейсбука сходится, а из Директа — нет. То же самое касается клиентских сегментов: с одними все хорошо, с другими — не очень.
Когорты. Когорта — группа клиентов, которую мы получили в определенном периоде. Экономика может сходиться для клиентов, которые пришли в октябре, а для ноябрьских — почему-то нет. Хотя когорты — это понятие, относящееся к пользователям, подход применим и к товарам и к другим юнитам. Юнит-экономика для елок в декабре прекрасная, а вот в январе что-то совсем… ну такая. Самый очевидный фактор здесь — сезонность, хотя и не только.
Учитываем только реализованную продукцию или оказанные услуги. Вносите расходы и доходы, связанные именно с проданными единицами продукта. Если купили компонентов на двести девайсов и оплатили производство тоже двухсот, но продали всего сто, учитываем расходы только на эти сто девайсов.
Считаем только то, что относится к юниту. Если продавец полдня продает девайсы, а еще полдня помогает в другом бизнесе, пишем сюда ту часть его зарплаты, которая связана с продажей девайсов.
Речь о реализации, а не денежных потоках. Записываем не кэшфлоу (денежный поток), то есть не фактическое движение денежных средств по счетам, а именно «виртуальные» деньги в том периоде, когда был продан товар или оказана услуга. Даже если оплатили компоненты и производство в октябре, а деньги от продаж через дистрибьютора придут в декабре, учитываем в ноябре, если продали девайсы в ноябре.
Зачем это все
Как правило, юнит-экономику считают, чтобы понять, насколько устойчив бизнес и можно ли его масштабировать, и именно поэтому в качестве юнита выбирают то, что хотят масштабировать.
Наша задача — понять одну простую вещь: зарабатываем мы или теряем на одном юните. Помимо собственно понимания эффективности бизнеса, это можно использовать при планировании: если юнит-экономика сходится, значит можем масштабировать и больше зарабатывать. Если же юнит-экономика отрицательная, то масштабировать будем убытки. А этого мы не хотим.
Кроме того, сам процесс расчета раскладывает экономику бизнеса на компоненты — конкретные статьи расходов и доходов — так проще понять, что на нее влияет, и в итоге — управлять.
Самое главное
Помним, что задача — рассчитать доходы и расходы, связанные с одним юнитом, и сделать это в целях масштабирования.
Если мы начнем относить к расходам на юнит то, что на самом деле с ним не связано, рискуем ошибочно получить отрицательный результат и сделать вывод, что масштабировать ничего не можем, хотя на самом деле это не так.
Справедливо и обратное: если не учтем в затратах на юнит то, что к ним на самом деле относится, рискуем масштабировать убытки.
Итого
Держите в голове цель — масштабировать бизнес — и относите к расходам и доходам на юнит только то, что реально относится к юниту в соответствии с бизнес-моделью.
Не особенно переживайте о терминах, если считаете для себя.
Не усложняйте. Если откинуть универсальные калькуляторы с терминологическими спорами и просто посчитать, станет понятно: юнит-экономика — это просто.
