Funnel conversion: как считать продакту

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Что такое воронка и зачем она нужна

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

Без воронки оптимизация продукта — это палец в небо. Можно полгода крутить кнопку «Купить», а проблема была на регистрации. Воронка показывает узкое место, и там стоит копать в первую очередь.

На собесе тебя почти наверняка попросят построить воронку для какого-то сценария. Не надо сразу писать SQL — сначала уточни шаги, источник идентификатора пользователя, окно и определение каждого события. Это половина оценки.

Пошаговая конверсия

Пошаговая конверсия — доля пользователей, дошедших с шага N до шага N+1.

CR(шаг N → N+1) = пользователей, прошедших шаг N+1 / пользователей, прошедших шаг N

Пример. Из 10 000 посетителей лендинга 4 000 нажали «Зарегистрироваться» (CR1 = 40%). Из них 2 800 завершили регистрацию (CR2 = 70%). Из них 700 совершили первое целевое действие (CR3 = 25%).

Эта декомпозиция полезна, потому что узкое место сразу видно. Здесь — переход «начал регистрацию → завершил» (70% — приличный), но самое слабое — финальное действие (25%). Туда и копать.

Пошаговая конверсия не должна превышать 100%. Если получилось — где-то ошибка. Часто это значит, что в шаг N+1 попадают люди, которые не проходили шаг N (например, пришли по другой ссылке).

Сквозная конверсия

Сквозная конверсия — доля пользователей, дошедших с первого шага до конкретного.

CR(1 → N) = пользователей, прошедших шаг N / пользователей, прошедших шаг 1

В примере выше сквозная конверсия лендинг → первое действие = 700 / 10 000 = 7%. Это интегральная цифра для канала или продукта.

Сквозная и пошаговая связаны:

CR(1 → N) = CR(1→2) * CR(2→3) * ... * CR(N-1→N)

40% * 70% * 25% = 7%. Совпало. Это полезное правило для проверки.

В отчётах обычно показывают обе. Сквозная даёт понять масштаб, пошаговая — где затыкается.

Окно воронки

Главный нюанс воронки — окно между шагами. Если пользователь зашёл на лендинг 1 апреля, а зарегистрировался 15 апреля — он в воронке или нет?

Без окна — да, всё, что было после, считается. Тогда сквозная конверсия высокая, но плохо отражает скорость продукта. Условные «вернутся через год» искажают статистику.

С окном — только если шаг произошёл в N часов/дней после предыдущего. Окно подбирается под продукт: для покупки в e-commerce — день, для регистрации в SaaS — неделя, для первого использования — месяц.

Окно должно быть одинаковым для каждого шага и явно указано в дашборде. Без этого воронка двух команд считает разные вещи.

Воронка по когортам

Воронка одной кучей — это среднее по больнице. Поделишь по когортам — увидишь динамику и аномалии.

Когорта по дате первой активности. Все, кто впервые зашёл в продукт 1 апреля, проходят воронку отдельно от тех, кто зашёл 2 апреля. Сравниваешь сквозную конверсию когорт — видишь, не сломал ли ты что-то в обновлении.

Когорта по источнику. Контекст, таргет, органика, реферальные. Часто разные источники дают радикально разный профиль воронки: органика лучше конвертится в действие, платный — в регистрацию.

Когорта по сегменту. Регион, устройство, платформа. Веб и мобайл могут отличаться на любом шаге.

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

Воронка в SQL

Базовая идея: для каждого пользователя посчитать, дошёл ли он до каждого шага в нужном окне.

WITH first_step AS (
  SELECT user_id, MIN(created_at) AS step1_at
  FROM events
  WHERE event_name = 'landing_view'
  GROUP BY user_id
),
step2 AS (
  SELECT f.user_id, MIN(e.created_at) AS step2_at
  FROM first_step f
  JOIN events e
    ON e.user_id = f.user_id
   AND e.event_name = 'signup_started'
   AND e.created_at >= f.step1_at
   AND e.created_at <  f.step1_at + INTERVAL '7 day'
  GROUP BY f.user_id
),
step3 AS (
  SELECT s.user_id, MIN(e.created_at) AS step3_at
  FROM step2 s
  JOIN events e
    ON e.user_id = s.user_id
   AND e.event_name = 'signup_completed'
   AND e.created_at >= s.step2_at
   AND e.created_at <  s.step2_at + INTERVAL '7 day'
  GROUP BY s.user_id
)
SELECT
  COUNT(DISTINCT f.user_id)                         AS n_step1,
  COUNT(DISTINCT s2.user_id)                        AS n_step2,
  COUNT(DISTINCT s3.user_id)                        AS n_step3,
  COUNT(DISTINCT s2.user_id)::NUMERIC
    / NULLIF(COUNT(DISTINCT f.user_id), 0)          AS cr_1_2,
  COUNT(DISTINCT s3.user_id)::NUMERIC
    / NULLIF(COUNT(DISTINCT s2.user_id), 0)         AS cr_2_3
FROM first_step f
LEFT JOIN step2 s2 USING (user_id)
LEFT JOIN step3 s3 USING (user_id);

Что важно. MIN(created_at) для каждого шага — берём самое раннее событие, иначе при множественных сработает в том числе и более позднее, и порядок ломается. >= step_prev — следующий шаг строго после предыдущего, иначе пользователь, посмотревший лендинг после регистрации, формально пройдёт воронку, что неправильно. NULLIF(..., 0) — защита от деления на ноль и от integer division.

Частые ошибки

Считать воронку без окна. Все события за всё время попадают в шаг — конверсии завышены, динамика теряется.

Не следить за порядком событий. Если шаг 2 случился раньше шага 1, такой пользователь не должен попадать в воронку. Часто такое бывает с пользователями, мигрировавшими из старой версии.

JOIN-ить события без агрегата по пользователю. Если у пользователя 5 заходов на лендинг и 3 регистрации, JOIN раздует строки до 15. Считать COUNT(DISTINCT user_id), а не COUNT(*).

Считать пошаговую конверсию от общего числа, а не от предыдущего шага. Это будет сквозная, не пошаговая. Подменять одно другим — обычная ошибка.

Игнорировать сегментацию. Веб и мобайл, новые и старые пользователи, регионы — разные воронки. Усреднение скрывает важное.

Сравнивать воронки разной длины. Если в одной 3 шага, а в другой 5, сквозная конверсия будет ниже у второй просто из-за длины. Сравнивай одинаковые шаги.

Связанные темы

FAQ

Чем воронка отличается от cohort-анализа?

Воронка смотрит на путь пользователя по шагам, cohort — на удержание во времени. Часто их совмещают: строят воронку отдельно для каждой когорты.

Как выбрать окно для воронки?

По типичному циклу пользователя в продукте. Если средняя регистрация занимает день, окно неделя — нормально. Если месяц — окно длиннее. Слишком короткое окно занижает конверсию, слишком длинное даёт ложно красивую картинку.

Сколько шагов в воронке оптимально?

Достаточно, чтобы видеть узкое место, но не больше. 3–6 шагов в одной воронке — рабочий диапазон. Если больше, разбей на несколько воронок.

Можно ли считать воронку по сессиям, а не по пользователям?

Можно, если важен внутрисессионный путь. Но обычно бизнес интересует именно пользователь — он принимает решение во времени, а не в одной сессии.

Что делать, если на одном шаге огромный отвал?

Копать. Сегментировать по устройствам, источникам, версиям приложения. Часто отвал даёт конкретная связка, и общий процент скрывает локальную проблему.

Как воронка связана с активацией?

Активация — это конкретный целевой шаг воронки, обычно «aha-момент». Activation rate = сквозная конверсия от старта до этого шага.


Тренируйте продуктовую аналитику — откройте тренажёр с 1500+ вопросами для собесов.