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