Если в RFC A/B нет этих полей — вы не делаете эксперимент, вы готовите спор на ретро.

Сценарий знакомый: запустили тест, через неделю в чате “победили”, через две — “метрика не та”, через месяц — “а сегмент не учли”, а потом выясняется, что трекинг падал и трафик перекосило. Цена — решения на эмоциях, потерянное время команды и вечная недоверчивость к аналитике.

Почему так происходит? Потому что A/B ломается не на статистике, а на договорённостях. Без заранее зафиксированных правил люди честно “оптимизируют” под свой интерес: выбирают удобную метрику, игнорируют guardrails, меняют окно наблюдения, находят “правильный” срез и называют это выводом.

Минимальный стандарт RFC, чтобы не спорить постфактум:

  1. Гипотеза и ожидаемое направление эффекта. Не “улучшим опыт”, а что именно меняем в продукте и какая метрика должна двинуться. Если метрика не двинулась, это тоже результат.

  2. Primary и guardrail метрики. Primary — единственная, по которой принимается решение. Guardrails — те, которые нельзя ухудшать, даже если primary растёт. Без этого вы просто не видите цену “успеха”.

  3. Единица рандомизации и экспозиция. Кто рандомизируется: пользователь, устройство, сессия, аккаунт. Когда считается “попал в тест”. Любая путаница тут превращает эффект в шум, а иногда и в иллюзию.

  4. Критерии остановки и правила анализа. Когда можно смотреть, когда можно останавливать, что считается “неуспехом”. И отдельно: что делаем при конфликте primary vs guardrails — это главный источник драм.

  5. План сегментов и ограничения. Какие срезы смотрим заранее (и зачем), какие запрещены, какие считаем чисто диагностикой. Иначе сегменты становятся фабрикой случайных “инсайтов”.

  6. Риски трекинга и проверки качества. Какие события критичны, где возможны пропуски, что проверяем в первые дни: SRM, перекосы трафика, различия в экспозиции, дубликаты, изменения в воронке логирования. Без этого тест может быть “значимым” только потому, что данные сломались.

Правильная практика выглядит скучно: RFC читается как контракт, а не как презентация. Тогда обсуждения идут до запуска, а после — вы просто исполняете заранее согласованные правила. Исключение одно: быстрые защитные эксперименты (например, аварийные откаты) — там вы честно снижаете амбиции выводов и фиксируете это в том же RFC.