Пейвол (paywall): что это, виды и как считать конверсию

Коротко

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

• Виды: жёсткий (дальше без оплаты нельзя), мягкий или метерный (N бесплатных материалов или действий), фримиум-граница (платные функции и лимиты), триал (полный доступ на срок).
• Воронка пейвола: показ → начало оформления → оплата или триал → первая оплата после триала → продление.
• Конверсия пейвола = оплатившие после показа / пользователи, которые видели пейвол. Не все пользователи и не все показы.
• Старт триала — ещё не оплата. Конверсию триала в оплату считают отдельно, на триалах, которые уже закончились.
• Смотрите вместе с конверсией выручку на показ, долю продлений и возвраты: конверсию легко поднять, отдав деньги дешёвым тарифом.
• Без события показа пейвола конверсию пейвола не посчитать. По оплатам видно только долю платящих среди зарегистрированных.

Что такое пейвол: в СМИ и в приложениях

Слово пришло из онлайн-СМИ. Там пейвол — ограничение доступа к статьям для читателей без подписки. Самый известный пример метерной модели — The New York Times: в марте 2011 года издание объявило, что читатель без подписки может открыть 20 материалов в месяц, а дальше нужна подписка. Поисковый спрос на «пейвол что это» отчасти именно про СМИ: как он устроен и как его обходят. Здесь не о том.

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

Для аналитика пейвол — шаг воронки монетизации со входом (показ) и выходом (оплата), если в данных есть событие показа.

Какие бывают пейволы

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

Граница между мягким пейволом и фримиумом размыта: лимит в «три проекта бесплатно» — и метерный пейвол, и фримиум-граница. Подробнее о бесплатном тарифе как модели — в статье о фримиуме. Для аналитики важнее не название, а то, в какой момент человек упирается в стену и что видел до неё.

Воронка пейвола: от показа до продления

Воронку пейвола удобно строить по пользователям, а не по показам: один человек может увидеть экран пять раз за неделю. Шаги такие: увидел пейвол → начал оформление (нажал на тариф, открыл форму или системное окно оплаты) → оплатил или начал триал → после триала прошло первое списание → через период прошло продление.

Условный пример. За месяц пейвол увидели 10 000 человек, 1 200 начали оформление, 450 оплатили, через месяц 270 из них продлили подписку. Конверсия показа в оплату — 450 / 10 000 = 4,5%. Из начавших оформление дошли до оплаты 450 / 1 200 = 37,5%: этот шаг про форму оплаты, способы платежа и ошибки списания. Доля продлений — 270 / 450 = 60%.

Последний шаг часто забывают, а он отделяет пейвол, который продаёт подписку, от пейвола, который продаёт один месяц. Как строить и читать воронки в целом — в статье о conversion rate.

Метрики пейвола и их знаменатели

Главная метрика — конверсия пейвола: доля пользователей, которые оплатили после показа, среди тех, кто пейвол видел. Окно фиксируйте заранее: например, оплата в течение 24 часов или 7 дней после первого показа. Без окна конверсия у свежих показов всегда ниже, чем у старых.

Знаменатель — главный источник споров. Вернёмся к ситуации из начала, теперь с условными числами. Новых пользователей за месяц 30 000. Пока пейвол жил в настройках, его видели 3 000, платили 180: 6% от видевших и 0,6% от всех новых. В онбординге его видят 27 000, платят 540: 2% от видевших и 1,8% от всех новых. Конверсия пейвола упала втрое, а платящих стало втрое больше.

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

Выручка на показ (точнее, на пользователя, видевшего пейвол) складывает конверсию и цену в одно число. В примере с воронкой 450 оплат по 500 ₽ — это 225 000 ₽, или 22,5 ₽ на каждого из 10 000 видевших. С учётом продлений за два месяца — (450 + 270) × 500 = 360 000 ₽, 36 ₽ на видевшего. Это ближе к тому, что пейвол даёт бизнесу. Связанные метрики выручки разобраны в статьях об ARPU и ARPPU и LTV по когортам.

Как считать конверсию триала в оплату

Триал — бесплатный или символически платный пробный период, после которого начинается обычная подписка. В App Store, например, бесплатный пробный период — один из видов вводного предложения для автопродлеваемой подписки: подписка начинается сразу, а списание проходит, когда пробный период закончился.

Поэтому старт триала — не оплата. Конверсия триала в оплату = первые успешные списания после триала / триалы, срок которых уже истёк. Триалы, которые ещё идут, в знаменатель не включайте: иначе каждый новый день будет «ухудшать» метрику, хотя ничего не произошло. Если триал требует карту, отмена во время триала — отдельное событие, его полезно считать: это ранний сигнал, что люди не увидели ценности.

Условный пример, как триал обманывает. Вариант с триалом: 10 000 показов, 900 стартов триала (9%), из них 360 заплатили после пробы (40%). Конверсия показа в оплату — 3,6%. Вариант без триала: те же 10 000 показов и 450 прямых оплат, 4,5%. Если «конверсией» назвать старт триала, вариант с триалом выглядит вдвое лучше, хотя платящих в нём меньше. В другом продукте выйдет наоборот — это проверяют экспериментом.

Что видно по оплатам без событий пейвола: время до первой оплаты

Часто аналитику достаётся только таблица оплат: событий показа пейвола никто не логировал. Посмотрим, что из неё можно выжать, на учебной базе «Маяк» — той же, на которой решают задачи в Симуляторе SQL-аналитика. В таблице payments одна строка — успешная оплата, payment_type равен first для первой оплаты и renewal для продления, plan — тариф basic, pro или team. Регистрации идут с 1 июня по 29 августа 2026 года, выгрузка закрыта 30 августа в 13:00.

Первый вопрос — сколько дней проходит от регистрации до первой оплаты. От ответа зависит окно, в котором честно сравнивать когорты, и кое-что о самом пейволе.

with first_payment as (
  select p.user_id, p.paid_at - u.signup_date as days_to_pay
  from payments as p
  join users as u on u.user_id = p.user_id
  where p.payment_type = 'first'
)
select
  case
    when days_to_pay <= 6 then '0–6 дней'
    when days_to_pay <= 13 then '7–13 дней'
    when days_to_pay <= 20 then '14–20 дней'
    else '21 день и позже'
  end as days_bucket,
  min(days_to_pay) as min_days,
  max(days_to_pay) as max_days,
  count(*) as payers,
  round(cast(100.0 * count(*) / sum(count(*)) over () as numeric(18, 6)), 1) as payers_pct,
  round(cast(100.0 * sum(count(*)) over (order by min(days_to_pay))
    / sum(count(*)) over () as numeric(18, 6)), 1) as cumulative_pct
from first_payment
group by 1
order by min_days;

Как читать время до оплаты

Из 912 первых оплат ни одна не случилась в первые три дня после регистрации, 23,1% пришлись на первую неделю, 63,9% — на первые две, и все уложились в 20 дней. Июньские когорты наблюдаются почти три месяца, и даже у них нет ни одной первой оплаты позже 20-го дня, так что это не обрезка выгрузкой.

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

Практический вывод — окно. Когорты регистраций сравнивают по доле оплативших в фиксированное число дней после регистрации. На этой базе окно — 21 день (дни 0–20). Если в вашем продукте оплаты приходят и позже, возьмите окно, покрывающее 90–95% первых оплат у старых когорт.

Доля платящих по когортам: почему последний месяц «падает»

Теперь доля платящих среди зарегистрированных по месяцам регистрации — двумя способами. Наивно: все, кто оплатил к моменту выгрузки. Честно: только дозревшие пользователи, у которых прошёл 21 день после регистрации (регистрация не позже 9 августа: 9 августа + 20 дней = 29 августа, последний полный день), и оплата в этом окне.

with first_payment as (
  select user_id, paid_at
  from payments
  where payment_type = 'first'
),
cohort as (
  select
    cast(date_trunc('month', u.signup_date) as date) as signup_month,
    u.signup_date,
    f.paid_at,
    u.signup_date <= date '2026-08-09' as is_mature
  from users as u
  left join first_payment as f on f.user_id = u.user_id
)
select
  signup_month,
  count(*) as users,
  count(paid_at) as payers_by_export,
  round(cast(100.0 * count(paid_at) / count(*) as numeric(18, 6)), 1) as naive_pct,
  count(*) filter (where is_mature) as mature_users,
  count(*) filter (where is_mature and paid_at <= signup_date + 20) as payers_21d,
  round(cast(100.0 * count(*) filter (where is_mature and paid_at <= signup_date + 20)
    / nullif(count(*) filter (where is_mature), 0) as numeric(18, 6)), 1) as payers_21d_pct
from cohort
group by signup_month
order by signup_month;

Что показывает сравнение когорт

Наивная доля в августе — 13,5%, вдвое ниже июньской. Отчёт с таким числом выглядит как авария. Но 1 406 из 1 895 августовских пользователей ещё не прожили 21 день: многие из них заплатят позже. Среди дозревших августовских (489 человек, регистрация 1–9 августа) платят 20,4% — против 22,3% в июле. Разница небольшая, а дозревшая часть августа — всего девять дней регистраций, так что выводы о ней осторожные.

Июнь и июль сравнивать можно: обе когорты дозрели. Снижение с 27,1% до 22,3% — настоящее, и его стоит раскладывать по каналам, устройствам и составу трафика, прежде чем винить пейвол. Как это делают, разобрано в статье о когортном анализе.

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

Тарифы первой оплаты и средний чек

Пейвол показывает не только «платить или нет», но и что выбрать. Посмотрим, как распределяются первые оплаты по тарифам и как меняется средний первый чек от месяца к месяцу. Суммы в базе — в долларах: basic стоит 19, pro — 29, team — 39 в месяц.

select
  coalesce(cast(cast(date_trunc('month', paid_at) as date) as varchar), 'всего') as first_month,
  count(*) as first_payments,
  round(cast(100.0 * count(*) filter (where plan = 'basic') / count(*) as numeric(18, 6)), 1) as basic_pct,
  round(cast(100.0 * count(*) filter (where plan = 'pro') / count(*) as numeric(18, 6)), 1) as pro_pct,
  round(cast(100.0 * count(*) filter (where plan = 'team') / count(*) as numeric(18, 6)), 1) as team_pct,
  round(cast(avg(amount) as numeric(18, 6)), 2) as avg_first_check
from payments
where payment_type = 'first'
group by rollup (cast(date_trunc('month', paid_at) as date))
order by first_month;

Зачем следить за тарифами вместе с конверсией

Больше половины первых оплат — basic, средний первый чек — 24,48 $. В июне basic выбирали чаще (62,3%), и чек был ниже: 23,85 $ против 24,64 $ в июле. Сдвиг небольшой, но именно так выглядит эффект, который на пейволе легко пропустить: доля платящих не изменилась, а смесь тарифов — да.

Обратная ситуация опаснее. Условный пример: вариант A пейвола выделяет тариф за 990 ₽, вариант B — за 690 ₽. На 10 000 показов A собирает 300 оплат, B — 360. Конверсия выросла на 20%, команда празднует. Выручка: 300 × 990 = 297 000 ₽ против 360 × 690 = 248 400 ₽, или 29,7 ₽ против 24,84 ₽ на показ — минус 16,4%. Поэтому рядом с конверсией пейвола всегда показывайте выручку на показ и средний чек, о нём есть отдельная статья — средний чек.

Доля продлений после первой оплаты

Продление показывает, продал ли пейвол подписку или один месяц. В базе «Маяк» каждое продление списывается ровно через 30 дней после предыдущей оплаты. Значит, честный знаменатель — первые оплаты, у которых срок продления уже наступил: оплаченные до 30 июля включительно (30 июля + 30 дней = 29 августа). Для второго продления — первые оплаты до 30 июня.

with first_payment as (
  select user_id, paid_at as first_paid_at
  from payments
  where payment_type = 'first'
),
renewals as (
  select user_id, count(*) as renewals
  from payments
  where payment_type = 'renewal'
  group by user_id
),
joined as (
  select
    cast(date_trunc('month', f.first_paid_at) as date) as first_month,
    f.first_paid_at,
    coalesce(r.renewals, 0) as renewals
  from first_payment as f
  left join renewals as r on r.user_id = f.user_id
)
select
  first_month,
  count(*) as first_payments,
  count(*) filter (where renewals >= 1) as renewed_by_export,
  count(*) filter (where first_paid_at <= date '2026-07-30') as due_1,
  count(*) filter (where first_paid_at <= date '2026-07-30' and renewals >= 1) as renewed_1,
  round(cast(100.0 * count(*) filter (where first_paid_at <= date '2026-07-30' and renewals >= 1)
    / nullif(count(*) filter (where first_paid_at <= date '2026-07-30'), 0) as numeric(18, 6)), 1) as renewed_1_pct,
  count(*) filter (where first_paid_at <= date '2026-06-30' and renewals >= 2) as renewed_2
from joined
group by first_month
order by first_month;

Что показывают продления

Если поделить всех продливших на все первые оплаты, выйдет 290 / 912 = 31,8%. Это число занижено почти вдвое: 410 августовских плательщиков просто не дожили до даты продления. Среди тех, у кого срок наступил, продлили 283 из 493 — 57,4%: 60,5% у июньских и 55,8% у июльских. В июле столбец renewed_by_export больше, чем renewed_1: девять человек впервые заплатили 31 июля, семеро из них продлились 30 августа, а этот день выгрузка застала только до 13:00. Такие строки в знаменатель не берут.

Второе продление видно только у июньских: из 101 продлившего ещё раз заплатили 47, то есть 46,5%. От всех 167 июньских плательщиков до третьей оплаты дошли 28,1%. Это и есть цена, которую видит бизнес: из десяти первых оплат к третьему месяцу остаются меньше трёх. О том, как эти доли превращаются в отток и MRR, — в статьях о churn rate и retention и об MRR и ARR.

Каких событий не хватает, чтобы посчитать конверсию пейвола

В базе «Маяк» есть оплаты, но нет ни одного события пейвола. Поэтому на ней нельзя узнать главное: сколько людей видели экран подписки, где и сколько раз, сколько начали оформление и бросили, сколько стартовали триал. Доля платящих среди зарегистрированных — лучшее, что тут доступно, и это не конверсия пейвола.

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

with paywall_events(user_id, event_time, event_name, placement) as (
  values
    (101, timestamp '2026-08-01 10:00', 'paywall_shown', 'onboarding'),
    (101, timestamp '2026-08-01 10:01', 'checkout_started', 'onboarding'),
    (101, timestamp '2026-08-01 10:03', 'purchase_completed', 'onboarding'),
    (102, timestamp '2026-08-01 11:00', 'paywall_shown', 'onboarding'),
    (103, timestamp '2026-08-02 09:00', 'paywall_shown', 'limit_reached'),
    (103, timestamp '2026-08-02 09:02', 'checkout_started', 'limit_reached'),
    (104, timestamp '2026-08-02 12:00', 'paywall_shown', 'limit_reached'),
    (104, timestamp '2026-08-02 12:01', 'checkout_started', 'limit_reached'),
    (104, timestamp '2026-08-02 12:04', 'trial_started', 'limit_reached'),
    (105, timestamp '2026-08-03 08:00', 'paywall_shown', 'onboarding'),
    (105, timestamp '2026-08-04 19:30', 'paywall_shown', 'onboarding')
)
select
  placement,
  count(*) filter (where event_name = 'paywall_shown') as shows,
  count(distinct user_id) filter (where event_name = 'paywall_shown') as users_shown,
  count(distinct user_id) filter (where event_name = 'checkout_started') as users_checkout,
  count(distinct user_id) filter (where event_name = 'purchase_completed') as users_paid,
  count(distinct user_id) filter (where event_name = 'trial_started') as users_trial
from paywall_events
group by placement
order by placement;

Что тестировать на пейволе и какие guardrail-метрики держать

Пейвол — одно из самых частых мест для A/B-тестов, потому что каждая правка сразу видна в деньгах. Обычно тестируют:

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

Почему конверсию пейвола нельзя оптимизировать отдельно

Единица рандомизации в таком тесте — пользователь, а не показ: варианты меняют то, сколько раз и кому экран показывается, и «конверсия на показ» в вариантах получается на разных знаменателях. Основная метрика — выручка на пользователя, попавшего в тест, за фиксированный горизонт (например, 30 дней, за вычетом возвратов). Как её выбирать — в статьях об A/B-тестировании и об основной метрике и guardrail.

Агрессивный пейвол легко поднимает быстрые оплаты, и платят за это три вещи. Продления: «дожатый» на третьей минуте человек чаще не продлевает. Возвраты: оплату, о которой жалеют, отзывают через поддержку или магазин приложений. И те, кто не заплатил: жёсткий экран отрезает людей, которые заплатили бы через неделю, — в «Маяке» первые оплаты растянуты на три недели.

Поэтому в тесте пейвола держите guardrail-метрики: долю продлений у первых оплат, возвраты и отмены триала, возврат неплатящих на 7-й и 30-й день. Продления созревают только через период подписки — значит, решение по тесту либо ждёт этот срок, либо принимается по ранним данным, а когорта теста досматривается позже и решение пересматривается.

Типичные ошибки при анализе пейвола

Почти все ошибки сводятся к неверному знаменателю или неверному моменту сравнения.

• Делить оплаты на всех пользователей или на всех активных и называть это конверсией пейвола. Это доля платящих, а не качество экрана.
• Считать на показах вместо пользователей: частые повторные показы занижают конверсию, а их сокращение «улучшает» её без изменений в продукте.
• Сравнивать недозревшие когорты: свежая неделя регистраций или оплат всегда выглядит хуже, как август в примере выше.
• Считать старт триала оплатой. Триал — обещание; оплата — первое списание после него.
• Считать долю продлений по всем первым оплатам, включая тех, чей срок продления ещё не наступил: на учебной базе это 31,8% вместо 57,4%.
• Радоваться росту конверсии, не глядя на средний чек и смесь тарифов: дешёвый тариф по умолчанию поднимает конверсию и роняет выручку.
• Сравнивать месячные и годовые планы по одной доле продлений: у годового продление через год, и в месячной когорте его просто нет.

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

Итог

Конверсия пейвола — доля оплативших среди тех, кто видел пейвол, в фиксированном окне. Её нельзя посчитать без события показа и нельзя оптимизировать без выручки на показ, продлений и возвратов. На учебной базе без событий пейвола четыре запроса всё же дали рабочую картину: первые оплаты растянуты на три недели, «падение» августа почти целиком объясняется незрелостью, а доля продлений после первой оплаты — 57,4%, а не 31,8%.

Такие расчёты — оплаты, когорты, продления — можно повторить в Симуляторе SQL-аналитика: там та же база «Маяк» и задачи на воронку, когорты и эксперимент.