Ранний стоп A/B по принципу «уже значимо» — красный флаг: вы меряете не эффект, а терпение команды.
Сценарий знакомый: на третий день p-value красивый, стейкхолдеры уже мысленно делят победу, и начинается торг: «давайте выключим тест, чтобы быстрее катить». Цена ошибки — не только неправильный релиз. Хуже другое: после пары таких «побед» к экспериментам перестают относиться как к инструменту, и дальше любые цифры воспринимаются как манипуляция.
Почему это ломается: когда вы смотрите на результаты каждый день и готовы остановиться в любой момент, вы фактически увеличиваете шанс поймать случайный всплеск. Плюс метрики часто имеют автокорреляции, циклы по дням недели, задержки в поведении. В итоге «значимо сейчас» означает только «сейчас шум сложился удачно».
Минимум, который нужно зафиксировать ДО старта, чтобы ранний стоп был легитимным:
- Допустимые точки принятия решения: либо фиксированный горизонт, либо заранее выбранный последовательный подход, а не «в любой день, когда понравилось».
- Минимальная длительность: не «пока не значимо», а «пока не пройдём базовые циклы поведения» и не соберём стабильную картину по ключевым сегментам.
- Правила сезонности и календаря: что делаем с праздниками, распродажами, релизами маркетинга, сдвигами трафика. Если событие попадает в окно — тест не «дожимают», а переоценивают пригодность данных.
- Набор метрик и приоритет: одна primary для решения, ограниченный список guardrails. Никаких подмен «главной метрики» по ходу, даже если она «лучше отражает продукт».
- Критерии валидности данных: проверки на SRM, дубликаты, лаги, изменения трекинга, стабильность разметки. Если флаг поднялся — стоп по качеству, а не стоп «потому что победили».
В правильной практике это выглядит скучно: короткий документ с правилами остановки и интерпретации, который подписан до запуска и одинаково защищает и «плюс», и «минус». Обычно спорят про скорость, но доверие к экспериментациям дешевле удержать заранее, чем потом отмывать после пары ранних остановок.
