Как продакт-менеджеру запустить эксперимент с нуля

Когда нужен эксперимент, а когда нет

Не каждую фичу надо A/B-тестить. Эксперимент имеет смысл, когда:

• Есть заметная неопределённость по эффекту.
• Можно поделить трафик и измерить разницу.
• Цена ошибки выше цены теста.

Не имеет смысла, когда фича обязательная (юр. требование), очевидно полезная (баг-фикс), или когда трафика слишком мало для значимости. Также бессмысленен тест на одной маленькой команде или на B2B-продукте, где у каждого клиента свои особенности и их 30 штук всего.

Эксперимент — не «всегда круто», а инструмент против дорогих ошибок. Делать пять тестов в неделю на маленьком продукте — стрелять в воздух. На каждый тест уходит время разработки, аналитики и приоритетный слот в продукте. Если у вас DAU 500, а ожидаемый эффект 1 п.п. — лучше ничего не тестить, а принять решение качественно.

Дерево решений «надо ли тестить»: можно ли откатить → есть ли трафик на MDE за разумный срок → есть ли заметная неопределённость → дороже ли ошибка теста. Если на любой из вопросов «нет» — выбираем другой инструмент: внутренняя бета, dogfooding, soft launch на одной стране.

1. Гипотеза по шаблону

Гипотеза начинается с проблемы, не с решения. Шаблон:

Пример:

Без шаблона гипотеза превращается в «давайте попробуем X» — это не гипотеза, это импульс.

Антипатерны формулировок:

• «Хотим протестировать новый дизайн». Это не гипотеза, нет ни проблемы, ни ожидаемой метрики.
• «Думаю, конверсия вырастет». Без оценки эффекта и механизма не отличишь шум от результата.
• «Если запустим — людям понравится». «Понравится» — не метрика.
• «Тест поможет понять, что лучше». Что мерим, по какому критерию выбираем — не сказано.

2. Дизайн-док эксперимента

Документ на 1–2 страницы перед стартом. Что в нём:

• Контекст и гипотеза.
• Что меняем (мокапы, ссылки на тикеты).
• Аудитория теста (новые / все / по сегменту).
• Сплит (50/50, 90/10, и так далее).
• Главная метрика.
• Защитные метрики (минимум 2: одна продуктовая — retention, churn; одна техническая — ошибки, скорость).
• Минимально интересный эффект (MDE).
• Размер выборки и срок.
• Кто принимает решение по результату.
• Что делаем при положительном/отрицательном/нулевом исходе.

Док обсуждается с аналитиком и тимлидом до запуска. Без подписи аналитика не катим.

Главный смысл дока — заранее зафиксировать критерий успеха. После запуска уже нельзя «передумать» какую метрику считать главной.

Мини-шаблон дока (можно скопировать в Notion):

Гипотеза: ...
Что меняем: ...
Аудитория и сплит: новые пользователи, 50/50
Главная метрика: конверсия из регистрации в активацию
Защитные: D7 retention, P95 latency, % ошибок
MDE: +2 п.п. (с 38% до 40%)
Длительность: 14 дней
Размер выборки: 12 000 на группу
Решение принимает: PM + аналитик
Если +: раскатываем 100%
Если 0: не раскатываем, фиксируем
Если -: откатываем, разбираем причину

3. Расчёт выборки и срока

Грубая формула для пропорций (конверсия): нужный размер выборки на группу ≈ 16 × p × (1 − p) / Δ², где p — базовая конверсия, Δ — минимально интересный эффект в долях.

Пример: базовая конверсия 10%, хотим поймать +1 п.п. (Δ = 0.01).

n ≈ 16 × 0.1 × 0.9 / 0.0001 = 14400 на группу, то есть 28800 всего.

При DAU 2000 и сплите 50/50 это 28800 / 2000 = 14 дней. Если меньше — недомощь, выводы шумные.

Реальные расчёты делаешь через калькулятор (G*Power, evanmiller.org), формула выше — для прикидки. На собесе уметь сказать порядок — уже хорошо.

Длительность эксперимента — обычно не меньше двух недель, чтобы захватить разные дни недели. Если у вас сильный B2B, у которого есть рабочие/выходные циклы — две полные недели обязательно.

Ориентир по MDE и сроку при разных размерах продукта (порядки величин, не гарантия):

DAU	Базовая конверсия	MDE +1 п.п.	MDE +2 п.п.	MDE +5 п.п.
500	10%	~58 дней	~14 дней	~3 дня
2 000	10%	~14 дней	~4 дня	<2 дней
10 000	10%	~3 дня	<2 дней	<1 дня
50 000	10%	<1 дня	<1 дня	<1 дня

Если MDE меньше реалистичного эффекта — тест проще не запускать, либо принять что результат будет «не значимо».

4. Запуск и мониторинг

Первые часы:

• Проверить, что сплит работает: попадание в группы примерно равное (A/A-проверка), нет смещения по странам/устройствам.
• Технические метрики не упали: ошибки, время загрузки, краши.
• Главная метрика логирует.

Если в первые часы что-то критично сломалось — катим обратно, не ждём.

Дальше — не подсматривать в результаты каждый день и не делать выводов. Ранняя «победа» в A/B обычно регрессирует к среднему. Смотришь промежуточно один-два раза и финально — в запланированный день.

Чек-лист «всё ли в порядке в день запуска»:

• A/A: распределение пользователей по контролю и тесту примерно равное (отклонение <1%).
• Главная метрика логируется в обеих группах.
• Не сломались технические метрики (ошибки, latency, краши).
• Нет смещения по сегментам (страна, платформа, источник).
• Аналитик подтвердил, что данные пишутся корректно.

5. Анализ и решение

В день окончания эксперимента:

• Считаешь главную метрику с доверительным интервалом.
• Смотришь защитные.
• Делаешь сегментацию (новые/старые, мобильные/десктоп, страны).
• Сравниваешь с тем, что зафиксировано в дизайн-доке.

Решение:

• Положительный эффект, защитные ок → раскатываем.
• Положительный эффект, защитная упала → не раскатываем сразу, ищем причину.
• Нулевой эффект → не раскатываем, фиксируем что научились.
• Отрицательный эффект → не раскатываем, разбираемся почему гипотеза была неверна.

После раската — мониторишь долгосрочный эффект 1–2 месяца. Многие фичи откатываются именно тут.

Шаблон отчёта по результату (важно для архива и собесов):

• Гипотеза в одно предложение.
• Что меняли.
• Главная метрика: значение в контроле, значение в тесте, доверительный интервал, p-value.
• Защитные метрики: что произошло.
• Сегментация: где эффект сильнее/слабее.
• Решение и обоснование.
• Что узнали — урок на будущее.

Альтернативы A/B-тесту

Когда A/B-тест не подходит — есть варианты:

• Pre/post сравнение. Меряем метрику до изменения и после. Минус: всё, что произошло за это время (сезонность, маркетинг), смешивается с эффектом фичи.
• Geo-тест. В одной стране катим, в другой — нет. Подходит для маркетинговых и крупных продуктовых изменений. Минус: страны не идентичны.
• Switchback. Часть времени включаем, часть выключаем. Подходит для marketplace-продуктов, где нельзя поделить пользователей.
• Holdout. 95% аудитории получают новую фичу, 5% не получают долго (3–6 месяцев). Меряем долгосрочное влияние. Хорошо для тех фич, эффект которых проявляется не сразу.
• Soft launch. Запускаем в одной стране/команде, смотрим качественно, потом раскатываем.

Каждый из методов имеет свои ограничения, важно их явно прописать в выводах.

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

• Запуск без дизайн-дока. Через две недели спор «а главная метрика была эта или эта».
• Подсматривание и «остановка по победе». Нарушает статистику, эффект преувеличен.
• Слишком много метрик. С 10 метриками одна обязательно покажет «значимость» по случайности (multiple testing).
• Игнор защитных метрик. Конверсия вверх, churn вверх — нетто-минус.
• Сегментация после факта. Если в общем эффект 0, но «у молодых пользователей +5%» — это не результат, это p-hacking, нужно подтверждать в новом тесте.
• Тест на слишком маленькой выборке. Недомощность = «не нашли эффект» ≠ «эффекта нет».
• Раскат на 100% без долгосрочного мониторинга.
• Параллельные тесты на одном экране — невозможно разделить эффекты.
• Использование p-value как единственного критерия — без размера эффекта и интервалов решение принимать опасно.

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

• Как оценить эффект фичи
• Что такое A/B-тест простыми словами
• Как вести беклог продукта
• Как поставить цели на квартал продукту

FAQ

Можно ли запускать эксперимент без аналитика?

Дизайн-док — желательно с аналитиком, легко промахнуться с MDE и сегментацией. На зрелом продукте без аналитика тесты теряют смысл.

Что делать, если эксперимент идёт две недели и эффект всё ещё нулевой?

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

Сколько экспериментов параллельно можно?

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

Как объяснить стейкхолдеру, что нужны 4 недели на тест?

Через MDE: при текущих DAU и базовой конверсии меньший срок не поймает эффект. Документ с расчётом снимает споры.

Что если A/B-тест запретили из-за продуктовых соображений?

Использовать pre/post или geo-тест. Описать в выводах ограничения метода.

Что такое peeking problem?

Это когда смотришь на промежуточные результаты и принимаешь решение раньше срока. Из-за случайных колебаний эффект может «казаться» значимым, а на финале — пропасть. Снижает истинную мощность теста.

Как часто эксперименты дают нулевой результат?

Часто — порядка 60–80% запусков на зрелых продуктах не дают значимого эффекта. Это норма, не повод грустить. Хорошая growth-команда учится на этих результатах не меньше, чем на «победах».

Можно ли использовать байесовский подход?

Да, многие команды переходят на байесовский A/B (вероятность того, что вариант лучше). Это не отменяет дизайн-док и расчёт выборки.

---

Тренируйте кейсы по A/B и продуктовой аналитике — откройте Карьерник с 2500+ вопросами.