Продакт-менеджер и эксперименты: как ставить и читать A/B

Зачем продакту эксперименты

Любая фича на масштабе — это эксперимент. Если ты выкатываешь изменение на 100% пользователей и смотришь «стало лучше или нет», ты не знаешь ответа: рост может быть из-за сезонности, маркетинга, погоды. A/B-тест — единственный способ отделить эффект фичи от шума.

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

Простой ментальный приём: каждый раз, когда вы говорите «давайте раскатим и посмотрим», задайте себе вопрос «как мы поймём, что эффект — это от нашего изменения, а не от внешних факторов?». Если ответа нет — это не релиз, это лотерея. A/B нужен ровно в этих случаях.

Гипотеза и метрика

Эксперимент начинается не с раскатки, а с гипотезы. Хорошая гипотеза формулируется так: «Если сделать X, то метрика Y изменится на Z, потому что W».

Пример:

• Плохо: «давайте поменяем цвет кнопки».
• Хорошо: «если изменить кнопку с серой на красную, конверсия в покупку вырастет на 1.5–3%, потому что красный заметнее на странице с текстом».

Метрика должна быть:

• Одна основная (primary). Все остальные — guardrail или secondary.
• Чувствительная — двигается от изменений быстро.
• Связанная с бизнесом — а не «кликов на кнопку».
• Измеряемая — её можно посчитать в системе аналитики.

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

Шаблон гипотезы для записи в документе эксперимента: «Проблема: X. Гипотеза: если сделать Y, то метрика Z изменится на N (диапазон), потому что W. Primary: Z. Guardrails: A, B. Сегмент: ...». Любая гипотеза, которую нельзя записать по этому шаблону, — это не гипотеза, а пожелание.

MDE и размер выборки

MDE (Minimum Detectable Effect) — минимальный эффект, который ты сможешь поймать тестом. Если MDE = 5%, а реальный эффект 2% — ты его не увидишь, тест покажет «нет разницы».

MDE зависит от:

• Размера выборки (больше пользователей — меньший эффект ловится).
• Дисперсии метрики (стабильнее метрика — меньший MDE).
• Уровня значимости (обычно ориентир 5%).
• Мощности (обычно ориентир 80%).

Перед тестом продакт обязан посчитать: «У нас Х пользователей в неделю, какой эффект мы можем поймать за 2 недели?» Если выходит MDE 10%, а реалистично ждёшь 2% — тест бессмысленный, надо либо увеличивать выборку, либо менять метрику.

Ориентиры (порядки величин, не гарантии): для конверсии 5% при выборке 50 тысяч на ветку MDE обычно в диапазоне 2–4%. Для метрик с большой дисперсией (например, выручка на пользователя) MDE при той же выборке будет хуже — нередко 10–20%. Точные числа считаются в калькуляторе или формулой через дисперсию метрики.

Что делать, если MDE плохой:

• Увеличить выборку (раскатить шире, ждать дольше).
• Снизить дисперсию (CUPED, стратификация, варианс-редукция).
• Сменить primary-метрику на более чувствительную.
• Признать, что A/B не подходит, и выбрать другой способ оценки.

Дизайн теста

Минимальный чек-лист дизайна:

• Юнит рандомизации. Обычно user_id. Иногда сессия, устройство, аккаунт.
• Длительность. Минимум один полный цикл — неделя, чтобы захватить будни и выходные. Лучше две.
• Сегменты. На какой аудитории катим — все, новые, активные, гео.
• Guardrail-метрики. Что не должно сломаться: латенси, отписки, жалобы.
• A/A-проверка. Если есть платформа экспериментов, проверить её перед серьёзными тестами.
• Решение заранее. Что делаем при росте, падении, отсутствии эффекта. Иначе после теста начнётся торг.

Дизайн пишется до запуска. После запуска править условия — значит, обнулять статистическую корректность.

Элемент дизайна	Типовой выбор	Когда менять
Юнит	user_id	Сессия — для not-logged-in флоу; устройство — для cross-account
Сплит	50/50	90/10 — если много веток или хочется минимизировать риск
Длительность	14 дней	7 — только если очень большой трафик; 28+ — для retention-метрик
Сегмент	Все активные	Новые — для онбординга; активные — для core-флоу

Чтение результатов

Результат теста — это не «зелёное число в дашборде». Это:

• Размер эффекта и доверительный интервал.
• p-value или вероятность по байесу.
• Состояние guardrail-метрик.
• Динамика по дням — нет ли всплеска и просадки.
• Срезы по сегментам — где эффект сильнее, где его нет.

Если эффект значим, но guardrail просел — фичу не катить. Если эффект значим только на одном сегменте — катить только на него.

Важно не подсматривать. Если смотреть на результаты каждый день и останавливать тест на «значимом» дне — вероятность ложно-положительного результата растёт. Либо использовать sequential testing, либо ждать запланированный срок.

Шаблон отчёта по эксперименту: гипотеза → дизайн → результаты по primary → результаты по guardrail → срезы → решение → следующие шаги. Без раздела «решение» отчёт превращается в «мы что-то измерили». Решение должно отвечать на три варианта: катим, не катим, нужен дополнительный тест.

Антипаттерн чтения: смотреть только на p-value. Эффект может быть статистически значим, но практически бесполезен (рост 0.1% при цене разработки в квартал). Всегда смотрите на абсолютный эффект и стоимость удержания фичи.

Когда A/B не работает

Не всё надо тестировать. Эксперимент — дорогой инструмент, и в ряде случаев он либо не нужен, либо не сработает.

Не подходит:

• Очень маленький продукт. Если у тебя 100 пользователей в неделю — A/B не поймает ничего, кроме слона.
• Сильные сетевые эффекты. Соцсеть, маркетплейс — пользователи в группах влияют друг на друга, простой split не работает.
• Юридические/обязательные изменения. Тут не «тестируем», а раскатываем.
• Стратегические решения. Перезапуск продукта не A/B-тестируется.
• Долгосрочные эффекты. Если фича влияет на retention 90 дней — A/B на 2 недели бесполезен.

Альтернативы: switchback, geo-сплиты, holdout-группы, до/после с контролем сезонности.

Полезно для каждого тестируемого изменения сначала спросить: «можно ли это вообще проверить классическим A/B?». Если ответ нет — выбираем альтернативу осознанно, а не «попробуем A/B и посмотрим, что получится».

Шаблон документа эксперимента

Базовая структура, которую полезно держать как шаблон в Notion или Confluence:

• Название и автор.
• Контекст: что за продукт, что за проблема.
• Гипотеза в формате «если — то — потому что».
• Primary-метрика и формула расчёта.
• Guardrail-метрики и пороги, при которых тест останавливается.
• Дизайн: юнит, сплит, сегмент, длительность.
• Расчёт MDE и обоснование длительности.
• План действий: при росте, при падении, при отсутствии эффекта.
• Технические детали: фича-флаг, события для аналитики, где смотреть данные.
• Результат и решение (заполняется после теста).

Если такой документ не пишется до запуска — после запуска начинается «давайте посмотрим, что есть в дашборде» и «а можно ещё посчитать вот так?». Это и есть подгонка результатов под желаемый ответ.

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

• Подглядывать и останавливать рано. Самая дорогая ошибка — решения по 3-дневным результатам.
• Менять условия в середине. Поменял пользовательский сегмент — обнулил тест.
• Не учитывать guardrail. Конверсия выросла, скорость страницы упала — фичу нельзя катить.
• Делать выводы по segment-фарму. Если сделать 20 срезов, в одном-двух всегда будет «значимо». Это шум.
• Игнорировать MDE. Запустили тест без расчёта — получили «нет разницы» и не поняли, это правда или просто маленькая выборка.
• Не считать стоимость поддержки. Победившая фича остаётся в коде навсегда — а каждая лишняя ветка дорожает с годами.
• Оценивать только сразу после теста. Эффект через месяц может развернуться (новизна спадает, привычка проходит).

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

• Hard skills продакт-менеджера
• Discovery в продакт-менеджменте
• A/B-тесты и статистика
• Что такое A/B-тест простыми словами

FAQ

Сколько должен длиться A/B-тест?

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

Какую значимость использовать?

Чаще ориентируются на 5% (alpha = 0.05) и мощность 80%. Это эвристики, можно менять под свои риски.

Что делать, если эффект значим, но guardrail просел?

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

Как понять, что платформа экспериментов работает корректно?

Запускать A/A-тесты — два одинаковых варианта. Если в 95% случаев нет значимого результата — платформа считает корректно.

Можно ли тестировать всё на нескольких метриках сразу?

Можно, но нужна поправка на множественные сравнения (Bonferroni, FDR). Иначе вероятность ложно-положительного результата растёт.

Что такое CUPED простыми словами?

Метод снижения дисперсии метрики за счёт использования предтестового поведения пользователя. На том же размере выборки можно поймать меньший эффект — то есть MDE улучшается.

Сколько A/B-тестов реально побеждает?

По публичным данным крупных компаний — обычно 10–30%. Большинство тестов не показывают значимого эффекта, и это нормально.

Когда катить фичу без A/B?

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

---

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