Если A/B стартует без pre-analysis plan, это не эксперимент, а повод для холивара

Типичный сценарий: релиз откатили, потому что “просела конверсия”, но в другом отчёте “всё ок”. Продакт просит ещё денёк подождать, маркетинг находит “победу” в сегменте, аналитик спорит про статистику, а инженер говорит, что логирование меняли вчера. Цена простая: вы принимаете решение не на данных, а на том, кто убедительнее.

Почему так происходит? Потому что в момент, когда уже видны цифры, мозг начинает торговаться: можно поменять метрику, окно, фильтры, сегменты, “исправить” выбросы, выбрать другой способ агрегации. Любой из этих ходов иногда оправдан, но без заранее зафиксированных правил это превращается в подгонку. И самое токсичное: спорят не про продукт, а про интерпретацию.

Один документ в формате RFC или pre-analysis plan обычно снимает 80% споров ещё до старта. Минимальный стандарт, который я бы требовал в команде:

  1. Формулировка решения: что именно считаем успехом и какое действие последует. Не “проверить гипотезу”, а “катим на 100% если… / откатываем если…”.

  2. Единица рандомизации и единица анализа: кто получает вариант (пользователь, устройство, сессия) и на чём считаем метрики. Несовпадение тут часто убивает доверие к эффекту.

  3. Метрики: одна primary, 2–3 guardrails. Guardrails заранее ограничивают “победили любой ценой” и защищают от локальной оптимизации.

  4. Сегменты: какие сегменты смотрим как диагностические, а не как отдельные “победы”. Если сегмент заранее не прописан, он не должен менять решение, максимум объяснять поведение.

  5. Критерии остановки и риски данных: когда можно смотреть результат, когда нельзя, что делаем при дропе событий, смене трекинга, всплеске ботов, задержках ETL. Если data quality под вопросом, эксперимент не “плохой”, он просто неинтерпретируемый.

В правильной практике этот документ живёт как контракт между продуктом, аналитикой и разработкой: что меряем, как принимаем решение, какие красные флаги останавливают тест. Обычно спорят про “можно ли смотреть по ходу” и “а давайте добавим ещё метрику” — и это нормально, если изменения фиксируются как новая версия плана до того, как вы увидели финальные цифры. Граница применимости простая: для UI-микроправок иногда достаточно облегчённого варианта, но для любых решений с риском на деньги или доверие — без плана лучше не начинать.