Freemium (фримиум): что это и где провести границу бесплатного

Коротко

Freemium (фримиум) — модель монетизации, в которой базовая версия продукта бесплатна без ограничения по сроку, а за расширенные возможности платит меньшая часть пользователей. Бесплатная версия работает как канал привлечения: она должна показать ценность и привести к оплате тех, кому нужно больше.

• Слово freemium появилось в марте 2006 года в блоге инвестора Фреда Уилсона: он описал модель и попросил читателей её назвать, название предложил Джарид Лукин из компании Alacra.
• От триала freemium отличается сроком: триал заканчивается, бесплатная версия — нет. От рекламной модели — тем, кто платит: при freemium деньги приносят сами пользователи.
• Экономика держится на неравенстве: обслуживание всех активных пользователей должно стоить заметно меньше, чем выручка на активного (ARPU = доля платящих × ARPPU).
• Конверсию в платящих сравнивают только по когортам с одинаковым окном от регистрации и в разрезе сегментов. На учебной базе наивное сравнение показывает падение вдвое, а честное — с 27,1% до 20,4%, и большую часть разницы объясняет новый рекламный канал.
• Границу бесплатного проводят по объёму, функциям, числу участников или глубине по времени и проверяют данными: сколько людей упирается в предел и что они делают дальше.

Что такое freemium и откуда взялось слово

Freemium — сращение английских free («бесплатный») и premium («премиальный»). Модель старше слова: программы с бесплатной базовой версией и платными дополнениями существовали задолго до 2006 года. Но устойчивое имя она получила в двух постах венчурного инвестора Фреда Уилсона, опубликованных 23 марта 2006 года в его блоге AVC.

В первом, «My Favorite Business Model», Уилсон описал схему: отдать сервис бесплатно, дёшево набрать большую аудиторию через рекомендации и поиск, а затем продавать части этой аудитории премиальные функции или расширенную версию. Примерами были Skype и Flickr. Названия у схемы не было, и Уилсон прямо попросил читателей его придумать. В тот же день во втором посте, «The Freemium Business Model», он сообщил, что слово freemium предложил Джарид Лукин из Alacra, компании из портфеля его фонда, и что будет называть модель так.

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

Чем freemium отличается от триала, условно-бесплатной и рекламной модели

Термины путают, потому что во всех случаях пользователь сначала ничего не платит. Различаются они тем, что именно бесплатно, как долго и кто в итоге приносит деньги.

С «условно-бесплатной» моделью путаница особенно частая: по-русски так называют и shareware — программы, которые после пробного срока или с постоянными напоминаниями просят заплатить, — и игры free-to-play с внутриигровыми покупками. Вторые по устройству близки к freemium: играть можно бесплатно и бессрочно, платят немногие. Первые ближе к триалу.

Модели монетизации: где freemium, а где подписочная модель

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

Для аналитика это различие практическое. Если вход через freemium, а оплата подпиской, метрик две группы: как бесплатные пользователи становятся платящими (конверсия по когортам, время до оплаты) и как платящие остаются (продления, отток, MRR и ARR). Первая группа отвечает за границу бесплатного, вторая — за то, стоит ли платный тариф своих денег.

Юнит-экономика freemium: из чего она складывается

В обычной юнит-экономике считают, сколько стоит привлечь клиента и сколько он принесёт. У freemium есть третья статья: бесплатные пользователи ничего не платят, но потребляют серверы, хранилище и поддержку. Их стоимость ложится на платящих.

Отсюда главное неравенство модели. Возьмём всех активных пользователей за месяц, платящих и нет. Выручка на одного активного — ARPU — равна доле платящих, умноженной на ARPPU, выручку на платящего. Если обслуживание одного активного пользователя стоит больше ARPU, продукт теряет деньги на каждом человеке ещё до затрат на привлечение и команду.

Из формулы видно, что у freemium три рычага: доля платящих, ARPPU и стоимость обслуживания. Щедрая бесплатная версия обычно поднимает привлечение и снижает долю платящих, скупая — наоборот. Нормальной конверсии «для freemium вообще» не существует: допустимая доля платящих зависит от ARPPU и от того, сколько стоит держать бесплатного пользователя. Сервису со стоимостью обслуживания в центы хватит маленькой доли, сервису с дорогими вычислениями на каждого — нет.

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

Почему средняя конверсия в платящих вводит в заблуждение

Вернёмся к спору из начала. Конверсия в платящих — доля зарегистрировавшихся, кто хоть раз заплатил. У неё есть встроенная ловушка: человек платит не в день регистрации, а через какое-то время. Свежие когорты ещё не прожили это время, и их доля платящих занижена.

В учебной базе «Маяка» пользователь регистрируется без оплаты и платит, если ему нужен тариф basic, pro или team. По форме это freemium; что именно закрыто тарифами, база не хранит. Регистрации идут с 1 июня по 29 августа 2026 года, выгрузка закрыта 30 августа в 13:00. Первый шаг — узнать, через сколько дней после регистрации приходит первая оплата.

select
  min(p.paid_at - u.signup_date) as first_day,
  max(p.paid_at - u.signup_date) as last_day,
  count(*) as first_payments
from payments p
join users u on u.user_id = p.user_id
where p.payment_type = 'first';

Как считать долю платящих по когортам с окном зрелости

Все 912 первых оплат пришли на 3–20-й день после регистрации. Значит, честное окно — 21 день (дни 0–20), и сравнивать можно только когорты, которые прожили его целиком. Последний полный день в выгрузке — 29 августа, поэтому зрелые когорты — зарегистрированные по 9 августа включительно. Запрос считает обе версии метрики: наивную (заплатил когда угодно до выгрузки) и с окном.

with first_pay as (
  select user_id, paid_at
  from payments
  where payment_type = 'first'
)
select
  cast(date_trunc('month', u.signup_date) as date) as cohort_month,
  count(*) as users,
  round(100.0 * count(f.user_id) / count(*), 1) as naive_pct,
  count(*) filter (where u.signup_date <= date '2026-08-09') as mature_users,
  count(*) filter (where u.signup_date <= date '2026-08-09'
                     and f.paid_at - u.signup_date <= 20) as payers_21d,
  round(100.0 * count(*) filter (where u.signup_date <= date '2026-08-09'
                                   and f.paid_at - u.signup_date <= 20)
        / nullif(count(*) filter (where u.signup_date <= date '2026-08-09'), 0), 1) as pct_21d
from users u
left join first_pay f on f.user_id = u.user_id
group by 1
order by 1;

• Июнь: 282 из 1042 заплатили, 27,1% в обеих версиях — все июньские пользователи давно прожили 21 день.
• Июль: 374 из 1676, 22,3% в обеих версиях по той же причине.
• Август: наивно 13,5%, а по зрелым когортам 1–9 августа — 100 из 489, 20,4%.

Что даёт разрез по каналам

Окно убрало половину «падения», но снижение с 27,1% до 20–22% осталось. Прежде чем винить бесплатный тариф, проверим состав когорт. Запрос делит зрелых пользователей на июньских и зарегистрированных с 1 июля по 9 августа и считает долю заплативших за 21 день в каждом канале.

with first_pay as (
  select user_id, paid_at
  from payments
  where payment_type = 'first'
)
select
  u.channel,
  count(*) filter (where u.signup_date < date '2026-07-01') as june_users,
  round(100.0 * count(*) filter (where u.signup_date < date '2026-07-01'
                                   and f.paid_at - u.signup_date <= 20)
        / nullif(count(*) filter (where u.signup_date < date '2026-07-01'), 0), 1) as june_pct,
  count(*) filter (where u.signup_date >= date '2026-07-01') as later_users,
  round(100.0 * count(*) filter (where u.signup_date >= date '2026-07-01'
                                   and f.paid_at - u.signup_date <= 20)
        / nullif(count(*) filter (where u.signup_date >= date '2026-07-01'), 0), 1) as later_pct
from users u
left join first_pay f on f.user_id = u.user_id
where u.signup_date <= date '2026-08-09'
group by u.channel
order by u.channel;

Что делают будущие платящие до первой оплаты

Второй вопрос о границе: какое действие в бесплатной версии связано с оплатой. В «Маяке» есть четыре ключевых действия — создать рабочее пространство, отчёт, отправить приглашение коллеге, выгрузить данные. Все они в базе случаются в первые три дня после регистрации (дни 0–2), а первая оплата — не раньше третьего дня. Поэтому всё, что сделано в дни 0–2, гарантированно сделано до оплаты, и обратной зависимости «заплатил, потом пригласил» здесь нет.

with cohort as (
  select
    u.user_id,
    u.signup_date,
    exists (
      select 1 from payments p
      where p.user_id = u.user_id
        and p.payment_type = 'first'
        and p.paid_at - u.signup_date <= 20
    ) as paid
  from users u
  where u.signup_date <= date '2026-08-09'
),
early as (
  select
    c.user_id,
    c.paid,
    max(case when e.event_name = 'workspace_created' then 1 else 0 end) as workspace,
    max(case when e.event_name = 'report_created' then 1 else 0 end) as report,
    max(case when e.event_name = 'invite_sent' then 1 else 0 end) as invite,
    max(case when e.event_name = 'export_completed' then 1 else 0 end) as exported
  from cohort c
  left join events e
    on e.user_id = c.user_id
   and cast(e.event_time as date) - c.signup_date <= 2
  group by c.user_id, c.paid
)
select
  case when paid then 'заплатили за 21 день' else 'не заплатили' end as grp,
  count(*) as users,
  round(100.0 * avg(workspace), 1) as workspace_pct,
  round(100.0 * avg(report), 1) as report_pct,
  round(100.0 * avg(invite), 1) as invite_pct,
  round(100.0 * avg(exported), 1) as exported_pct
from early
group by paid
order by paid desc;

Пригласил коллегу — значит, заплатит? Проверка внутри каналов

Таблица выше подсказывает, что выгрузка с оплатой не связана, а у остальных трёх действий разница есть, но скромная: от 3,6 до 7,2 пункта. Соблазн — объявить самое «сильное» действие причиной оплаты и строить вокруг него границу. Сначала стоит проверить, не прячется ли за связью канал: если пользователи из рекомендаций и чаще создают отчёты, и чаще платят, связь «отчёт → оплата» может быть связью «канал → оба». Запрос сравнивает долю заплативших с действием и без него отдельно в каждом канале.

with cohort as (
  select
    u.user_id,
    u.channel,
    exists (
      select 1 from payments p
      where p.user_id = u.user_id
        and p.payment_type = 'first'
        and p.paid_at - u.signup_date <= 20
    ) as paid,
    exists (
      select 1 from events e
      where e.user_id = u.user_id
        and e.event_name = 'report_created'
        and cast(e.event_time as date) - u.signup_date <= 2
    ) as report,
    exists (
      select 1 from events e
      where e.user_id = u.user_id
        and e.event_name = 'invite_sent'
        and cast(e.event_time as date) - u.signup_date <= 2
    ) as invite
  from users u
  where u.signup_date <= date '2026-08-09'
)
select
  channel,
  count(*) as users,
  round(100.0 * avg(case when paid then 1 else 0 end) filter (where report), 1) as pay_if_report,
  round(100.0 * avg(case when paid then 1 else 0 end) filter (where not report), 1) as pay_if_no_report,
  round(100.0 * avg(case when paid then 1 else 0 end) filter (where invite), 1) as pay_if_invite,
  round(100.0 * avg(case when paid then 1 else 0 end) filter (where not invite), 1) as pay_if_no_invite
from cohort
group by rollup (channel)
order by channel nulls last;

• Связь отчёта с оплатой внутри каналов разваливается: в органике её нет совсем, у пользователей из рекомендаций создавшие отчёт платят даже реже. Если подставить в запрос workspace_created, картина та же: в referral 30,2% против 34,6%. Общая разница в значительной мере объясняется тем, что в разных каналах приходят люди с разной привычкой создавать отчёты.
• Приглашение коллеги держит знак во всех четырёх каналах: плюс 2–6 пунктов. Это самый устойчивый сигнал из четырёх действий, но слабый.
• Это связь, а не причина. Возможно, приглашают и платят одни и те же люди — те, у кого в компании есть задача на команду. Тогда, если заставить всех приглашать коллег, оплат не прибавится. Проверить причинность можно только экспериментом: например, сделать приглашение заметнее в онбординге для случайной половины новых пользователей и сравнить долю платящих в одинаковом окне.

За какие тарифы платят в первый раз

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

select
  plan,
  count(*) as first_payments,
  round(100.0 * count(*) / sum(count(*)) over (), 1) as share_pct,
  sum(amount) as revenue
from payments
where payment_type = 'first'
group by plan
order by first_payments desc;

• Больше половины первых оплат — basic, но pro и team вместе дают 56,3% выручки первых оплат. Бесплатная версия конкурирует прежде всего с basic, поэтому пересматривать её нужно вместе с ним.
• Командный тариф team — 11,2% первых оплат. Если граница проводится по числу участников, именно эта доля должна расти после её изменения.

Сколько стоят бесплатные пользователи: условная модель

Теперь главное неравенство. Затрат на обслуживание в учебной базе нет, поэтому стоимость одного активного пользователя ниже задана условно: 0,50, 1,50 и 3,00 доллара в месяц. Всё остальное посчитано по базе за август: активные — кто сделал хоть одно событие в августе, бесплатные — активные, которые не платили ни разу, выручка — все оплаты августа.

with active as (
  select distinct user_id
  from events
  where event_time >= timestamp '2026-08-01'
    and event_time <  timestamp '2026-09-01'
),
ever_paid as (
  select distinct user_id from payments
),
august as (
  select
    (select count(*) from active) as active_users,
    (select count(*) from active a
      where a.user_id not in (select user_id from ever_paid)) as free_users,
    (select count(distinct user_id) from payments
      where paid_at >= date '2026-08-01' and paid_at < date '2026-09-01') as payers,
    (select sum(amount) from payments
      where paid_at >= date '2026-08-01' and paid_at < date '2026-09-01') as revenue
),
cost_per_user (cost) as (
  values (0.50), (1.50), (3.00)
)
select
  c.cost as cost_per_active_user,
  a.active_users,
  a.free_users,
  a.revenue,
  round(a.revenue / a.active_users, 2) as arpu,
  round(a.revenue / a.payers, 2) as arppu,
  c.cost * a.free_users as free_users_cost,
  round(100 * c.cost * a.free_users / a.revenue, 1) as free_cost_pct_of_revenue,
  a.revenue - c.cost * a.active_users as left_after_serving_all
from august a
cross join cost_per_user c
order by c.cost;

• Порог модели — ARPU: 15 788 / 4109 = 3,84 доллара. При такой стоимости обслуживания выручка августа целиком уходит на то, чтобы держать продукт открытым.
• При 3 долларах на пользователя бесплатные съедают почти две трети выручки. Здесь граница бесплатного становится вопросом выживания, а не роста: либо дешеветь в обслуживании, либо поднимать долю платящих, либо сужать бесплатную версию.
• Модель грубая: в ней одинаковая стоимость для всех, хотя активный пользователь с большими отчётами стоит дороже открывшего приложение раз в месяц. В реальном продукте стоимость считают по фактическому потреблению ресурсов и делят на сегменты.
• Деталь из данных: 49 из 642 августовских плательщиков в августе продукт не открывали. Такие люди платят и почти ничего не стоят, но это первые кандидаты на отток.

Где провести границу бесплатного и как проверять её данными

Граница отвечает на вопрос, за что человек заплатит, когда получит достаточно ценности. Типов границ четыре, и у каждого своя проверка. Общее правило: бесплатная версия должна доводить человека до первой ценности (то, что меряет activation rate), а предел — срабатывать у тех, кому продукт уже нужен.

Как менять границу и не обмануть себя

Изменение границы — продуктовая гипотеза, и проверять её лучше A/B-тестом на новых пользователях: старые уже привыкли к прежнему пределу. Метрик минимум две — доля платящих в одинаковом окне и удержание бесплатных. Сужение почти всегда поднимает первую и опускает вторую; решение принимают по сумме: сколько платящих и выручки приходит с когорты за полный цикл, а не за первую неделю.

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

Типичные ошибки

• Граница так щедра, что платить незачем. Признак: бесплатные пользователи активны и остаются, но почти никто не упирается в предел, а платящие — в основном те, кому нужна одна редкая функция. Проверка: распределение использования относительно лимита.
• Граница так скупа, что бесплатная версия не показывает ценность. Признак: люди упираются в предел раньше, чем доходят до первой ценности, и уходят, а не платят. Проверка: activation rate и удержание бесплатных до и после изменения.
• Сравнение конверсии разных когорт без окна. Свежие когорты не успели заплатить; на учебной базе это превращает 20,4% в 13,5%. Окно берут по данным: от регистрации до момента, к которому приходит почти вся первая оплата.
• Одна средняя конверсия на весь продукт. Состав аудитории меняется вместе с каналами, и средняя падает, даже если в каждом канале ничего не изменилось. Сначала разрез по сегментам, потом выводы о тарифе.
• Вывод о причинности из связи «пригласил → заплатил». Действие и оплата могут иметь общую причину — тип пользователя. Связь подсказывает, что тестировать; доказывает только эксперимент.
• Стоимость бесплатных не учитывается в экономике. Без неё freemium выглядит дешёвым каналом привлечения, хотя каждый бесплатный пользователь стоит денег каждый месяц.

Частые вопросы

Итог

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

На учебной базе это видно на одном примере: наивный график показывал падение конверсии вдвое, честное окно и разрез по каналам свели его к новому рекламному каналу, а самое «сильное» действие перед оплатой оказалось следом канала. Все запросы выполняются на продуктовой базе; в Симуляторе SQL-аналитика когорты, активацию и выручку считают на ней же.