Пример из учебного эксперимента
На вымышленном маркетплейсе Meridian значок «быстрая доставка» тестировали с планом 50/50. В данных — 5978 участников в контроле и 5663 со значком. Дашборд объявил значок победителем, но проверка соотношения даёт p ≈ 0,004. Нажмите «Пример из Meridian», чтобы увидеть расчёт. Прежде чем рекомендовать изменение, нужно понять, почему в данных второй группы меньше участников.
Что проверить при предупреждении
- Редиректы и скорость страницы: не теряет ли один вариант участников до записи события?
- Боты и внутренний трафик: не учтены ли сотрудники или роботы только в одной группе?
- Назначение группы: не распределяются ли вернувшиеся пользователи заново, не сбрасывается ли cookie?
- Фильтры после назначения: одинаково ли правила применяются к обеим группам?
- Сбор данных: не пропускаются ли события одной группы, в одинаковый ли момент они записываются?
План выборки и срок эксперимента разобраны в гайде «Сколько должен идти A/B-тест». Работа с предупреждением SRM — часть симулятора Meridian.
Попробовать работу аналитика
В бесплатном кейсе 1 промокод сопровождается корзинами в 2,5 раза больше. SQL уже написан: вам решать, что сравнение позволяет рекомендовать. Около 17 минут, без аккаунта.
Частые вопросы
Что такое sample ratio mismatch?
SRM — это статистически необычное соотношение размеров групп при запланированном распределении. Например, 51/49 вместо 50/50 на 20 000 участников даёт p ≈ 0,005, а 52/48 на 2000 ещё может объясняться случайностью. Это повод проверить распределение и сбор данных, а не готовый диагноз.
Как проверяется SRM?
Критерий согласия хи-квадрат сравнивает фактические размеры групп с ожидаемыми по плану. Малый p-value означает, что при заданной модели распределения столь сильное или более сильное расхождение было бы необычным. Порог выбирают до теста. Здесь предупреждение появляется при p < 0,01; команды, которые следят за множеством тестов, могут выбрать более строгий порог, например 0,001.
Что может вызвать расхождение?
Например, редирект или медленная страница теряет участников одной группы до записи события; бот попадает только в один вариант; вернувшийся пользователь распределяется заново; фильтр применяется после распределения; из одной группы теряются события. SRM сам по себе не различает эти причины.
Можно ли делать вывод по результату A/B-теста при SRM?
Сначала разберитесь с предупреждением. Если распределение или сбор данных смещены, значимая разница в метрике может вводить в заблуждение. Зафиксируйте, что показали проверки и подходят ли данные для нужного сравнения. Одно предупреждение SRM ещё не доказывает ошибку.
Это бесплатно? Куда уходят данные?
Бесплатно и без аккаунта. Расчёт выполняется в браузере; введённые размеры групп никуда не отправляются. Пример взят из вымышленного учебного маркетплейса Meridian.