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

Здесь интервьюер смотрит не на знание формул, а на дисциплину: умеешь ли ты договориться о правилах игры ДО старта. Половина «провальных» тестов проваливается на планировании, а не на матане.

Как рассуждать

Веди рассказ по этапам и на каждом называй решение, которое надо принять заранее. Ключевая мысль: все пороги — метрику, α, мощность, размер выборки, длительность — фиксируем до начала. Как только начал двигать правила по ходу теста (подсматривать, докидывать пользователей до значимости), статистика перестаёт работать, а вероятность ложного вывода уезжает вверх.

Эталонный ответ

1. Гипотеза и метрика. Одна основная метрика (например, конверсия в покупку), плюс 1–2 контрольные (guardrail), чтобы не сломать выручку ради кликов. Гипотеза формулируется как «новая кнопка поднимет конверсию с 10% до 11%».

2. Пороги. Задаём α — вероятность ошибки первого рода, обычно 0.05, и мощность 80% (то есть допускаем 20% ошибки второго рода). И главное — MDE, минимальный эффект, который вообще имеет смысл ловить.

3. Размер выборки. Под выбранные α, мощность и MDE считаем, сколько нужно наблюдений на группу — отдельный вопрос со своей формулой. Из размера выборки и дневного трафика получаем длительность.

4. Рандомизация. Делим пользователей случайно и на уровне пользователя, а не сессии, иначе один человек попадёт в обе группы. Проверяем, что группы сопоставимы (A/A-тест или sanity-check по базовым метрикам).

5. Сбор и анализ. Набираем заранее посчитанную выборку целиком. Сравниваем группы: для конверсий — z-тест долей, для среднего чека — t-тест или бутстрап. Смотрим на p-value и на доверительный интервал разницы.

6. Решение. Значимость плюс размер эффекта плюс guardrail-метрики. «Значимо, но +0.05% при разработке на месяц» — это «нет». И наоборот: красивый рост, который не дотянул до значимости, — это ещё не «фича не работает», а «данных не хватило, чтобы утверждать». Хороший финал разбора — проговорить, что делаем с незначимым результатом: катим дальше по другим соображениям, докручиваем гипотезу или закрываем.

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

• Peeking — подсматривать и останавливать тест в момент, когда p-value случайно провалился ниже 0.05. Это раздувает ошибку первого рода в разы; нужен либо фиксированный размер выборки, либо последовательные методы с поправкой.
• Крутить много метрик и радоваться любой значимой — это проблема множественных сравнений.
• Останавливать тест, «как только стало значимо», игнорируя недельную сезонность: гоняем целое число недель.
• Мерить сессии вместо пользователей и ловить утечку между группами.
• Забыть про MDE и запустить тест, который физически не мог поймать реалистичный эффект при таком трафике.
• Не проверить группы на сопоставимость до старта: если рандомизация сломана и в контроле случайно оказались более активные юзеры, результат не спасёт никакая статистика.