Команда хочет иметь возможность останавливать эксперимент раньше, если эффект явно плохой или явно хороший. Что лучше всего сделать, чтобы снизить риск peeking?
AЗаранее определить правила ранней остановки и использовать согласованный критерий (например, последовательный подход), а не принимать решение по «глазу»
BОстанавливать, когда менеджер считает, что данных достаточно
CВсегда смотреть метрики каждый час и останавливать на пике
DЗапускать тест только в выходные, чтобы быстрее увидеть эффект
Правильный ответ. Если нужна ранняя остановка, правила должны быть заранее определены, иначе
peeking делает выводы ненадёжными.Разбор
Ранняя остановка возможна, но она должна быть частью заранее согласованного процесса. Иначе вы многократно проверяете гипотезу и рискуете остановиться на случайном колебании. Правильная практика — зафиксировать, при каких условиях эксперимент останавливается по primary metric и guardrail metric, и придерживаться этих условий.
Проверь себя · 1/3разбор после ответа
После запуска вы выяснили, что часть пользователей видит
treatment на вебе и control в приложении из-за разных систем флагов. В чём главная проблема?Ещё вопросы по теме «A/B-тесты в продуктовой аналитике»
- Какая формулировка лучше всего соответствует проверяемой `hypothesis` для `A/B test`?
- Что в `A/B test` обычно означает разделение на `control` и `treatment`?
- Вы тестируете новую страницу товара; цель — увеличить покупки. Какая метрика наиболее логична как `primary metric` для решения о запуске?
- Вы увеличиваете частоту push-уведомлений, ожидая рост заказов. Какая метрика наиболее уместна как `guardrail metric`?
- Когда `A/B test` обычно предпочтительнее, чем сразу делать полный `rollout` изменения?
- Все вопросы по «A/B-тесты в продуктовой аналитике» →