В 2026 году правильное определение юнита для юнит-экономики, особенно для продуктов со сложной монетизацией и многосторонних платформ, сводится к поиску наименьшей экономически неделимой сущности, которая генерирует доход и на которую приходятся переменные расходы. Это может быть платящий клиент, транзакция, подписка или даже пара взаимодействующих сторон, но всегда — конкретный элемент, отражающий основной поток ценности.
%22%20fill%3D%22%231a1410%22%2F%3E%3C%2Fsvg%3E)
В 2026 году правильное определение юнита для юнит-экономики, особенно для продуктов со сложной монетизацией и многосторонних платформ, сводится к поиску наименьшей экономически неделимой сущности, которая генерирует доход и на которую приходятся переменные расходы. Это может быть платящий клиент, транзакция, подписка или даже пара взаимодействующих сторон, но всегда — конкретный элемент, отражающий основной поток ценности.
Классический подход, где юнит — это всегда один пользователь или один заказ, для современных цифровых продуктов часто оказывается неработоспособным. В 2026 году стартапы все чаще выходят на рынок с многоуровневыми подписками, фримиум-моделями, B2B SaaS с лицензированием по командам или многосторонними платформами, которые связывают несколько групп пользователей.
Неверное определение юнита приводит к искаженным метрикам CAC (стоимость привлечения клиента) и LTV (пожизненная ценность клиента). Если юнит выбран неточно, вы получите цифры, которые не отражают реального положения дел. Это, в свою очередь, ведет к ошибочным управленческим решениям: необоснованным инвестициям в маркетинг, неверной оценке потенциала роста, некорректной ценовой политике и, как следствие, к потере капитала.
Суть в том, что юнит должен точно отражать основной механизм создания ценности и получения дохода. Если ваш продукт приносит деньги не напрямую от каждого пользователя, а от целой компании, группы или через сложную цепочку взаимодействий, то и юнит должен быть соответствующим. Только так можно получить адекватную картину экономики и обеспечить устойчивый рост.
Юнит, равный одному пользователю, по-прежнему актуален для продуктов с простой линейной монетизацией. Например, для некоторых EdTech-сервисов, где каждый пользователь покупает индивидуальный доступ к курсу, или для простых SaaS-решений с помесячной подпиской на одного человека без дополнительных опций. Здесь один пользователь — это один платящий клиент, и метрики LTV и CAC рассчитываются прямолинейно.
Однако такой подход быстро натыкается на ограничения. Что делать, если у вас семейная подписка на стриминговый сервис, где один платящий клиент дает доступ нескольким пользователям? Или B2B-инструмент, который продается на целую команду, но пользуются им, скажем, пять сотрудников? Здесь попытка считать по пользователям немедленно исказит CAC и LTV, так как стоимость привлечения приходится на одного покупателя, а не на каждого фактического потребителя услуги.
Особенно проблематичен подход 'один пользователь — один юнит' для фримиум-моделей. Если вы привлекаете миллионы бесплатных пользователей, а монетизируете лишь процент из них, то CAC, рассчитанный на всех пользователей, будет неоправданно низок, а LTV на платящих — завышен. Необходимо связывать экономические показатели с той сущностью, которая приносит деньги и на которую направлены основные переменные затраты.
Для платформ, основной доход которых генерируется от каждой транзакции или заказа (классические E-commerce, маркетплейсы вроде Ozon или Яндекс.Маркета с комиссией от продаж), часто кажется логичным выбрать заказ в качестве юнита. И действительно, можно посчитать среднюю выручку с заказа, среднюю прибыль с заказа. Это дает представление о рентабельности одной операции.
Проблема такого подхода в том, что он не учитывает LTV конкретного клиента. Один пользователь может совершить 10 заказов, другой — один. Если мы считаем юнит как заказ, мы теряем ценность повторных покупок и лояльности. Получается, что CAC мы все равно считаем на привлечение пользователя, а LTV — на привлечение единичного заказа, что создает методологический разрыв. Необходимо связывать транзакции с сущностью, которая их 'поставляет' — то есть, с клиентом или покупателем.
Правильнее в этом случае считать юнит как уникального покупателя, который совершил хотя бы одну транзакцию. Тогда LTV будет отражать суммарный доход со всех его покупок, а CAC — затраты на его первое привлечение. Юнит-экономика должна давать представление о прибыльности привлечения именно покупателя, а не единичной покупки. Это позволяет видеть перспективу и работать над удержанием клиентов.
Во фримиум-моделях юнит определяется с учетом потенциальной конверсии. Здесь юнит — это не просто любой пользователь, а именно уникальный пользователь, который *потенциально* может перейти на платный тариф. Для расчёта юнит-экономики вы должны ориентироваться на тех, кто прошел определенный этап активации или соответствует профилю целевого платящего клиента.
CAC в этом случае будет рассчитываться на всех привлеченных уникальных пользователей, которые достигли определенной стадии активации или вовлечения в бесплатный продукт. LTV, в свою очередь, будет относиться только к той части этих пользователей, которая конвертировалась в платящих. Важно, чтобы юнит-экономика показывала, сколько вы тратите на привлечение потенциального платящего клиента и сколько он приносит вам после конверсии. Это даст реалистичную картину рентабельности модели.
Многосторонние платформы — агрегаторы такси, маркетплейсы, платформы для фрилансеров — по своей природе имеют несколько типов пользователей: покупатели и продавцы, водители и пассажиры, заказчики и исполнители. Каждый из этих сегментов имеет свою экономическую логику, свои затраты на привлечение и свою ценность для платформы. Поэтому единый универсальный юнит здесь почти никогда не работает.
В таких случаях приходится определять несколько юнитов. Например, для маркетплейса можно иметь юнит 'покупатель' (с его CAC, LTV) и юнит 'продавец' (со своими метриками, где LTV может быть доходом от комиссии с его продаж). Для платформы доставки еды это может быть 'ресторан', 'курьер' и 'заказчик'. Каждая из этих сторон является 'юнитом' в своем контексте, и их метрики взаимосвязаны.
Крайне важно понимать эту взаимосвязь. LTV продавца на маркетплейсе напрямую зависит от LTV покупателей, которые приходят и совершают покупки. И наоборот, привлечение покупателей без достаточного количества качественных продавцов бессмысленно. Юнит-экономика многосторонних платформ — это не сумма отдельных юнит-экономик, а сложная система, где LTV одной стороны может быть функцией от LTV другой. Именно здесь проявляется мастерство венчурного аналитика — увидеть эти связи и правильно их оцифровать.
Несмотря на многообразие юнитов по сторонам платформы, часто полезно выделить центральный 'юнит обмена' — то, что является ядром ценности, ради чего все стороны приходят на платформу. Для агрегатора такси это 'поездка'. Для сервиса по поиску репетиторов — 'занятие'. Для платформы для подбора специалистов — 'успешно завершенный проект'.
Этот центральный юнит обмена помогает агрегировать доходы и расходы от всех сторон. Вы можете посчитать средний доход, полученный платформой с одной поездки, или с одного завершенного проекта. Это позволяет оценить операционную эффективность. Однако не стоит заменять им юниты 'покупателя' или 'продавца' для расчета LTV/CAC, так как он не отражает пожизненной ценности конкретной стороны.
Настоящая ценность этого центрального юнита — в возможности посчитать юнит-экономику отдельного взаимодействия. Сколько вы зарабатываете на каждой поездке? Каковы переменные затраты на неё (комиссия водителя, поддержка)? Это дополняет картину и помогает в оптимизации бизнес-процессов, но не отменяет необходимости считать LTV/CAC по каждой стороне платформы.
Если вы не можете чётко определить, за что конкретно вам платят и что порождает ваши затраты, у вас нет юнит-экономики, а есть финансовый отчёт, который лишь констатирует факт. Артём Ковалёв, Стратег стартапов.
— Артём Ковалёв
Рассмотрим реальный кейс — B2B SaaS платформу для управления проектами. Допустим, она предлагает три тарифа: 'Базовый' для команд до 5 пользователей, 'Стандарт' до 20 пользователей и 'Корпоративный' без лимита по количеству пользователей, с ежемесячной подпиской. Продукт активно привлекает лиды через контент-маркетинг, контекстную рекламу и продажи по телефону.
Проблема: Многие стартапы в такой ситуации ошибочно берут за юнит 'пользователя'. Если бы мы считали юнит-экономику по пользователям, мы бы получили искаженную картину. Например, одна проданная подписка на 'Корпоративный' тариф может принести 100 активных пользователей. Если разделить весь CAC на 100 пользователей, он окажется крайне низким, а LTV каждого пользователя — тоже низким, ведь они не платят индивидуально. Такая 'экономика' выглядит привлекательно, но абсолютно нереалистична для инвестора и внутренней аналитики.
Правильное определение юнита: В данном случае, юнит — это платящая компания (Account). Именно компания принимает решение о покупке, именно она оплачивает подписку, и именно на привлечение *компании* направлены основные усилия по продажам и маркетингу. Количество пользователей внутри аккаунта — это уже метрика использования, а не юнит.
Расчет метрик для юнита 'Компания':
Вывод из кейса: Определив юнит как 'компанию', мы получаем реалистичную и управляемую юнит-экономику. Мы понимаем, сколько стоит привлечь реального платящего клиента, сколько он приносит и как долго остается с нами. Попытка считать по пользователям дала бы заниженный CAC (много пользователей за одну продажу) и неточный LTV, что привело бы к ошибочным выводам о прибыльности и масштабируемости бизнеса.
Одно из самых распространенных заблуждений в работе с многосторонними платформами — это сосредоточиться только на одной стороне. Например, маркетплейс, который считает юнит-экономику исключительно для покупателей, полностью игнорируя продавцов. В таком сценарии можно успешно привлекать покупателей, но если нет достаточного количества или качества продавцов, то LTV покупателей будет падать из-за отсутствия предложений или низкого уровня сервиса.
Юнит-экономика продавца, его CAC и LTV, часто играют не менее, а иногда и более важную роль для долгосрочной стабильности платформы. Привлечение качественного продавца с уникальным товаром может стоить дорого, но его LTV (в виде комиссии от продаж) может значительно превосходить LTV обычного покупателя. Игнорировать это — значит упускать ключевой рычаг роста и оптимизации.
Активный пользователь (Active User) — это важная метрика вовлеченности и здоровья продукта, но она не всегда является базовым экономическим юнитом. Например, в социальной сети активный пользователь — это человек, который регулярно заходит и потребляет контент. Но если монетизация идет исключительно через рекламу, то юнит-экономику логичнее считать не на 'активного пользователя', а на 'показ рекламы' или 'клик по рекламе'. В этом случае пользователь является объектом для монетизации, но не самим юнитом дохода.
Особенно это заметно в продуктах с моделью 'attention economy', где ценность создается за счет внимания аудитории, а монетизация происходит через посредников. Здесь важно различать того, кто создает трафик или внимание (активный пользователь), и того, кто фактически приносит доход (например, рекламодатель или рекламное действие). Смешение этих понятий приведет к тому, что вы будете оптимизировать не ту воронку, которая напрямую влияет на прибыль.
Многие стартапы считают, что юнит, определенный на старте, будет актуален всегда. Это опасное заблуждение. Продукт развивается, бизнес-модель может трансформироваться. Изначально юнит мог быть 'индивидуальный пользователь' для бесплатной бета-версии, но после запуска платных командных тарифов он естественным образом должен стать 'компанией' или 'командой'.
Я рекомендую регулярно пересматривать определение юнита, как минимум раз в 6-12 месяцев, или при каждом значительном изменении в стратегии монетизации или продуктовой линейке. Гибкость в этом вопросе позволяет юнит-экономике оставаться актуальным и мощным инструментом для принятия стратегических решений, а не просто архивным документом.
Многие стартапы 'умирают' не от отсутствия продукта, а от неспособности доказать, что каждый новый привлечённый клиент не уносит с собой больше денег, чем приносит. А это прямое следствие неверно построенной юнит-экономики.
— Андрей Гурьев, венчурный инвестор
Расчет CAC (Customer Acquisition Cost) для сложных юнитов требует точности в определении 'привлеченного юнита'. Формула остается классической: (Затраты на маркетинг + Затраты на продажи) / Количество привлеченных юнитов. Однако под 'количеством привлеченных юнитов' мы понимаем именно те сущности, которые были определены как наш юнит. Если это компания, то и делить нужно на количество привлеченных компаний.
Важно учитывать *все* переменные затраты, связанные с привлечением конкретного юнита. Для многосторонних платформ это может означать, что в CAC для 'покупателя' могут включаться затраты на привлечение 'продавцов', если без них первые не смогли бы получить ценность. Например, в агрегаторе услуг, стоимость привлечения клиента может включать часть затрат на привлечение и обучение исполнителей, которые будут оказывать эти услуги.
Строго соблюдайте сроки: CAC нужно считать за тот же период, за который собраны данные по привлеченным юнитам. Смешение когорт или периодов ведет к неточностям. Например, если вы потратили 100 000 рублей на рекламу в январе и привлекли 10 платящих компаний, ваш CAC равен 10 000 рублей. Не следует включать в расчет компании, привлеченные в феврале, или затраты декабря.
Расчет LTV (Lifetime Value) также должен опираться на правильно определенный юнит. Простая формула — ARPU (средний доход на юнит) * Lifetime (среднее время жизни юнита) — вполне работоспособна, но требует четкого понимания, что такое 'доход' и 'время жизни' для вашего юнита.
Для подписочных моделей, более точная формула LTV = ARPU * (1 / Churn Rate), где Churn Rate — это ежемесячный или ежеквартальный отток юнитов. Для транзакционных моделей (например, маркетплейсов), LTV может быть рассчитан как (Средний чек * Средняя частота покупок в месяц * Среднее время жизни юнита). При этом 'средний чек' и 'частота' должны быть агрегированы именно для выбранного юнита, например, для одной компании или одного покупателя.
Для многосторонних платформ LTV одного юнита может зависеть от активности других юнитов. Например, LTV продавца на маркетплейсе будет напрямую связан со средним количеством и суммой транзакций, которые совершают покупатели с его товарами. Здесь нужно строить модели, которые учитывают эту взаимозависимость, чтобы не переоценить или недооценить истинную ценность каждой стороны платформы.
Классическое определение юнита как просто пользователя часто не подходит для сложных бизнес-моделей 2026 года, таких как фримиум, подписки с разными тарифами или многосторонние платформы. Оно искажает реальные затраты на привлечение (CAC) и пожизненную ценность (LTV), потому что один платящий клиент может объединять множество пользователей или приносить доход через множество транзакций, а не прямое единоразовое действие.
Центральный юнит обмена на многосторонней платформе это то ключевое взаимодействие или объект, вокруг которого строится ценность и монетизация. Например, для агрегатора такси это поездка, для фриланс-биржи — завершенный проект, а для маркетплейса — проданный товар. Именно от этого юнита калькулируются основные доходы и расходы.
Во фримиум-моделях юнит следует определять как уникального пользователя, который *потенциально* может конвертироваться в платящего. Это позволяет отслеживать эффективность верхних воронок, конверсию из бесплатной версии в платную, и корректно считать CAC для всех привлеченных пользователей и LTV для тех, кто в итоге заплатил. Такой подход дает более полное представление о прибыльности бизнес-модели.
Ключевые ошибки включают фокусировку только на одной стороне платформы, игнорируя вклад других, смешивание понятия 'юнит' с 'активным пользователем', а также отсутствие итеративного пересмотра юнита по мере развития продукта. Также опасно не учитывать все переменные затраты, связанные с жизненным циклом выбранного юнита.
Для большинства стартапов с приемлемой маржой, здоровым считается отношение LTV к CAC от 3:1. Это означает, что каждый рубль, вложенный в привлечение клиента, приносит минимум три рубля дохода за весь срок его жизни. Показатель ниже 2:1 часто указывает на проблемы в бизнес-модели или неэффективность маркетинга.
Определение юнита не статично. Его следует пересматривать каждые 6-12 месяцев или при существенных изменениях в бизнес-модели продукта. Например, при добавлении новых тарифов, выходе на новые рынки или изменении ключевого способа монетизации, переоценка юнита становится необходимой для поддержания актуальности юнит-экономики.
Комментарии (0)
Без регистрации. Комментарии проверяются автоматически перед публикацией.
Пока нет комментариев. Будьте первым!