Сообщить об ошибкеКороткий ответ
SRM почти всегда указывает на техническую проблему в рандомизации, логировании или фильтрации данных, а не на продуктовый эффект, поэтому до анализа метрик нужно системно проверить пайплайн назначения групп и сбора событий.
Как это работает подробнее
SRM проверяется chi-square тестом на соответствие фактических частот групп ожидаемому сплиту; большое отклонение при большой выборке почти наверняка статистически значимо и требует расследования, а не игнорирования.
Пример кода
example.sql
SELECT event_date, group_name, COUNT(DISTINCT user_id)
FROM ab_assignments
GROUP BY event_date, group_name
ORDER BY event_date;Что использовать на практике
- типичные причины: редиректы или различия в производительности/загрузке страницы между вариантами (из-за чего часть пользователей 'теряется' из воронки логирования до назначения группы), фильтры ботов, работающие по-разному для вариантов, кэширование на CDN, присваивающее стабильно одну версию части трафика, или баг в самом коде сплитования (несимметричный хэш/соль).
- Шаги расследования: 1) сравнить распределение групп по платформам/странам/времени — если расхождение сосредоточено в одном сегменте (например, только iOS), это сужает причину до клиентской логики; 2) проверить логи на дубли/потери событий назначения группы; 3) посчитать SRM отдельно по дням — если отклонение появилось в конкретный день, искать деплой или инцидент в этот день.
Подводные камни
- попытка 'объяснить' SRM продуктовой причиной ('наверное, пользователям из B не понравилось и они ушли') вместо проверки логов трекинга; также ошибка — продолжать анализировать метрики теста, не устранив SRM, так как любые выводы будут смещены.