Peeking в A/B-тестах: почему нельзя остановиться раньше

Peeking — многократный просмотр результата с решением остановить обычный фиксированный тест, как только p-value пересёк желаемый порог. Каждый новый шанс остановиться на случайном всплеске повышает общий риск ложноположительного вывода.

Проблема не в открытом dashboard. Мониторить здоровье эксперимента можно и нужно: распределение трафика, ошибки, sample ratio mismatch, технические guardrails. Нарушение возникает, когда решение о победе принимают по обычному порогу, хотя число и моменты проверок не были учтены в статистической процедуре.

Даже при нулевом эффекте накопленная разница колеблется. Если ждать первого удачного пересечения, редкое событие со временем становится гораздо вероятнее.

Фиксированный горизонт

Простой надёжный подход — заранее определить размер выборки и минимальную длительность, дождаться обоих условий и провести основной анализ один раз. План фиксирует primary metric, MDE, alpha, мощность, правила исключения и допустимые аварийные остановки.

Остановка из-за поломки или вреда отличается от объявления победителя. Если guardrail показывает серьёзный риск, эксперимент можно прекратить ради безопасности, но нельзя затем выдавать обычный p-value за результат заранее запланированного финального анализа.

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

Последовательные методы

Если бизнесу нужно принимать решение по мере накопления трафика, применяют group sequential design, alpha spending, always-valid p-values или байесовское правило с заранее заданными порогами. У каждого метода собственный контракт и предпосылки; просто смотреть на обычный t-тест каждый час недостаточно.

Защитите процесс организационно: план эксперимента сохраняется до запуска, dashboard разделяет health и outcome, а аналитический код воспроизводим. После завершения показывают весь путь накопления данных, но вывод строят по выбранной процедуре.

Главная идея: частота просмотра должна быть частью дизайна. Тогда ранняя остановка может быть корректной; без такого дизайна она систематически выбирает удачный шум.

Почему двадцать просмотров не равны одному тесту

Пусть команда проверяет двадцать независимых гипотез без реальных эффектов, каждую с alpha=0,05. Вероятность хотя бы одного ложного срабатывания — 1 минус вероятность, что все двадцать проверок обошлись без него. Посчитаем эту величину.

alpha, independent_checks = 0.05, 20
chance_any = 1 - (1-alpha)**independent_checks
print(round(chance_any, 3))
assert 0.64 < chance_any < 0.65

Получится примерно 64,2%. Это иллюстрация множественных независимых проверок. Ежедневные просмотры одного A/B-теста зависимы, поэтому число нельзя объявлять точным риском двадцати дней наблюдения. Проблема остаётся: остановка при первом удобном p-value меняет процедуру.

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

Продолжите разбор: Bootstrap в A/B-тестах: доверительный интервал.