A/B-тесты для продакт-менеджера с нуля
Содержание:
Зачем PM понимать A/B
A/B-тесты — главный инструмент валидации продуктовых гипотез. PM запускает тест каждый раз, когда меняет что-то значимое: новый онбординг, ценник, дизайн кнопки, ML-модель.
Без понимания A/B PM либо доверяет интуиции (часто ошибается), либо слепо следует выводам аналитика. Цель — уметь дизайнить тест и интерпретировать результат на уровне «достаточно для решения, без формул».
Этапы дизайна A/B-теста
- Гипотеза — что меняем и почему ждём эффекта
- Метрики — primary, secondary, guardrails
- Сегментация — кто попадёт в тест
- Размер выборки — на основе MDE и текущей дисперсии
- Длительность — по выборке + минимум 1-2 недели для эффекта недели
- Анализ — после набора выборки
- Решение — раскат, отказ, итерация
Гипотеза и метрики
Хорошая гипотеза:
Если мы добавим кнопку «купить в один клик» в карточку товара, конверсия в покупку вырастет на 5% за счёт сокращения шагов в воронке.
Содержит: что меняем, почему ждём эффекта, насколько.
Primary metric — главная метрика, по которой принимаем решение. Должна быть одна.
Secondary metrics — поддерживающие. Если primary вырос, но secondaries упали — повод задуматься.
Guardrail metrics — не должны ухудшиться. Latency, error rate, NPS, churn premium-юзеров. Если guardrail упал значимо — раскат отменяется.
Пример для теста новой формы регистрации:
- Primary: конверсия из visitor в зарегистрированного
- Secondary: время до первого действия после регистрации
- Guardrail: time-to-load формы, ошибки сервера
Размер выборки
Главный вопрос: «Сколько юзеров нужно в каждую группу?» Зависит от:
- Baseline conversion — текущая метрика
- MDE (Minimum Detectable Effect) — минимальный эффект, который хотим уверенно ловить
- Statistical power — обычно 80%
- Significance level — обычно 5%
Калькулятор выборки доступен в Evan Miller, Stats Engine. Pop-rule: чем меньше baseline и MDE, тем больше выборка нужна.
Пример: при baseline 5% и MDE 0.5% (relative 10%) нужно ~30 000 юзеров на группу.
PM не считает sample size руками — спрашивает аналитика. Но должен понимать, почему «5% лифт нужно проверить на 10к юзерах за 2 дня» обычно нереалистично.
Анализ результата
После набора выборки смотрите:
- Sample Ratio Mismatch (SRM) — соотношение групп близко к 50/50? Если нет (например, 51/49 на большой выборке) — есть баг в randomization. Тест нельзя анализировать.
- P-value на primary — < 0.05 значит эффект значим
- Effect size — не только статистически значим, но и бизнесово важен
- Guardrails — не упали значимо
- Сегментный анализ — эффект на конкретных сегментах
Решение:
- Все ОК → раскат
- Primary не значим, но guardrails упали → отказ
- Primary значим, но sub-сегмент пострадал → раскат с эксклюзией сегмента или итерация
Что должен делать PM, а что аналитик
PM делает:
- Гипотеза, бизнес-обоснование
- Выбор primary metric (с консультацией аналитика)
- Решение по результату
Аналитик делает:
- Дизайн теста (sample size, randomization)
- Имплементация трекинга
- Анализ p-value, ДИ, сегментов
- Технические рекомендации
PM, который пытается «делать всю аналитику» — забирает время от своих задач. Аналитик, у которого нет PM в процессе, делает технически правильный, но бизнесово бесполезный тест.
Частые ошибки
Несколько primary metrics. «Если конверсия или retention улучшились — раскатываем». Это multiple testing. Только одна primary.
Останавливать тест при p<0.05. Peeking. Тест должен идти до выборки.
Игнорировать guardrails. Конверсия выросла, но churn premium-юзеров вырос ещё больше. Net negative.
Тестировать слишком много вариантов. A/B/C/D/E на 5 групп — каждая группа маленькая, сложно интерпретировать. Лучше 2 итерации с фокусом.
Не учитывать недели. Бизнес-метрики имеют недельную сезонность. Тест на 3 дня может попасть на праздник или конец месяца. Минимум 7-14 дней.
FAQ
Сколько A/B-тестов в год — норма?
Зависит от размера команды и трафика. Стартап — 2-4 в месяц на команду. Большая платформа — десятки одновременно.
Что делать с тестом, который не значим?
«Не значимо» ≠ «нет эффекта». Возможно, выборки не хватило. Решения:
- Если эффект ноль на ДИ → бросаем гипотезу
- Если эффект мал, но в правильную сторону → бросаем (не окупится)
- Если ДИ широкий → может быть эффект, но нужно больше данных
Это официальная информация?
Нет. Статья основана на индустриальных практиках.