Если у A/B нет RFC-шаблона, вы тестируете не продукт, а собственные интерпретации

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

Почему это ломается: без единого документа у каждого в голове свой эксперимент. Гипотеза одна, метрики разные, дизайн “по ходу”, анализ задним числом, критерий остановки заменяется на “когда станет красиво”. А дальше включается p-hacking, конфликт интересов и вечные споры о том, что вообще тестировали.

Минимальный стандарт, который реально повышает качество, — RFC на один эксперимент. Он должен отвечать на 7 вопросов и закрывать возможность самообмана:

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

  2. Метрики и guardrails: одна primary, несколько вторичных, плюс метрики безопасности. Если guardrails заранее не определены, “успех” можно нарисовать всегда.

  3. Дизайн: единица рандомизации, варианты, целевая аудитория, исключения, длительность и что считается экспозицией. Особенно важно: где будут “невидимые” пользователи и пересечения с другими тестами.

  4. Расчёт мощности: минимальный эффект, который имеет смысл для бизнеса, и что вы можете детектировать при текущем трафике. Если не сходитесь — это не повод “всё равно запустить”, это повод менять дизайн или ожидания.

  5. План анализа: как считаете метрики, какие срезы разрешены заранее, как обрабатываете выбросы, возвраты, повторные визиты. Любая “идея посмотреть ещё” после старта — отдельный эксперимент.

  6. Критерии остановки: когда останавливаем по времени, по качеству данных, по рискам. И отдельная строка: что считается неуспехом, чтобы не было бесконечной “докрутки”.

  7. Риски и зависимости: трекинг, релизы, сезонность, параллельные изменения, команды-владельцы. Всё, что может сделать результат неинтерпретируемым.

В правильной практике RFC пишется до старта и утверждается теми, кто потом будет жить с решением: продукт, аналитика, инженерия, иногда финансы. Обычно спорят не про формулы, а про одно: что именно считаем успехом и что готовы “не заметить”, если primary растёт.

Граница применимости простая: для быстрых UX-проверок без метрик можно обойтись без A/B, но как только вы хотите принимать продуктовые решения по цифрам — без RFC вы уже в серой зоне, даже если графики выглядят убедительно.