Юнит-экономика простыми словами: CM1, CM2

Коротко: Юнит-экономика — это ответ на вопрос «зарабатываем мы или теряем на одном заказе». В e-commerce за юнит удобнее брать один заказ (или одного клиента за период) и считать по нему цепочку contribution margin: CM1 = выручка минус себестоимость товара, CM2 = CM1 минус переменные операционные расходы (логистика, эквайринг, упаковка, возвраты), CM3 = CM2 минус привлечение (CAC). Если CM3 на первый заказ отрицательный — это норма для маркетплейса, но тогда юнит обязан выйти в плюс за счёт повторных покупок (retention), иначе бизнес горит на масштабе.

Дальше разложим каждый уровень на реальных числах, соберём таблицу юнит-экономики одного заказа и напишем SQL, который посчитает CM1/CM2/CM3 из сырых данных заказов.

Что такое юнит-экономика и что вообще считать за юнит?

Юнит-экономика — это экономика минимальной повторяемой единицы бизнеса. Идея простая: если один юнит приносит прибыль, то тысяча таких юнитов даст тысячу прибылей, и масштабирование имеет смысл. Если юнит убыточный, то чем больше вы растёте, тем быстрее теряете деньги — рост маркетинга только ускоряет падение.

Главный спор в e-commerce — что брать за юнит. Есть два рабочих подхода:

• Юнит = один заказ. Удобно, когда покупки нерегулярные и обезличенные: доставка еды, разовая электроника, товары, которые берут раз в год. Считаете маржу на заказ и смотрите, покрывает ли она привлечение.
• Юнит = один клиент за горизонт (LTV-подход). Нужен, когда важны повторные покупки: маркетплейс, товары повседневного спроса, подписочные боксы. Здесь один заказ может быть в минус, а клиент за 12 месяцев — в плюс.

Правильный ответ почти всегда «считаем оба среза». Заказ показывает операционную эффективность здесь и сейчас, клиент — окупаемость привлечения на горизонте. На собеседовании аналитика этот вопрос («что такое юнит и почему») любят задавать как проверку продуктового мышления — разбор продуктового кейса на собесе как раз про это.

Чем юнит e-commerce отличается от SaaS-юнита?

В SaaS всё крутится вокруг подписки: юнит — это клиент с ежемесячным платежом, а ключевые метрики — LTV, CAC, payback и отток. Себестоимость обслуживания почти нулевая: сервер стоит одинаково, обслуживает он 100 или 101 пользователя. Поэтому маржа высокая (70–85%), а вся драма — в удержании и сроке окупаемости привлечения. Если интересна именно SaaS-модель, есть отдельный разбор — LTV, CAC и payback в SaaS на практике.

E-commerce устроен иначе, и переносить SaaS-формулы сюда — типичная ошибка:

• Есть физическая себестоимость товара (COGS). Каждый проданный товар реально стоит денег, и это самая большая статья расходов. Валовая маржа часто 15–40%, а не 80%.
• Есть логистика и фулфилмент на каждый заказ. Сборка, упаковка, доставка, обработка возврата — переменные затраты, которые растут вместе с числом заказов.
• Возвраты бьют по марже дважды. Вы теряете и логистику туда-обратно, и часть товара (уценка, брак).
• Доход разовый, а не подписочный. Клиент может не вернуться, поэтому retention и частота покупок критичны для окупаемости CAC.

Вывод: в SaaS достаточно смотреть LTV/CAC, в e-commerce нужна цепочка contribution margin, где видно, на каком уровне юнит теряет деньги — на товаре, на логистике или на привлечении.

Отдельно стоит помнить про payback — за сколько месяцев повторные платежи возвращают CAC. В SaaS здоровым считается payback до 12 месяцев, и вся модель живёт на длинном хвосте подписки. В e-commerce аналог payback — сколько заказов должен сделать клиент, чтобы отбить стоимость своего привлечения; и если этот срок длиннее реального жизненного цикла клиента, юнит убыточный, сколько трафика ни лей.

Что такое contribution margin CM1, CM2 и CM3?

Contribution margin (маржинальная прибыль) — это то, что остаётся от выручки после вычета переменных затрат. «Переменные» — ключевое слово: аренда офиса и зарплата аналитика в юнит-экономику одного заказа не входят, они постоянные. В юнит попадает только то, что возникает из-за самого заказа.

Уровни считаются последовательно, каждый следующий вычитает новую группу расходов:

Выручка (нетто, без НДС и скидок)
  − Себестоимость товара (COGS)
= CM1  (валовая маржинальная прибыль)

CM1
  − Переменные операционные расходы
    (логистика, фулфилмент, эквайринг, упаковка, возвраты)
= CM2  (операционная маржинальная прибыль)

CM2
  − Затраты на привлечение (CAC на заказ)
= CM3  (маржа после маркетинга — «чистый вклад» юнита)

Как читать уровни на практике:

• CM1 отрицательный — вы продаёте товар дешевле закупки. Это разовая акция или ошибка в ценообразовании, на потоке так жить нельзя.
• CM2 отрицательный — товар прибыльный, но логистика и возвраты съедают всё. Классика дешёвых товаров с бесплатной доставкой.
• CM3 отрицательный на первый заказ — норма для маркетплейса. Но тогда клиент обязан вернуться, и суммарный CM3 по всем его заказам должен стать плюсовым.

Разные компании нумеруют уровни немного по-разному (кто-то кладёт маркетинг в CM2), поэтому на собеседовании всегда уточняйте определение. Важна логика «выручка минус переменные по слоям», а не конкретный номер.

Практический смысл разбивки на уровни — не бухгалтерская отчётность, а диагностика. Когда юнит убыточный, разбивка сразу показывает, где именно течёт: если проблема в CM1 — разговор про закупку и ценообразование, если в CM2 — про логистику и возвраты, если в CM3 — про каналы привлечения. Один агрегированный «минус на заказе» такой подсказки не даёт, поэтому цепочку почти всегда считают по слоям, а не одним числом.

Как разложить себестоимость, логистику и CAC на один заказ?

Возьмём заказ на маркетплейсе одежды. Клиент оформил корзину на 3200 рублей, применил промокод на 200 рублей. Разложим по статьям — это и есть скелет таблицы юнит-экономики.

1. Выручка (нетто). Из суммы заказа убираем скидки и НДС (для маркетплейса — ещё и часть, которая уходит продавцу, если вы платформа; для собственных продаж берём весь чек). Пусть нетто-выручка = 2500 рублей.

2. Себестоимость товара (COGS). Закупочная цена всех позиций в заказе. Пусть 1500 рублей → это уже 60% от выручки.

3. Переменные операционные расходы. Всё, что тратится на исполнение заказа:

• Логистика (доставка до клиента + обработка на складе): 350 рублей.
• Эквайринг (комиссия за приём платежа, обычно 1.5–3%): 2500 × 2% = 50 рублей.
• Упаковка и расходники: 40 рублей.
• Резерв на возвраты: если 12% заказов возвращают и возврат стоит ~500 рублей логистики + уценки, то на каждый заказ закладываем 0.12 × 500 = 60 рублей.

4. CAC на заказ. Берём весь маркетинговый бюджет за период и делим на число привлечённых заказов (или новых клиентов). Пусть маркетинг на привлечение стоит 400 рублей на первый заказ. Важно: CAC вешаем на *первый* заказ клиента, повторные заказы приходят бесплатно (органика/retention). Как правильно считать привлечение — в заметке про метрику CAC.

Ключевой принцип разложения: на юнит вешаем только переменное. Зарплаты, офис, серверы, зарплату команды разработки — это постоянные затраты (fixed costs), они покрываются суммарным CM3 всех заказов, а не сидят внутри одного юнита.

При каком AOV и retention юнит выходит в плюс?

Соберём числа из примера выше в один расчёт первого заказа:

CM3 первого заказа = +100 рублей. Формально юнит плюсовой уже на первой покупке — редкая удача. Но представьте, что CAC вырос до 700 рублей (конкурентный аукцион, дорогой трафик). Тогда:

CM3 первого заказа = CM2 − CAC = 500 − 700 = −200 ₽

Юнит ушёл в минус на 200 рублей. Спасает только retention. Если клиент в среднем делает ещё 2 повторных заказа с тем же CM2 = 500 рублей (но без CAC, потому что он уже привлечён), то суммарный вклад клиента:

LTV-вклад = CM2_первый − CAC + CM2_повтор × число_повторов
          = 500 − 700 + 500 × 2
          = −200 + 1000
          = 800 ₽ прибыли на клиента

Отсюда два рычага окупаемости, когда первый заказ убыточный:

• Поднять AOV. Средний чек напрямую тянет вверх CM1 и CM2 (апселл, кросс-селл, бесплатная доставка от порога). Про средний чек AOV — отдельная метрика, за которой стоит следить помесячно.
• Поднять retention. Каждый повторный заказ приходит без CAC, то есть с полным CM2 «в карман». Даже небольшой рост доли вернувшихся резко улучшает юнит. Как строить кривую удержания — в гайде по retention и когортном анализе в SQL.

Простое правило окупаемости: суммарный CM3 по всем заказам клиента должен покрыть CAC с запасом. Если CAC окупается за 1–2 заказа — модель здоровая; если нужно 6+ заказов, а средний клиент делает 2 — юнит убыточный, и масштабировать закупку трафика нельзя.

Как собрать таблицу юнит-экономики одного заказа в SQL?

Обычно данные лежат в таблице заказов с суммами и статьями расходов. Посчитаем CM1/CM2/CM3 на каждый заказ, а затем агрегат по месяцу. Допустим, есть таблица orders с полями: сумма нетто, COGS, логистика, эквайринг, упаковка, резерв возвратов, флаг первого заказа и CAC.

WITH unit AS (
    SELECT
        order_id,
        client_id,
        date_trunc('month', created_at) AS month,
        net_revenue,
        cogs,
        -- CM1: выручка минус себестоимость товара
        net_revenue - cogs AS cm1,
        -- CM2: CM1 минус переменные опер. расходы
        net_revenue - cogs
            - logistics_cost
            - acquiring_fee
            - packaging_cost
            - returns_reserve AS cm2,
        -- CAC вешаем только на первый заказ клиента
        CASE WHEN is_first_order THEN cac ELSE 0 END AS cac_alloc
    FROM orders
)
SELECT
    order_id,
    cm1,
    cm2,
    cm2 - cac_alloc            AS cm3,
    ROUND(cm1  * 100.0 / net_revenue, 1) AS cm1_pct,
    ROUND(cm2  * 100.0 / net_revenue, 1) AS cm2_pct,
    ROUND((cm2 - cac_alloc) * 100.0 / net_revenue, 1) AS cm3_pct
FROM unit
ORDER BY order_id;

Обратите внимание на два момента в запросе. Во-первых, CAC аллоцируется через CASE только на первый заказ клиента — иначе привлечение задвоится на повторных покупках и юнит будет выглядеть хуже, чем есть. Во-вторых, проценты считаются через умножение на 100.0, а не 100, чтобы не поймать целочисленное деление и не получить нули в колонках маржинальности.

Агрегат по когорте месяца привлечения — чтобы видеть, окупается ли трафик:

SELECT
    month,
    COUNT(*)              AS orders,
    SUM(net_revenue)      AS revenue,
    SUM(cm1)              AS cm1_total,
    SUM(cm2)              AS cm2_total,
    SUM(cm2 - cac_alloc)  AS cm3_total,
    ROUND(SUM(cm2 - cac_alloc) * 100.0 / SUM(net_revenue), 1) AS cm3_margin_pct
FROM unit
GROUP BY month
ORDER BY month;

Если удобнее считать в Python на выгрузке из BI — та же логика на pandas:

import pandas as pd

df = pd.read_csv("orders.csv", parse_dates=["created_at"])

df["cm1"] = df["net_revenue"] - df["cogs"]
df["cm2"] = (
    df["cm1"]
    - df["logistics_cost"]
    - df["acquiring_fee"]
    - df["packaging_cost"]
    - df["returns_reserve"]
)
df["cac_alloc"] = df["cac"].where(df["is_first_order"], 0)
df["cm3"] = df["cm2"] - df["cac_alloc"]

report = df.assign(month=df["created_at"].dt.to_period("M")).groupby("month").agg(
    orders=("order_id", "count"),
    revenue=("net_revenue", "sum"),
    cm1=("cm1", "sum"),
    cm2=("cm2", "sum"),
    cm3=("cm3", "sum"),
)
report["cm3_margin_pct"] = (report["cm3"] / report["revenue"] * 100).round(1)
print(report)

Оба варианта можно тут же прогнать в браузере: SQL — в SQL-тренажёре, Python — в Python-тренажёре. Если синтаксис оконных функций и date_trunc пока шатается, начните с базы — курс SQL с нуля закрывает GROUP BY, CTE и агрегаты, на которых стоит вся эта выгрузка.

Какие драйверы сильнее всего двигают маржинальность?

Когда таблица собрана, возникает главный аналитический вопрос: куда бить, чтобы юнит вышел в плюс. Ранжирую драйверы по силе влияния на CM3 для типичного e-commerce:

• Себестоимость товара (COGS). Самая крупная статья (часто 50–70% выручки), поэтому даже 3 процентных пункта скидки от поставщика двигают CM1 сильнее, чем оптимизация упаковки на 20%. Рычаги: переговоры с поставщиками, собственные торговые марки, сокращение неликвида.
• AOV / средний чек. Растёт чек — почти все переменные расходы (COGS, логистика) растут медленнее, а эквайринг вообще фиксированный процент. Каждый рубль сверх порога бесплатной доставки идёт почти целиком в маржу.
• Retention и частота покупок. Повторные заказы приходят без CAC — это самый чистый CM2. Рост доли вернувшихся клиентов на 5 п.п. часто окупает весь маркетинг. Здесь помогает RFM-сегментация в SQL: понять, кого возвращать в первую очередь.
• CAC. Дорогой трафик убивает CM3 первого заказа. Рычаги: доля органики, реферальные механики, работа с каналами по отдельным CAC, а не «средним по больнице».
• Возвраты. Бьют дважды — по логистике и по товару. Снижение доли возвратов через точные размерные сетки и фото сильно чистит CM2 в одежде и обуви.
• Логистика и фулфилмент. Обычно оптимизируется в последнюю очередь (склады, зоны доставки), но на масштабе тоже даёт эффект.

Практический приём: посчитайте маржу в разрезе категорий и когорт, а не в среднем. «Средний CM3 = 4%» может прятать половину товаров в глубоком минусе и половину в жирном плюсе — это парадокс Симпсона, из-за него принимают неверные решения по ассортименту. Тот же принцип разбора маркетплейса по слоям — в кейсе про GMV и take rate.

С чего начать считать свою юнит-экономику?

Минимальный план, который работает в любом e-commerce:

• Определите юнит: один заказ для операционки, один клиент за 12 месяцев для окупаемости привлечения.
• Выгрузите сырые данные заказов и разнесите расходы на переменные (в юнит) и постоянные (вне юнита).
• Посчитайте CM1 → CM2 → CM3 по слоям и найдите уровень, где юнит теряет деньги.
• Наложите retention: убедитесь, что суммарный CM3 клиента покрывает CAC.
• Разбейте по категориям и когортам, а не смотрите средний — там прячутся решения.

Юнит-экономика — не разовый расчёт в таблице, а навык быстро собирать чистые метрики из данных: выручку, себестоимость, GMV, CAC, retention. Именно это и спрашивают на собеседованиях аналитика — потренироваться на реальных вопросах можно в банке вопросов, а прогнать полноценный разбор с обратной связью — в AI-мок-собесе. Разложить SQL-выгрузку по CM-уровням — в тренажёре: первые 5 задач открыты бесплатно, дальше — по Pro-подписке. Начните с одного заказа, доведите цепочку CM1/CM2/CM3 до конца — и вопрос «зарабатываем мы на юните» перестанет быть страшным.