Содержание за 15 секунд:
1. Содержание терминов unit-экономики разное в разных компаниях. Прочитав эту статью, вы поймете общий принцип расчетов, и сможете распространить на любой проект.
2. Нормальный файл для расчета по ссылке.

🖖 Говорят, что термин Unit-экономика и принцип ее расчета был предложен в России Ильей Красинским. Как по мне, это адаптация простых формул университетского курса про постоянные и переменные издержки, точку безубыточности или более сложного финансового анализа, к метрикам и реалиям цифрового мира. В том числе к метрикам мобильных приложений.

Что-то революционное? — Нет. Ближе к современному бизнесу? — Наверное.

🤑 В чем хорош подход? Он подсвечивает те метрики, от которых зависит успех бизнеса. Анализ чувствительности результата к ним покажет, какая из метрик больше влияет на прибыль.

👺 Но как обычную экономику за пределами бухучета все считают по-своему, так и unit-экономика оказалась у каждого своя. Это нормально, потому что бизнес-модели у всех разные: у кого-то пользователи и месячная подписка, у кого-то интернет-магазин с потоком заказов и т. п. Масла в огонь подливает разница в понятиях финансового учета в России и США и то, что эти понятия плохо состыковываются с уже закрепившимися финансовыми понятиями в digital.

😞 Первая боль — это беда с терминами. В пределах одного инструмента могут быть использованы разные названия одного параметра. Например, сначала вы называете покупателей Buyers, а потом Customer, а потом в аббревиатурах еще используете Paying User (ARPPU, Average Revenue Per Paying User). Revenue повсеместно мешается с Margin повсеместно.

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

💸 Третья боль — учет затрат, которые у нас принято относить к постоянным: зарплата менеджмента, продуктовых команд. Те деньги, объем которых не зависит напрямую от объема продаж. Про них часто забывают или учитывают в себестоимости, как переменные издержки. Так делать не стоит, они не зависят напрямую от объема продаж, цены.

👨‍🏫 Четвертая боль — обилие материала по теме с призывом разобраться за 15 минут. В разных источниках отличаются термины и определения, и сложно установить правду. Поэтому лучше включать свою логику. С ней, по крайней мере, будет понятно, как перейти в систему координат очередного автора.

Вот одна из трактовок. Она не единственно верная.

Термины

👨 Users — пользователи. Сколько вообще есть у вас зарегистрированных пользователей за период.

➡️ Коэффициент C1. Коэффициент конверсии из пользователей в покупатели.

🤑 Customers, или Buyers, Paying Users** — покупатели (Customers = Users × C1). Нам нужны именно уникальные покупатели, число людей.

💵 Average Price — средний чек (Revenue / Buyers). Эту метрику можно разбить далее на число товаров в корзине (icount) и среднюю стоимость (iprice) для того, чтобы отслеживать, как изменение этих параметров влияет на прибыль.

💸 COGS (Cost of Good Sold) — это затраты на проданные товары, что-то вроде себестоимости. Их можно разбить:

• 📌 COGS, % — затраты, которые зависят от цены продажи и относятся к единице продукции. Например, комиссия за электронную транзакцию, если она считается как процент к базе;
• 🧱COGS, vc  — переменные затраты, которые не зависят от цены продажи, но относятся к единице продукции. Например, себестоимость сырья;
• 1️⃣ 1sCOGS — дополнительные затраты на осуществление первой (и последующих) покупок. Например, купон на скидку для новых клиентов. Эти затраты не зависят ни от цены, но относятся к единице продукции.
• 💻 COGS, fix — затраты, относимые к постоянным. Они не зависят ни от цены, ни от объема продаж. Например, расходы на продуктовую команду.

Часто постоянные затраты при расчетах unit-экономики относят к переменным, относя их к прогнозной базе привлеченных пользователей. Однако в этом случае становится некорректным анализ чувствительности — изменения прибыли в зависимости от числа пользователей. Т. к. изменение числа пользователей приведет к другому значению постоянных издержек, приведенных к единице продукции.

💲 Payments per 1 Buyer или APC (Average Payment Count) — число платежей, которые в среднем делает покупатель за период.

💰 Revenue — выручка. Это то, сколько денег мы получили до вычета наших расходов (Revenue = Customers x Average Price x APC)

💳 AC (Acquisition Costs) — стоимость привлечения, то есть маркетинговый бюджет на привлечение новых пользователей.

❤️ CPA (Cost Per Acquisition) или CPU (Cost Per User) — стоимость привлечения одного пользователя (CPA = AC / Users).

👍 CM (Contribution Margin) — маржинальная/валовая прибыль. Ее как раз и считаем, и на ее основании оцениваем эффективность модели.

Как посчитать Прибыль?

Очевидно, что CM — это разница между Revenue и затратами. Формула для выручки была выше. Из чего складываются затраты:

• 📌 COGS,% × Customers × Average Price × APC — затраты, которые мы несем с каждой единицей продукции и которые зависят от цены;
• 🧱 COGS, vc × Customers × APC — затраты, которые мы несем с каждой единицей продукции;
• 1️⃣ 1sCOGS × Customers — затраты, которые мы несем с каждым пользователем при первой покупке;
• 💻 COGS, fix — просто постоянные затраты. Важно, что COGS, fix стоит брать за тот же период, за который рассчитывается APC.
• CPA × Users — затраты на привлечение, которые привяжем к пользователям.

В итоге получаем:

👍 CM = Customers × Average Price × APC  — (COGS,% × Customers × Average Price × APC + COGS,vc × Customers × APC + 1sCOGS × Customers + COGS,fix + CPA × Users) (1)

или

👍 CM = Users × (C1 × (APC × (Average Price × (1 — COGS,%) — COGS,vc) — 1sCOGS) — CPA) — COGS,fix (2)

зеленым — то, что удается заработать c одного пользователя, назовем эту цифру прибыль с пользователя (AMPU — Average Margin Per User).

Какой вывод напрашивается: объем — король. В пределе бесконечное число пользователей при положительном AMPU может покрыть любые постоянные затраты. В жизни это, конечно, не так, поскольку с ростом базы пользователей увеличивается CPA; увеличивается штат продаж и поддержки, то есть COGS, fix.

Пример

У нас есть интернет-магазин со следующими показателями, отнесенными к одному месяцу. То есть в случае с APC предполагаем, что клиент успевает купить указанное число раз в течение месяца.

• 👨 Users = 20 000

• ➡️ С1 = 2,15%

• 💵 Average Price = 2 000 руб.

• 💲 APC = 1,6

• 📌 COGS,% = 10% от цены на налоги и эквайринг

• 🧱 COGS,vc = 900 руб.

• 1️⃣ 1sCOGS = 50 руб.

• 💻 COGS, fix = 300 000 руб. на зарплату персоналу

• 💳 AC = 250 000 руб.

Подставляем в формулу
👍 CM = 20 000 × (2,15% × (1,6 × (2 000 × (1 — 0,1) — 900) — 50) — 12,5)  — 300 000 = 347 700 — 300 000 = 47 700 руб.

AMPU, то есть, сколько мы зарабатываем с одного пользователя с учетом всех затрат, кроме постоянных и затрат на привлечение:
AMPU = 2,15% × (1,6 × (2 000 × (1 — 0,1) — 900) — 50) = 29,89 руб.

AMPU (29,89) больше CPA (12,5 руб.), поэтому дальнейшее повышения числа пользователей при условии сохранения прежнего уровня постоянных затрат приведет к росту прибыли.

Проведем анализ чувствительности — как изменится CM, если изменить входные данные.

Сильнее всего в этом примере влияет Average Price. Так, ее снижение на 20% обрушивает экономику проекта к уровню — минус 200 тыс. руб. Практически не влияет изменение дополнительных затрат на совершение первой покупки — 1sCOGS.

Во всех ли примерах изменение Average Price будет оказывать наибольшее влияние, а изменение 1sCOGS — наименьшее? Нет. Все зависит от соотношения величин самих параметров.

Что влияет на Прибыль?

Вернемся к начальной формуле (1), заменив Customers = Users × C1:

👍 CM = Users × C1 × Average Price × APC  — (COGS,% × Users × C1 × Average Price × APC + COGS,vc × Users × C1 × APC + 1sCOGS × Users × C1 + COGS,fix + CPA × Users) (3)

Как быстро понять, прибыльный у нас проект или нет? Очевидно, что через сравнение выручки и затрат. В случае CM = 0 выручка равна затратам. Давайте разделим обе части на Revenue = Users × C1 × Average Price × APC и обозначим CM1 = CM/Revenue. Тогда из (3) получим:

👍 CM1 = 1 — COGS, % — COGS,vc / Average Price — 1sCOGS / (Average Price × APC) — COGS,fix / Revenue — CPA / (Average Price × APC × C1) (4)

Каждое из слагаемых в правой части «откусывает» от нашей выручки свою долю, уменьшая прибыль. Не только каждое из слагаемых должно быть меньше единицы, но и сумма слагаемых с отрицательным знаком для положительной прибыли должна быть меньше единицы.

Перепишем (4) в виде (5):

CM1 = 1 — E — D — C — B — A (5),
где A-E соответствующие коэффициенты. Например, A = CPA / (Average Price × APC × C1).

Подставив числа, получим, что наши затраты «съедают» 97% выручки. Действительно, CM / Revenue у нас равно 3,5%. При этом половина — это 🧱 COGS, vc

Если вы знаете коэффициенты A-E, вы знаете, на чем вы теряете больше всего.

Калькулятор юнит-экономики

Калькулятор юнит-экономики, повторяющий расчет, описанный в статье, — https://docs.google.com/spreadsheets/d/1BRkUs4UInWWK2Etm_70vaFiqCBaMjktNitXEsbRbSXc/. Чтобы задать свои параметры, скопируйте его к себе на Google Drive.

Это все. А дальше?

А дальше — усиление расчетов unit-экономики благодаря когоротному анализу и применению метода к разным временным периодам. Когороты, действительно, дают лучшее представление, что происходит с бизнесом, и где надо срочно чинить.