Как определить юнит для юнит-экономики в 2026 году: Методология для сложных продуктов

В 2026 году правильное определение юнита для юнит-экономики, особенно для продуктов со сложной монетизацией и многосторонних платформ, сводится к поиску наименьшей экономически неделимой сущности, которая генерирует доход и на которую приходятся переменные расходы. Это может быть платящий клиент, транзакция, подписка или даже пара взаимодействующих сторон, но всегда — конкретный элемент, отражающий основной поток ценности.

Почему определение юнита критично для сложных моделей

Классический подход, где юнит — это всегда один пользователь или один заказ, для современных цифровых продуктов часто оказывается неработоспособным. В 2026 году стартапы все чаще выходят на рынок с многоуровневыми подписками, фримиум-моделями, B2B SaaS с лицензированием по командам или многосторонними платформами, которые связывают несколько групп пользователей.

Неверное определение юнита приводит к искаженным метрикам CAC (стоимость привлечения клиента) и LTV (пожизненная ценность клиента). Если юнит выбран неточно, вы получите цифры, которые не отражают реального положения дел. Это, в свою очередь, ведет к ошибочным управленческим решениям: необоснованным инвестициям в маркетинг, неверной оценке потенциала роста, некорректной ценовой политике и, как следствие, к потере капитала.

Суть в том, что юнит должен точно отражать основной механизм создания ценности и получения дохода. Если ваш продукт приносит деньги не напрямую от каждого пользователя, а от целой компании, группы или через сложную цепочку взаимодействий, то и юнит должен быть соответствующим. Только так можно получить адекватную картину экономики и обеспечить устойчивый рост.

Единый подход: От ценности к монетизации

Пользователь как юнит: Когда работает, когда нет

Юнит, равный одному пользователю, по-прежнему актуален для продуктов с простой линейной монетизацией. Например, для некоторых EdTech-сервисов, где каждый пользователь покупает индивидуальный доступ к курсу, или для простых SaaS-решений с помесячной подпиской на одного человека без дополнительных опций. Здесь один пользователь — это один платящий клиент, и метрики LTV и CAC рассчитываются прямолинейно.

Однако такой подход быстро натыкается на ограничения. Что делать, если у вас семейная подписка на стриминговый сервис, где один платящий клиент дает доступ нескольким пользователям? Или B2B-инструмент, который продается на целую команду, но пользуются им, скажем, пять сотрудников? Здесь попытка считать по пользователям немедленно исказит CAC и LTV, так как стоимость привлечения приходится на одного покупателя, а не на каждого фактического потребителя услуги.

Особенно проблематичен подход 'один пользователь — один юнит' для фримиум-моделей. Если вы привлекаете миллионы бесплатных пользователей, а монетизируете лишь процент из них, то CAC, рассчитанный на всех пользователей, будет неоправданно низок, а LTV на платящих — завышен. Необходимо связывать экономические показатели с той сущностью, которая приносит деньги и на которую направлены основные переменные затраты.

Заказ или транзакция как юнит: Маркетплейсы и E-commerce

Для платформ, основной доход которых генерируется от каждой транзакции или заказа (классические E-commerce, маркетплейсы вроде Ozon или Яндекс.Маркета с комиссией от продаж), часто кажется логичным выбрать заказ в качестве юнита. И действительно, можно посчитать среднюю выручку с заказа, среднюю прибыль с заказа. Это дает представление о рентабельности одной операции.

Проблема такого подхода в том, что он не учитывает LTV конкретного клиента. Один пользователь может совершить 10 заказов, другой — один. Если мы считаем юнит как заказ, мы теряем ценность повторных покупок и лояльности. Получается, что CAC мы все равно считаем на привлечение пользователя, а LTV — на привлечение единичного заказа, что создает методологический разрыв. Необходимо связывать транзакции с сущностью, которая их 'поставляет' — то есть, с клиентом или покупателем.

Правильнее в этом случае считать юнит как уникального покупателя, который совершил хотя бы одну транзакцию. Тогда LTV будет отражать суммарный доход со всех его покупок, а CAC — затраты на его первое привлечение. Юнит-экономика должна давать представление о прибыльности привлечения именно покупателя, а не единичной покупки. Это позволяет видеть перспективу и работать над удержанием клиентов.

Специфика фримиум-моделей: Юнит — это конвертируемый пользователь

Во фримиум-моделях юнит определяется с учетом потенциальной конверсии. Здесь юнит — это не просто любой пользователь, а именно уникальный пользователь, который *потенциально* может перейти на платный тариф. Для расчёта юнит-экономики вы должны ориентироваться на тех, кто прошел определенный этап активации или соответствует профилю целевого платящего клиента.

CAC в этом случае будет рассчитываться на всех привлеченных уникальных пользователей, которые достигли определенной стадии активации или вовлечения в бесплатный продукт. LTV, в свою очередь, будет относиться только к той части этих пользователей, которая конвертировалась в платящих. Важно, чтобы юнит-экономика показывала, сколько вы тратите на привлечение потенциального платящего клиента и сколько он приносит вам после конверсии. Это даст реалистичную картину рентабельности модели.

Многосторонние платформы: Сложность в квадрате

Определение 'юнита' для каждой стороны платформы

Многосторонние платформы — агрегаторы такси, маркетплейсы, платформы для фрилансеров — по своей природе имеют несколько типов пользователей: покупатели и продавцы, водители и пассажиры, заказчики и исполнители. Каждый из этих сегментов имеет свою экономическую логику, свои затраты на привлечение и свою ценность для платформы. Поэтому единый универсальный юнит здесь почти никогда не работает.

В таких случаях приходится определять несколько юнитов. Например, для маркетплейса можно иметь юнит 'покупатель' (с его CAC, LTV) и юнит 'продавец' (со своими метриками, где LTV может быть доходом от комиссии с его продаж). Для платформы доставки еды это может быть 'ресторан', 'курьер' и 'заказчик'. Каждая из этих сторон является 'юнитом' в своем контексте, и их метрики взаимосвязаны.

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

Центральный юнит: Объект обмена

Несмотря на многообразие юнитов по сторонам платформы, часто полезно выделить центральный 'юнит обмена' — то, что является ядром ценности, ради чего все стороны приходят на платформу. Для агрегатора такси это 'поездка'. Для сервиса по поиску репетиторов — 'занятие'. Для платформы для подбора специалистов — 'успешно завершенный проект'.

Этот центральный юнит обмена помогает агрегировать доходы и расходы от всех сторон. Вы можете посчитать средний доход, полученный платформой с одной поездки, или с одного завершенного проекта. Это позволяет оценить операционную эффективность. Однако не стоит заменять им юниты 'покупателя' или 'продавца' для расчета LTV/CAC, так как он не отражает пожизненной ценности конкретной стороны.

Настоящая ценность этого центрального юнита — в возможности посчитать юнит-экономику отдельного взаимодействия. Сколько вы зарабатываете на каждой поездке? Каковы переменные затраты на неё (комиссия водителя, поддержка)? Это дополняет картину и помогает в оптимизации бизнес-процессов, но не отменяет необходимости считать LTV/CAC по каждой стороне платформы.

Если вы не можете чётко определить, за что конкретно вам платят и что порождает ваши затраты, у вас нет юнит-экономики, а есть финансовый отчёт, который лишь констатирует факт. Артём Ковалёв, Стратег стартапов.

— Артём Ковалёв

Методология определения юнита: Пошаговый алгоритм

1. 1.Шаг 1: Идентифицируйте основной поток создания ценности. Поймите, что является ключевым взаимодействием или действием, за которое ваша компания в конечном итоге получает деньги. Это может быть подписка, покупка товара, завершение проекта, просмотр рекламы. Определите, что именно приносит доход, а не просто активность.
2. 2.Шаг 2: Определите ключевых акторов. Выделите всех участников, которые играют существенную роль в этом потоке ценности и монетизации. Это могут быть конечные пользователи, компании-клиенты, продавцы, поставщики, рекламодатели, курьеры. Задайте вопрос: кто реально платит или кто позволяет вам зарабатывать?
3. 3.Шаг 3: Выделите источник дохода. С какой конкретной сущности или действия приходит основной, повторяющийся или значительный доход. Если это подписка, то кто её оплачивает? Если это комиссия, то с какой транзакции? Если это реклама, то кто ее смотрит или кликает?
4. 4.Шаг 4: Выделите источник затрат. С какой сущности или действия связаны основные переменные затраты на привлечение и обслуживание? Если вы привлекаете компании, то CAC — это стоимость привлечения компании. Если вы платите комиссию за каждую транзакцию, то это переменная затрата, связанная с транзакцией. Юнит должен быть тем, что вызывает эти переменные расходы.
5. 5.Шаг 5: Проверьте на делимость и независимость. Можно ли выбранную вами сущность разбить на более мелкие экономически значимые части? Юнит должен быть наименьшей неделимой единицей, которая приносит доход и на которую приходятся переменные расходы. Он должен быть достаточно независимым, чтобы на его основе можно было считать LTV и CAC.
6. 6.Шаг 6: Тестирование на примере. Возьмите гипотетическую когорту из 1000 ваших выбранных юнитов, привлеченных за один месяц. Попробуйте на них рассчитать LTV и CAC. Сходятся ли эти цифры с вашими общими финансовыми показателями? Если нет, то ваш юнит определен неточно. Проверяйте, насколько выбранный юнит помогает в принятии решений о масштабировании и прибыльности.

Кейс: Расчет юнит-экономики для B2B SaaS платформы с многоуровневой подпиской

Рассмотрим реальный кейс — B2B SaaS платформу для управления проектами. Допустим, она предлагает три тарифа: 'Базовый' для команд до 5 пользователей, 'Стандарт' до 20 пользователей и 'Корпоративный' без лимита по количеству пользователей, с ежемесячной подпиской. Продукт активно привлекает лиды через контент-маркетинг, контекстную рекламу и продажи по телефону.

Проблема: Многие стартапы в такой ситуации ошибочно берут за юнит 'пользователя'. Если бы мы считали юнит-экономику по пользователям, мы бы получили искаженную картину. Например, одна проданная подписка на 'Корпоративный' тариф может принести 100 активных пользователей. Если разделить весь CAC на 100 пользователей, он окажется крайне низким, а LTV каждого пользователя — тоже низким, ведь они не платят индивидуально. Такая 'экономика' выглядит привлекательно, но абсолютно нереалистична для инвестора и внутренней аналитики.

Правильное определение юнита: В данном случае, юнит — это платящая компания (Account). Именно компания принимает решение о покупке, именно она оплачивает подписку, и именно на привлечение *компании* направлены основные усилия по продажам и маркетингу. Количество пользователей внутри аккаунта — это уже метрика использования, а не юнит.

Расчет метрик для юнита 'Компания':

1. CAC (Customer Acquisition Cost): Все затраты на маркетинг и продажи (реклама, зарплаты сейлзов, комиссии, вебинары и т.д.), деленные на количество *привлеченных компаний* за определенный период. В B2B SaaS для российского рынка этот показатель может колебаться от 50 000 до 500 000 рублей, в зависимости от сложности продукта и среднего чека. Например, если за квартал потратили 5 000 000 рублей и привлекли 50 компаний, CAC = 100 000 рублей.
2. LTV (Lifetime Value): Средний доход, который приносит одна компания за весь срок её жизни на платформе. Учитывает апсейлы (переход на более дорогие тарифы) и даунсейлы. Предположим, средний ежемесячный чек с компании составляет 70 000 рублей, а средний срок жизни клиента — 18 месяцев (что соответствует ежемесячному оттоку (churn rate) около 5.5%). Тогда LTV = 70 000 * 18 = 1 260 000 рублей. Отношение LTV/CAC в этом случае составит 1 260 000 / 100 000 = 12.6, что является отличным показателем.
3. Retention (удержание): Важно анализировать когортный ретеншн именно *компаний*, а не пользователей. Сколько компаний из когорты, привлеченной в определенный месяц, остаются платящими через 3, 6, 12 месяцев. Для B2B SaaS хорошие показатели ретеншна — это 85-90% через 3 месяца и 70-75% через год. Если ретеншн ниже 60% к концу первого года, это тревожный сигнал.

Вывод из кейса: Определив юнит как 'компанию', мы получаем реалистичную и управляемую юнит-экономику. Мы понимаем, сколько стоит привлечь реального платящего клиента, сколько он приносит и как долго остается с нами. Попытка считать по пользователям дала бы заниженный CAC (много пользователей за одну продажу) и неточный LTV, что привело бы к ошибочным выводам о прибыльности и масштабируемости бизнеса.

Частые ошибки и заблуждения при определении юнита

Фокус на одной стороне платформы

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

Юнит-экономика продавца, его CAC и LTV, часто играют не менее, а иногда и более важную роль для долгосрочной стабильности платформы. Привлечение качественного продавца с уникальным товаром может стоить дорого, но его LTV (в виде комиссии от продаж) может значительно превосходить LTV обычного покупателя. Игнорировать это — значит упускать ключевой рычаг роста и оптимизации.

Смешение понятий 'юнит' и 'активный пользователь'

Активный пользователь (Active User) — это важная метрика вовлеченности и здоровья продукта, но она не всегда является базовым экономическим юнитом. Например, в социальной сети активный пользователь — это человек, который регулярно заходит и потребляет контент. Но если монетизация идет исключительно через рекламу, то юнит-экономику логичнее считать не на 'активного пользователя', а на 'показ рекламы' или 'клик по рекламе'. В этом случае пользователь является объектом для монетизации, но не самим юнитом дохода.

Особенно это заметно в продуктах с моделью 'attention economy', где ценность создается за счет внимания аудитории, а монетизация происходит через посредников. Здесь важно различать того, кто создает трафик или внимание (активный пользователь), и того, кто фактически приносит доход (например, рекламодатель или рекламное действие). Смешение этих понятий приведет к тому, что вы будете оптимизировать не ту воронку, которая напрямую влияет на прибыль.

Отсутствие итераций

Многие стартапы считают, что юнит, определенный на старте, будет актуален всегда. Это опасное заблуждение. Продукт развивается, бизнес-модель может трансформироваться. Изначально юнит мог быть 'индивидуальный пользователь' для бесплатной бета-версии, но после запуска платных командных тарифов он естественным образом должен стать 'компанией' или 'командой'.

Я рекомендую регулярно пересматривать определение юнита, как минимум раз в 6-12 месяцев, или при каждом значительном изменении в стратегии монетизации или продуктовой линейке. Гибкость в этом вопросе позволяет юнит-экономике оставаться актуальным и мощным инструментом для принятия стратегических решений, а не просто архивным документом.

Многие стартапы 'умирают' не от отсутствия продукта, а от неспособности доказать, что каждый новый привлечённый клиент не уносит с собой больше денег, чем приносит. А это прямое следствие неверно построенной юнит-экономики.

— Андрей Гурьев, венчурный инвестор

Как считать LTV и CAC для сложных юнитов

Расчет CAC

Расчет CAC (Customer Acquisition Cost) для сложных юнитов требует точности в определении 'привлеченного юнита'. Формула остается классической: (Затраты на маркетинг + Затраты на продажи) / Количество привлеченных юнитов. Однако под 'количеством привлеченных юнитов' мы понимаем именно те сущности, которые были определены как наш юнит. Если это компания, то и делить нужно на количество привлеченных компаний.

Важно учитывать *все* переменные затраты, связанные с привлечением конкретного юнита. Для многосторонних платформ это может означать, что в CAC для 'покупателя' могут включаться затраты на привлечение 'продавцов', если без них первые не смогли бы получить ценность. Например, в агрегаторе услуг, стоимость привлечения клиента может включать часть затрат на привлечение и обучение исполнителей, которые будут оказывать эти услуги.

Строго соблюдайте сроки: CAC нужно считать за тот же период, за который собраны данные по привлеченным юнитам. Смешение когорт или периодов ведет к неточностям. Например, если вы потратили 100 000 рублей на рекламу в январе и привлекли 10 платящих компаний, ваш CAC равен 10 000 рублей. Не следует включать в расчет компании, привлеченные в феврале, или затраты декабря.

Расчет LTV

Расчет LTV (Lifetime Value) также должен опираться на правильно определенный юнит. Простая формула — ARPU (средний доход на юнит) * Lifetime (среднее время жизни юнита) — вполне работоспособна, но требует четкого понимания, что такое 'доход' и 'время жизни' для вашего юнита.

Для подписочных моделей, более точная формула LTV = ARPU * (1 / Churn Rate), где Churn Rate — это ежемесячный или ежеквартальный отток юнитов. Для транзакционных моделей (например, маркетплейсов), LTV может быть рассчитан как (Средний чек * Средняя частота покупок в месяц * Среднее время жизни юнита). При этом 'средний чек' и 'частота' должны быть агрегированы именно для выбранного юнита, например, для одной компании или одного покупателя.

Для многосторонних платформ LTV одного юнита может зависеть от активности других юнитов. Например, LTV продавца на маркетплейсе будет напрямую связан со средним количеством и суммой транзакций, которые совершают покупатели с его товарами. Здесь нужно строить модели, которые учитывают эту взаимозависимость, чтобы не переоценить или недооценить истинную ценность каждой стороны платформы.

Выводы и практические шаги

1. Чёткое определение юнита — фундамент. Без него все метрики юнит-экономики будут искажены, а стратегические решения — ошибочны. Это первый и самый важный шаг для любого стартапа.
2. Юнит должен отражать ценность. Ищите наименьшую неделимую экономическую сущность, которая получает ценность от вашего продукта и приносит доход. Это может быть платящий клиент, компания или даже конкретная транзакция.
3. Для платформ: несколько юнитов и центральный объект обмена. Анализируйте каждую сторону многосторонней платформы как отдельный юнит со своими CAC и LTV. При этом выделите центральный 'юнит обмена' для оценки операционной эффективности всего процесса.
4. Итеративность и гибкость. Юнит-экономика не высечена в камне. Регулярно пересматривайте определение юнита по мере развития продукта, изменения бизнес-модели или появления новых каналов монетизации.
5. Ориентируйтесь на LTV/CAC > 3. Для большинства стартапов с приличной маржой это золотое правило, показывающее здоровую экономику и потенциал для масштабирования. Отклонения требуют немедленного анализа.
6. Детализируйте переменные затраты. В CAC включайте не только прямые расходы на привлечение, но и все переменные расходы на обслуживание и поддержку юнита, пока он приносит доход. Это обеспечит максимальную точность.
7. Не пренебрегайте когортным анализом. Отслеживайте ретеншн и LTV по когортам, чтобы видеть динамику и оперативно реагировать на изменения в поведении ваших юнитов.
8. Оспорьте хайп цифрами. Если кто-то рассказывает о грандиозном росте, но не может четко показать юнит-экономику, скорее всего, он живет в мире иллюзий. Только цифры, основанные на корректном определении юнита, дают объективную картину.

Ещё от Артём Ковалёв

Стратегический пивот до MVP: CustDev для смены курса и доверия инвесторов в 2026

14 мин

Как не потерять Product-Market Fit после первого раунда: CustDev для устойчивости в 2026

15 мин

Стратегическая валидация: Как стартапу удержать Product-Market Fit и юнит-экономику в турбулентном 2026 году

17 мин