Кейс Представим, что мы работаем с приложением крупного ретейлера. Продакт предлагает упростить оформление заказа: вместо пяти шагов оставить три. Наша задача - грамотно спроектировать A/B-тест.

Гипотеза такая: если сократить количество шагов, пользователям будет проще и быстрее оформить заказ, а значит, доля завершённых покупок вырастет.

Роли метрик в эксперименте

1. Метрики успеха Это метрики, по которым мы определяем, победил эксперимент или нет. Именно они лежат в основе решения о выкатке изменения. Такие метрики должны напрямую отражать ожидаемое изменение поведения, быть чувствительными к эффекту, понятными в интерпретации и немногочисленными - обычно достаточно 1–3. Пример: доля завершённых покупок на сессию в течение первых 7 дней.

2. Guardrail-метрики Эти метрики нужны, чтобы убедиться, что эксперимент не нанёс побочного вреда. Мы не ждём, что они улучшатся. Главное — проверить, что они не стали заметно хуже. Для них обычно используют тесты неухудшения. Примеры: выручка на завершённый заказ, производительность сайта.

3. Deterioration-метрики Эти метрики помогают обнаружить негативные последствия изменения. В отличие от guardrail-метрик, здесь нас интересует именно наличие ухудшения. Их проверяют с помощью тестов на ухудшение. Примеры: доля возвратов, число обращений в поддержку.

4. Quality-метрики Quality-метрики отвечают за корректность самого эксперимента. Они показывают, правильно ли сработала рандомизация, корректно ли пользователи попали в эксперимент, не было ли технических сбоев или ошибок экспозиции. Их стоит проверять до анализа бизнес-результатов.

5. Исследовательские метрики Эти метрики помогают разобраться, почему эксперимент дал именно такой результат. Их можно добавлять уже на этапе анализа. Они не влияют на расчёт размера выборки и не используются напрямую для решения о выкатке. Их результаты скорее формируют гипотезы для следующих экспериментов.

Поправки на множественное тестирование Когда решение принимается сразу по нескольким метрикам, появляется проблема множественного тестирования. Важный момент: поправки зависят не просто от числа метрик, а от того, как устроено правило принятия решения - decision rule. Есть два базовых типа составных гипотез.

UI-тестирование, или логика «хотя бы одна» В этом случае мы отвергаем H₀, если отвергнута хотя бы одна из подгипотез. Такая логика увеличивает риск ложноположительного вывода, поэтому нужна поправка на α. Например, можно использовать поправку Бонферрони: α/M.

IU-тестирование, или логика «все или ничего» Здесь мы отвергаем H₀ только тогда, когда отвергнуты все подгипотезы. В этом случае основной риск - потеря мощности. Поэтому нужна поправка на β: β/M для каждого отдельного теста.

Простое правило принятия решения Выкатываем изменение, если одновременно выполняются два условия: 1. Хотя бы одна метрика успеха статистически значимо улучшилась. 2. Все guardrail-метрики статистически значимо не хуже заданного порога.

Это IU-тест из G+1 гипотез.

Корректные поправки в таком случае: для каждой guardrail-метрики: уровень значимости α, мощность 1 − β/(G+1); для каждой метрики успеха: уровень значимости α/S, мощность 1 − β/(G+1).

Например, если у нас есть 5 guardrail-метрик и каждая из них имеет мощность 80%, то совместная мощность будет всего около 33%.

Без такой поправки эксперимент может потерять способность находить реальные эффекты.

Вывод

Применять поправки механически, без учёта структуры decision rule, — ошибка. Такой подход может привести к завышенным требованиям к размеру выборки, снижению мощности эксперимента и отказу от изменений, которые на самом деле могли бы быть полезными.