Аналитик смотрит промежуточные результаты каждый день, но команда заранее зафиксировала fixed horizon: тест идёт 14 дней, и решение принимают только по финальному анализу в конце. Что наиболее корректно про влияние такого peeking на Type I error для основной проверки?
A
Type I error неизбежно сильно растёт, даже если решение принимают только в концеB
Type I error не меняется только если отключить randomization и раздать варианты вручнуюCЕсли действительно соблюдён
fixed horizon и план не меняют по ходу, то контроль Type I error сохраняетсяDНужно обязательно применять
alpha spending, даже если досрочная остановка никогда не используетсяПравильный ответ. Если решение строго принимают только в конце по заранее заданному
fixed horizon и план не меняют, то формальный контроль Type I error для основной проверки сохраняется.Разбор
Проблема появляется, когда peeking влияет на stopping rule или на выбор метрик, сегментов и длительности теста. Если вы просто наблюдаете, но вывод делаете строго по финальной проверке в заранее заданный момент, то обычная интерпретация p-value остаётся корректной. На практике стоит учитывать человеческий фактор: промежуточные цифры часто провоцируют optional stopping.
Проверь себя · 1/3разбор после ответа
У вас нет инфраструктуры для
sequential testing, но команда хочет минимизировать риски от peeking. Какой подход самый безопасный и простой?Ещё вопросы по теме «Секвенциальное тестирование»
- Команда запускает `A/B test` и каждый день смотрит `p-value`; как только видит `p-value < alpha`, сразу завершает и объявляет победу. В чём главный риск такого `peeking`?
- Что лучше всего описывает `stopping rule` в контексте `sequential testing`?
- Что такое `alpha spending` в `sequential testing`?
- Почему в корректном `sequential testing` порог для ранней остановки обычно более строгий, чем в конце эксперимента?
- Стейкхолдеры хотят еженедельные апдейты и возможность остановить тест раньше, если уже «всё ясно». Что лучше сделать до запуска?
- Все вопросы по «Секвенциальное тестирование» →