В A/B-тесте группы разного размера: проверка SRM
Как проверить SRM перед сравнением конверсий: расчёт для двух групп, воспроизводимый Python-пример и диагностика назначения, экспозиции и отчёта.
В эксперименте запланировано распределение 50/50, а в отчёте получилось 52/48. Это ещё не диагноз. При тысяче участников такое отклонение может возникнуть случайно; при десяти тысячах та же пропорция уже выглядит иначе. Перед сравнением конверсии нужно проверить, соответствует ли фактическое распределение правилу назначения.
Эта проверка называется Sample Ratio Mismatch, или SRM. Она отвечает на вопрос о составе групп, а не о том, какой вариант продаёт лучше. В отличие от расчёта необходимой выборки из общего разбора A/B-тестирования, здесь проверяют уже собранные данные.
Сначала договоритесь, кого считать
Возьмите единицу рандомизации: пользователя, аккаунт или другую независимо назначаемую сущность. Если тест распределяет аккаунты, сравнение количества сессий неверно: активность аккаунтов может различаться. Один пользователь с десятью визитами не должен превращаться в десять независимых участников.
Разделите два журнала: назначение варианта и фактическую экспозицию. Первый помогает проверить работу распределения. Второй показывает, кто встретился с изменением. Если считать только увидевших кнопку, которую вариант сам переместил, можно получить отбор, вызванный тестом.
В документации Amplitude выбор события экспозиции и настройки эксперимента рассматриваются как часть определения анализируемой аудитории. Поэтому в выгрузке сохраните правило попадания, событие, идентификатор и период. Названия настроек конкретной платформы не заменяют это описание.
Мини-калькулятор для двух групп
Следующий расчёт подходит для независимых единиц, фиксированных вероятностей назначения и достаточно больших ожидаемых численностей. Для двух групп используется критерий хи-квадрат с одной степенью свободы. Ожидаемое число в группе равно общему числу участников, умноженному на заданную долю.
| Наблюдения A / B | Ожидается A / B | Хи-квадрат | p-value |
|---|---|---|---|
| 520 / 480 | 500 / 500 | 1,6 | около 0,206 |
| 5 200 / 4 800 | 5 000 / 5 000 | 16 | около 0,000063 |
Формула: сумма квадратов отклонений от ожидаемого числа, делённых на ожидаемое число. Для второй строки: 200² / 5 000 + 200² / 5 000 = 16. Доля 52/48 одинакова, но размер выборки меняет силу свидетельства против заданного распределения.
Этот короткий Python-пример воспроизводит вторую строку. Он рассчитан ровно на две группы; вероятности задаются до просмотра результата. Проверка ожидаемого количества нужна для применимости приближения.
import math
observed = [5200, 4800]
probabilities = [0.5, 0.5]
total = sum(observed)
expected = [total * p for p in probabilities]
assert min(expected) >= 5
chi2 = sum((o - e) ** 2 / e for o, e in zip(observed, expected))
p_value = math.erfc(math.sqrt(chi2 / 2))
print(chi2, p_value)Microsoft Research описывает SRM как сигнал возможных ошибок назначения, исполнения и анализа. Приведённый там рабочий порог Microsoft — не универсальное правило для любой команды. Порог тревоги и порядок реакции нужно установить заранее. Малое p-value не указывает причину ошибки и не является вероятностью того, что эксперимент сломан.
Дерево проверки после сигнала
- Перекос уже в назначениях. Проверьте фактические веса вариантов, единицу распределения, стабильность ID и историю изменения конфигурации. Если доли менялись, нельзя считать весь период как неизменные 50/50.
- Назначения сходятся, экспозиции расходятся. Ищите различия загрузки, ошибок скрипта, условий показа и регистрации события. Сопоставьте устройства и версии приложения.
- Оба журнала сходятся, итоговый отчёт расходится. Проверьте фильтры, объединение таблиц, исключение ботов и обработку пустых ID. Потеря строки при соединении тоже меняет группы.
- Сигнал виден только в сегменте. Сначала уточните, был ли сегмент определён до воздействия. Сегментация по действию, которое меняет вариант, сама способна создавать дисбаланс.
Не перебирайте десятки срезов, пока случайно не найдётся значимый. Начните с диагностических признаков, связанных с предполагаемой причиной, и сохраняйте проверенные гипотезы. Отсутствие SRM во всей выборке не гарантирует исправность каждого сегмента.
Что делать с результатом конверсии
Пока существенный перекос не объяснён, обозначьте сравнение конверсий как ненадёжное для решения о победителе. Не выравнивайте группы случайным удалением лишних пользователей: это прячет симптом, но не восстанавливает потерянные наблюдения.
Если причина в конфигурации лендинга, сохраните её версию и проверяемые настройки по схеме передачи окружения. При пользовательской поломке действуйте по заранее подготовленному плану отката. Затем определите пригодный период данных или перезапустите эксперимент с исправленным сбором.
Для адаптивного распределения, кластерных зависимостей и малых ожидаемых численностей этот калькулятор не подходит без изменения метода. Начните проверку с четырёх полей: единица, ожидаемая доля, фактическое число и источник журнала. Они полезнее, чем спор о допустимой разнице в процентах.