Урок курса
Peeking в A/B-тестах: почему нельзя остановиться раньше
A/B тесты и анализ данных на PythonPeeking — многократный просмотр результата с решением остановить обычный фиксированный тест, как только 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, а аналитический код воспроизводим. После завершения показывают весь путь накопления данных, но вывод строят по выбранной процедуре.
Главная идея: частота просмотра должна быть частью дизайна. Тогда ранняя остановка может быть корректной; без такого дизайна она систематически выбирает удачный шум.
Попробуйте решить
Какой просмотр во время фиксированного A/B-теста сам по себе не создаёт peeking?
Продолжить с проверкой и прогрессом
Откройте интерактивный раннер с заданиями урока.
