Почему я больше не верю в A/B «до метрики» и как мы возвращаем культуру экспериментов в 2026

Почему я больше не верю в A/B «до метрики» и как мы возвращаем культуру экспериментов в 2026

В 2026 я всё чаще вижу один и тот же антипаттерн: команда запускает A/B-тест «на цель», но на самом деле проверяет не продуктовое решение, а устойчивость аналитического рельса. В результате эксперимент выглядит аккуратно (есть p-value, есть конверсия), а бизнес-решения принимаются вслепую.

Моя позиция простая: A/B нельзя начинать с выбора целевой метрики. Нельзя “сверху вниз” назначить конверсию в качестве истины и надеяться, что тест ответит на вопрос. Почти всегда это маскирует главную проблему — неверную цепочку причинности между изменением и наблюдаемым поведением.

Как мы делаем по-другому (и почему это возвращает культуру экспериментов)

1) Сначала — гипотеза в терминах процесса, а не KPI
Я формулирую гипотезу как изменение в механизме: что именно стало быстрее/понятнее/надёжнее для пользователя и на каком шаге это должно отразиться. KPI — лишь следствие. Пример из практики: редизайн формы заявки. В “старой” логике тестируют конверсию в лид. В “правильной” — сначала проверяют измеримость шагов: доля просмотров полей, ошибки валидации, успешность отправки, время до отправки. Конверсия в лид — конечная точка, а не единственный судья.

2) Затем — “метрика разложения” (metric decomposition)
Вместо одного числа мы строим мини-воронку и тестируем, где появилось улучшение/ухудшение. Это дисциплинирует: если итоговая конверсия не растёт, но падает ошибка валидации и растёт успешная отправка, мы понимаем, что узкое место сместилось дальше по цепочке. В 2026 это особенно важно из‑за privacy-first атрибуции и разъезда трактовок в аналитике: одна агрегированная метрика может лгать из‑за того, как моделируются события.

3) И только потом — дизайн статистики
Когда цепочка причинности ясна, можно честно обсуждать длительность эксперимента, степень рандомизации, критерии остановки и правила “переезда” победителя. Иначе p-value превращается в декорацию.

Одна цифра из того, как это ловит ошибки
В одном из недавних тестов команда “сверху” выбрала метрику: доля заявок. Через разложение оказалось, что успешность отправки выросла, но доля прохождений антифрода — тоже выросла и съела эффект на следующем шаге. Итоговая конверсия была примерно ровной, и тест решили считать нейтральным. По факту продукт улучшил UX формы, а бизнес-процесс (скоринг/маршрутизация) компенсировал изменение. Если бы мы измеряли только “доходящую” метрику, решение было бы неправильным: победителя можно было бы не масштабировать, хотя он устранял реальную проблему.

Почему это особенно актуально в эпоху RevOps
Когда ответственность за выручку общая (маркетинг + продажи + customer success), “одна метрика” начинает спорить с другой: маркетинг говорит про лиды, продажи — про качество и скорость обработки, customer success — про удержание и повторные сценарии. Разложение метрик позволяет удержать эксперимент в рамках процесса и не превращать A/B в спор отделов.

Мой контрольный принцип:
если я не могу объяснить, через какие 2–4 наблюдаемых шага изменение должно дойти до итоговой метрики, значит эксперимент пока не эксперимент, а просто смена интерфейса под статистический шум.

Хотите — поделюсь шаблоном формулировки гипотезы “процесс → события → финальная метрика” и чек-листом разложения под MQL/SQL и retention.

— @ExperimentationRoom