Проверка SRM: как понять, что сплит A/B-теста перекосило

Коротко

SRM — sample ratio mismatch, расхождение фактического сплита с плановым. Проверяется критерием согласия χ² по числу пользователей в группах.

• Проверять надо до расчёта метрик, а не после подозрительного результата.
• Порог тревоги — 0,0005, а не привычные 0,05.
• Перекос почти никогда не бывает случайным: это редирект, кеш, фильтр или счётчик.
• «Признаков перекоса нет» не означает «сплит правильный».
• Неравный сплит по плану — не поломка: 90 на 10 при 9 000 и 1 000 даёт χ² ровно ноль.

Почему это первая проверка, а не последняя

Рандомизация — единственное, что позволяет приписать разницу вашему изменению. Если в одну группу систематически попало больше или меньше людей, чем должно, значит, в распределение вмешалось что-то ещё. И это «что-то» почти наверняка связано с поведением: медленные соединения, определённый браузер, пользователи с включённым блокировщиком.

Тогда группы отличаются не только тем, что вы меняли, и любое p-value ниже по течению измеряет смесь эффекта и утечки. Причём чаще всего утечка больше эффекта — именно поэтому «внезапно значимый» результат стоит проверять на SRM в первую очередь.

Как считается

Берётся фактическое число пользователей в каждой группе и ожидаемое по плану сплита. Критерий согласия χ² складывает квадраты отклонений, поделённые на ожидаемое, и переводит сумму в p-value. Смысл p-value тот же, что и везде: как часто такое или большее расхождение возникало бы при исправной рандомизации.

Проверка работает с любым числом вариантов и любым плановым сплитом. План задаётся долями в любых единицах — 50 и 50 то же самое, что 1 и 1.

Ограничение одно: в каждой группе должно ожидаться не меньше пяти пользователей. На меньших числах приближение χ² перестаёт работать, и точная на вид цифра будет ложной.

Почему порог 0,0005, а не 0,05

Это главное отличие SRM от остальных проверок, и его чаще всего упускают. Обычный порог 0,05 означает одну ложную тревогу на двадцать проверок. Но SRM смотрят у каждого теста, часто по несколько раз за его жизнь — значит, при таком пороге каждый двадцатый совершенно здоровый тест объявлялся бы сломанным.

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

Расплаты за строгость почти нет: настоящий перекос обычно даёт p на порядки меньше даже такого порога. Смотрите таблицу — 10 000 против 10 400 даёт p = 0,0051 и тревоги не поднимает, а 50 000 против 48 000 уходит ниже 0,00001.

Где обычно ломается

Редирект. Вариант реализован отдельной страницей, часть пользователей до неё не доезжает — и это не случайные пользователи, а те, у кого хуже связь.

Кеш и CDN. Один из вариантов отдаётся из кеша чаще, и события с него теряются или дублируются.

Фильтры в отчёте. Ботов, внутренний трафик или тестовые аккаунты отфильтровали после распределения, и фильтр сработал по группам неравномерно.

Точка замера. Пользователя записали в группу на бэкенде, а событие отправляется с фронтенда: все, у кого не выполнился скрипт, выпали из одной группы сильнее, чем из другой.

Поздняя активация. Вариант подключается не сразу, и часть пользователей уходит до того, как попала в замер.

Как искать причину

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

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

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

Шаг третий: проверить SRM в разрезах — по устройству, браузеру, стране, версии приложения. Перекос, который виден только на одном срезе, почти всегда называет виновника прямо: сломанная вёрстка на старом Safari, блокировщик, отвалившийся CDN в одном регионе.

Шаг четвёртый: посмотреть на перекос во времени. Ровный до вторника и разъехавшийся после — это релиз или изменение конфигурации, и дату можно назвать точно.

Частые вопросы

Насколько большим должно быть расхождение, чтобы забеспокоиться? Не в процентах дело, а в объёме. При тысяче пользователей в группе разница в 4% — обычное дело; при пятидесяти тысячах те же 4% практически невозможны случайно. Поэтому и нужен критерий, а не правило вида «до 5% нормально».

Можно ли просто перезапустить тест? Можно, но если причина не найдена, она повторится. Перезапуск без разбора — это способ получить тот же перекос через две недели.

Что делать, если перекос обнаружился на уже принятом решении? Пересчитать нельзя, данные испорчены. Практичный выход — раскатить изменение на небольшую долю и наблюдать за guardrail-метриками, а не задним числом искать оправдание прошлому выводу.

Нужно ли проверять SRM, если сплит делает готовая платформа? Да. Платформа отвечает за распределение, но не за то, что произойдёт с пользователем дальше: редиректы, кеш, фильтры в отчёте и точка замера остаются на вашей стороне.

Считать SRM по пользователям или по сессиям? По той единице, по которой шло распределение. Если распределяли пользователей, а считать сессии, то активные пользователи дадут перекос сами по себе, безо всякой поломки.

Когда перекос не поломка

Не всякое расхождение с планом — авария. Неравный сплит, заданный намеренно, критерий принимает спокойно: 90 на 10 при девяти тысячах и тысяче пользователей даёт χ² ровно ноль, потому что факт совпадает с ожиданием. Проверка сравнивает не группы между собой, а факт с тем, что вы заказывали.

Постепенная раскатка тоже не перекос сама по себе. Если вариант включали 10% в первый день, 50% во второй и 100% в третий, то суммарный сплит будет неровным по замыслу — и считать SRM нужно либо по каждому периоду отдельно, либо с ожиданием, учитывающим план раскатки.

Малое расхождение на малом трафике не значит ничего. При тысяче пользователей в группе отклонение в четыре процента возникает случайно постоянно; при пятидесяти тысячах то же самое отклонение практически невозможно. Именно поэтому здесь считают критерий, а не сравнивают проценты с фиксированным допуском.

И обратная сторона: критерий проверяет только количество пользователей. Ровный сплит по числу людей не гарантирует, что группы одинаковы по составу — доля новых, распределение по устройствам и странам могут разъехаться и при исправной рандомизации. Это отдельная проверка, которую полезно делать по ключевым разрезам до старта.

Что делать при перекосе

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

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

Результаты теста до выяснения причины не считать. Это неприятно, но дешевле, чем принять решение по смеси эффекта и утечки.

И помните обратное: отсутствие тревоги не доказывает, что сплит правильный. Слабый перекос на малом трафике критерий не заметит — это осознанный размен на редкость ложных тревог.