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