Планировали разделить клиентов поровну, а в отчёте получили 59% в тесте и 41% в контроле. Иногда это обычная случайность, иногда — потеря событий или ошибка настройки. Пока причина неизвестна, красивый рост конверсии нельзя считать надёжным результатом.

SRM, sample ratio mismatch, — статистически необычное расхождение между запланированными долями групп и наблюдаемым распределением участников. Проверка SRM отвечает на вопрос о качестве распределения и данных. Она не проверяет, выросли ли продажи.

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

Считайте участников, которым назначили вариант

Для CRM единицей распределения часто является клиент. Сначала проверьте уникальные ID в журнале назначения: один участник, одна группа, понятный момент входа. Число отправок не подходит, если один клиент получает несколько сообщений.

Разная доля открывших письмо сама по себе не является SRM. Открытие может зависеть от тестируемой темы, доставки и особенностей измерения. Если сравнивать только открывших, получится отбор по событию после воздействия.

Полезно сопоставить несколько уровней: назначение, попытка отправки, доставка, наличие записи в аналитике. Ожидаемая доля 50/50 обязана сохраняться не на каждом из них: новая политика может специально уменьшать число отправок. Отклонение на позднем этапе сначала интерпретируют с учётом механики.

Учитывайте размер базы и дизайн

Условный пример. Из 10 тысяч клиентов при распределении 50/50 наблюдаем 5 900 и 4 100. Ожидание — по 5 тысяч. Статистика критерия хи-квадрат равна сумме двух слагаемых: квадрат отклонения 900, делённый на 5 тысяч. Получается 324. Для одной степени свободы это крайне маловероятное расхождение при исправном независимом распределении 50/50.

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

Если доля контроля менялась с 10% до 20%, нельзя сравнивать общий итог с одной из этих долей. Восстановите ожидание по этапам и слоям, предусмотренным дизайном. При назначении магазинов сначала проверяют магазины: равенство покупателей не обещалось.

Найдите первый этап расхождения

ПроверкаВозможная причинаСледующий шаг
Назначение по дням и источникамОшибка правила, повторное назначениеСверить версию алгоритма и устойчивость ID
Журнал назначения против выгрузкиПотерянная партия или неверный joinНайти ID, отсутствующие на одной стороне
Фильтры анализаУдаление клиентов по событиям после стартаВосстановить исходную аудиторию
Запись заказовОшибка трекинга только в одном вариантеСверить с независимым реестром заказов
Сегменты и устройстваЛокальная ошибка интеграцииПроверить затронутый путь данных

Разрезы помогают локализовать проблему, но не превращаются в соревнование за самый маленький p-value. Начинайте с технически обоснованных подозрений. При регулярном автоматическом мониторинге заранее задайте процедуру сигнализации: многократные проверки тоже создают ложные тревоги.

Почему нельзя просто уравнять группы

Удаление «лишних» клиентов исправляет красивую пропорцию, но не восстанавливает потерянную информацию. Если исчезали преимущественно пользователи со сбоями оплаты, случайная обрезка другой группы не вернёт сопоставимость.

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

Решение исключить технически повреждённый период должно учитывать, не зависело ли повреждение от варианта и поведения клиентов. Простого правила «убрать плохие дни» недостаточно. Действия и их обоснование сохраняют вместе с отчётом.

Когда можно вернуться к оценке эффекта

Нужны установленная причина, проверенный способ исправления и повторная сверка всей аудитории. Восстановленный отчёт должен воспроизводиться из сохранённых данных, а не существовать только в ручной таблице аналитика.

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

Источники

Microsoft Experimentation Platform. Diagnosing Sample Ratio Mismatch in A/B Testing. Microsoft Research. 14 сентября 2020.