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

Коротко

Доверие к тесту складывается из трёх вещей: группы получили эксперимент случайно, данные собираются одинаково, а правило остановки было задано заранее. Если хотя бы одно из этих условий нарушено, p-value и uplift создают видимость точности, но не спасают дизайн.

• Проверь SRM: фактическое распределение пользователей между группами должно соответствовать плану.
• Не останавливай тест в тот день, когда случайно появился красивый результат.
• Зафиксируй primary metric, guardrails и срок до старта эксперимента.
• После запуска проверь трекинг и полноту событий до чтения результата.

SRM: группы распределились не так, как планировали

Sample Ratio Mismatch — это ситуация, когда в группах оказалось существенно не то соотношение пользователей, которое задавали в эксперименте. При плане 50/50 ожидаем примерно одинаковое число назначений. Если в control попало 58%, а в test 42%, сначала расследуем рандомизацию, фильтры и доставку варианта, а не обсуждаем uplift.

SRM не доказывает, что результат неправильный, но показывает: механизм эксперимента мог повлиять на то, кто вообще попал в каждую группу. Причина часто находится в SDK, кэше, авторизации, исключении старых пользователей или фильтре уже после назначения варианта.

Подглядывание меняет правило игры

Если каждый день смотреть на p-value и останавливать тест при первом значении ниже 0,05, вероятность случайно объявить победителя становится выше заявленных 5%. Это не значит, что нельзя открывать дашборд вообще. Нельзя менять правило решения после того, как увидели промежуточный результат.

Безопасная практика: заранее записать минимальный срок или размер выборки, частоту проверок, primary metric и условие остановки. Если нужен последовательный дизайн, используй его осознанно и с подходящим методом, а не называй обычный тест последовательным задним числом.

Множественные проверки и незапланированные срезы

Тест можно “найти” почти в любом результате, если одновременно проверять десять метрик, пять сегментов и несколько периодов. Один случайный p-value ниже 0,05 среди большого набора проверок не выглядит таким же убедительным, как заранее выбранная основная метрика.

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

• Назови primary metric до запуска и не меняй её на вторую по ходу теста.
• Список guardrail-метрик держи коротким: только реальные риски релиза.
• Сегментные находки помечай как exploratory, если они не были запланированы.
• Для нескольких сравнений используй поправку или отдельный дизайн, а не обычный порог механически.

Проверка событий важнее красивого дашборда

До чтения результата сравни размер аудитории эксперимента с числом пользователей в основной метрике. Если вариант видит 20 тысяч пользователей, а покупка считается только у 11 тысяч из них, нужно понять, это ожидаемый знаменатель или потеря события. Отдельно проверь дубли, задержку загрузки и одинаковую доступность целевого действия в обеих группах.

Полезно иметь диагностический график до primary metric: назначения по дням, доля пользователей с событием, доля неизвестных вариантов, ошибки и время от exposure до целевого действия. Он не заменяет анализ, но быстро показывает, где искать поломку.

Чеклист аналитика

Перед финальным выводом пройди список сверху вниз. Если на каком-то шаге нет ответа, честнее отложить решение и починить эксперимент, чем превращать статистический отчёт в аргумент за уже принятое решение.

• Группы назначаются случайно и сохраняются за пользователем?
• SRM проверен на общей аудитории и ключевых технических срезах?
• Тест прожил заранее заданный срок или достиг плановой выборки?
• Primary metric и guardrails были определены до запуска?
• Данные одинаково полно собираются в обеих группах?
• Сегментные находки отделены от подтверждающего результата?