Если A/B запускается без единого RFC-шаблона — вы тестируете не фичу, а удачу.
Узнаваемая картина: команда “быстро катнём”, метрику выберем по ходу, сегменты посмотрим “на всякий”, остановим когда “уже видно”. Потом начинается магия: один дашборд показывает рост, другой — падение, продукт верит тому, что ближе к плану, аналитик превращается в адвоката. Цена — неверные решения и потеря доверия к экспериментам как к инструменту.
Проблема не в статистике, а в отсутствии фиксации договорённостей до старта. Когда нет предзаданной гипотезы, метрик, дизайна, плана анализа и критериев остановки, у вас появляется бесконечный простор для “чуть-чуть иначе посчитать”. Даже честные люди в такой системе неизбежно подгоняют вывод под ожидания — просто потому что вариантов интерпретации слишком много.
Минимальный RFC для каждого эксперимента (один документ, одна версия правды):
- Гипотеза и ожидаемое направление эффекта: что именно должно измениться и за счёт какого поведения.
- Метрики и guardrails: одна основная метрика решения + список метрик, которые нельзя ухудшать, иначе эксперимент считается токсичным.
- Дизайн: единица рандомизации, целевая популяция, окна измерения, обработка повторных пользователей, что делаем с ботами/аномалиями.
- Расчёт мощности: минимально значимый эффект, допущения по базовой конверсии/дисперсии, требуемый объём и длительность. Без этого “не хватает трафика” обнаруживается слишком поздно.
- План анализа: какие срезы разрешены заранее, как считаем (например, ITT), как работаем с missing/логированием, как проверяем SRM и базовые инварианты.
- Критерии остановки: когда можно/нельзя смотреть на результаты, что считаем достаточным для решения, что делаем при технических сбоях.
- Риски и зависимости: изменения в трекинге, параллельные запуски, сезонность, миграции, всё, что может сломать интерпретацию.
В правильной практике RFC подписывает команду на дисциплину: не “как посчитаем”, а “как договорились считать”. Спорят обычно не про форму документа, а про то, кто готов жить по зафиксированным правилам, когда результат неудобный. Исключение простое: если это не A/B, а быстрый UX-черновик без решения “катим/не катим”, не притворяйтесь экспериментом — назовите это проверкой идеи и не требуйте от неё доказательности.
