Продуктовая аналитика: метрики, воронки и A/B-тесты на примере

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

В нашем сервисе команда замечает: людей приходит больше, а платных подписок почти не прибавляется. Продуктовый аналитик уточняет, где возник разрыв: изменился источник привлечения, сломалось событие оплаты или пользователи перестали доходить до первой тренировки. Затем предлагает способ проверить объяснение. Рабочий результат — обоснованное решение и описание того, насколько ему можно доверять.

Название должности не гарантирует одинаковый набор задач. В небольшой команде один человек может готовить витрину, строить дашборд и помогать с экспериментом. Поэтому при выборе направления смотрите на конкретную работу: интересно ли вам формулировать проверяемые вопросы, искать ошибки и объяснять неопределённость, а не только писать SQL.

Начните со схемы событий и проверки данных

Событие — запись о действии: пользователь зарегистрировался, завершил тренировку или оплатил подписку. Для нашего исследования нужны signup_completed, workout_completed и subscription_paid. Нажатие кнопки оплаты не заменяет подтверждённый платёж: первое говорит о намерении, второе — о результате. Сумму и статус платежа надёжнее сверять с серверной системой учёта.

Перед расчётом пройдите сценарий тестовым аккаунтом и сопоставьте действия с журналом. Проверьте обязательные поля, повторные event_id, неизвестные названия, невозможные даты и долю записей без user_id. Отдельно сравните оплаченные заказы с платёжной системой. Исключение тестовых аккаунтов должно быть одинаковым во всех отчётах; произвольная чистка после получения результата меняет смысл сравнения.

Воронка и конверсия: сначала договоритесь о знаменателе

Возьмём когорту: 1 000 новых аккаунтов, впервые зарегистрированных с 1 по 7 сентября включительно, без сотрудников и тестовых пользователей. Для каждого наблюдаем семь суток после регистрации: интервал от момента регистрации включительно до момента регистрации плюс семь суток, не включая правую границу. Выгрузку делаем после окончания окна последнего участника с запасом на доставку событий.

Из этой тысячи 600 человек завершили хотя бы одну тренировку в своём окне. Из этих 600 ровно 120 затем оплатили подписку до конца того же окна. Все шаги должны происходить в заданном порядке; другие действия между ними допустимы. Такой порядок — отдельная настройка воронки, описанная и в документации Amplitude. Покупателя, оплатившего до первой тренировки, в финальный шаг этой конкретной воронки не включаем.

20% и 12% одновременно верны: у них разные знаменатели. Ошибка возникает, если назвать оба числа просто «конверсией в оплату» без определения. Общая конверсия зарегистрированных в любую оплату может быть выше 12%, если кто-то покупает до тренировки. Для неё нужен отдельный расчёт, без требования пройти промежуточный шаг.

Потеря 400 человек до первой тренировки подсказывает область исследования, но не причину. Разбейте воронку по платформе и источнику, проверьте ошибки запуска, изучите обращения. Если выросла доля менее заинтересованной аудитории, общая конверсия способна упасть без ухудшения интерфейса. Наблюдаемая связь ещё не доказывает действие конкретной функции.

SQL: проверить временной порядок на маленьких данных

Ниже самостоятельный пример для PostgreSQL: таблицы создавать не нужно, данные заданы через VALUES. Он иллюстрирует общую конверсию из регистрации в оплату за семь суток, без обязательной тренировки. Пользователь 1 оплатил дважды, пользователь 2 — только до регистрации, пользователь 3 — ровно на правой границе. Правильный результат: три регистрации, один покупатель, 33,33%.

WITH signups(user_id, signup_at) AS (
  VALUES
    (1, TIMESTAMPTZ '2026-09-01 10:00:00+00'),
    (2, TIMESTAMPTZ '2026-09-01 10:00:00+00'),
    (3, TIMESTAMPTZ '2026-09-01 10:00:00+00')
), payments(user_id, paid_at) AS (
  VALUES
    (1, TIMESTAMPTZ '2026-09-02 10:00:00+00'),
    (1, TIMESTAMPTZ '2026-09-03 10:00:00+00'),
    (2, TIMESTAMPTZ '2026-08-31 10:00:00+00'),
    (3, TIMESTAMPTZ '2026-09-08 10:00:00+00')
), users AS (
  SELECT s.user_id, EXISTS (
    SELECT 1 FROM payments p
    WHERE p.user_id = s.user_id
      AND p.paid_at >= s.signup_at
      AND p.paid_at < s.signup_at + INTERVAL '168 hours'
  ) AS converted
  FROM signups s
)
SELECT COUNT(*) AS registered,
       COUNT(*) FILTER (WHERE converted) AS buyers,
       ROUND(100.0 * COUNT(*) FILTER (WHERE converted)
             / NULLIF(COUNT(*), 0), 2) AS conversion_pct
FROM users;

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

Retention: возвращаются ли люди за пользой

Удержание, или retention, требует двух определений: какое действие вводит пользователя в когорту и какое означает возвращение. В Amplitude это starting event и return event. Для нашего сервиса началом возьмём первую завершённую тренировку, возвращением — следующую завершённую тренировку. Открытие приложения показывает другую степень вовлечённости и даст другое число.

Пусть у 600 участников предыдущей когорты первая тренировка случилась в семидневном окне. Из них 210 завершили хотя бы одну тренировку в интервале от 7 × 24 до 14 × 24 часов после первой. Удержание во второй неделе равно 210 / 600 = 35%. Это недельное удержание активированных пользователей, а не доля вернувшихся из всех 1 000 зарегистрированных и не retention ровно седьмого дня.

Рассчитывать его можно, только когда у каждого участника полностью прошло окно возвращения. Поздние участники не должны получать меньше времени. Сравнивайте когорты одинакового возраста и с одинаковыми правилами: например, первую и вторую неделю сентября после завершения наблюдения. Даже при одинаковом возрасте различия каналов привлечения или сезонность могут мешать объяснить изменение.

Основная метрика и ограничения для изменения

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

Защитные метрики, или guardrails, помогают увидеть цену улучшения. Для примера заранее зададим допустимые изменения частоты ошибок запуска, обращений в поддержку на нового пользователя и семидневной конверсии в любую оплату. Удержание оценим позже, когда созреет его окно. Численные пороги команда выбирает из стоимости ущерба и возможностей измерения, а не переносит из чужого продукта.

Как спланировать A/B-тест и прочитать результат

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

1. Зафиксируйте условия участия, распределение 50/50, основную метрику и семидневное окно каждого пользователя. Считайте всех распределённых подходящих участников, включая тех, кто не начал тренировку.
2. По историческим данным оцените базовую долю и трафик именно этой аудитории. Задайте минимальный обнаруживаемый эффект — MDE, уровень значимости и мощность. Например, рост с 60% до 63% означает +3 процентных пункта, или +5% относительно базы.
3. До запуска рассчитайте выборку и календарный план. Меньший MDE требует больше данных; мощность 80% означает шанс обнаружить заданный эффект при его наличии и принятых предположениях. Это не вероятность успешности продуктовой идеи.
4. Проверьте назначение вариантов, события и соответствие фактических размеров групп ожидаемому распределению. Значимый Sample Ratio Mismatch — повод разобраться с экспериментом, а не объявлять победителя.
5. Завершите набор по заранее выбранному правилу и дождитесь полного окна последнего участника. В обычном тесте с фиксированным горизонтом нельзя ежедневно останавливать эксперимент при первом p-value ниже 0,05. Для такого решения нужны заранее выбранные последовательные методы.

Предположим, в отдельном учебном эксперименте набрали по 5 000 пользователей: в A тренировку завершили 3 000, в B — 3 150. Доли равны 60% и 63%, наблюдаемая разница — +3 процентных пункта. При независимых наблюдениях приблизительный 95%-й интервал разницы по нормальной аппроксимации составляет от +1,09 до +4,91 процентного пункта. Это расчёт для завершённого сравнения двух групп, без поправок на многократные проверки.

Интервал описывает точность оценки при предположениях метода: процедура построения 95%-х интервалов при повторениях покрывает истинный эффект примерно в 95% случаев. p-value оценивает, насколько необычны данные при нулевой гипотезе и модели теста; он не равен вероятности, что гипотеза верна. Статистическая значимость также не определяет окупаемость изменения.

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

Что изучать и положить в первое портфолио

Начните с SQL: фильтры, соединения, группировки, оконные функции и даты. Затем добавьте описательную статистику, доверительные интервалы, проверку гипотез и визуализацию. Python удобен для воспроизводимых расчётов и проверки качества; инструмент продуктовой аналитики — для исследования событий. Освоение интерфейса сервиса не заменяет понимания метрики.

• Словарь событий с полями, моментом отправки и примерами проверок качества.
• Описание когорты и метрик: единица анализа, знаменатель, окно, исключения и границы времени.
• SQL и небольшой набор данных с дублями, ранней оплатой и неполным наблюдением; ожидаемые результаты.
• Воронка и когортная таблица с пояснением, какие сравнения корректны.
• План эксперимента с основной метрикой, MDE, выборкой, защитными метриками и правилом завершения.
• Короткая записка: что обнаружено, чего данные не доказывают и какое решение предлагается.

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