5 реальных причин SRM с которыми я сталкивался на практике

Если не знаете что такое SRM,то читайте эти статьи

https://t.me/y_borzilo/398
https://t.me/y_borzilo/541
https://t.me/y_borzilo/546

А теперь перейдем к практическому опыту

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

Т.е. по части пользователей не будет никаких данных в логах и из-за этого мы будем видеть, что в одной группе значимо больше пользователей, чем в другой.

2. SRM из-за ошибок в отчетности
Я делал отчет для контроля АБ тестов и тестировал его на "стерильных АБ тестах", где была очень маленькая доля пользователей < 0.001% которые попадали в 2 варианта АБ теста и это никак не аффектило на SRM.

Но потом оказалось, что есть небольшая доля АБ тестов, в которых 0,5% пользователей попадает в несколько вариантов АБ теста и в таких АБ тестах мы выявляли SRM.

Оказалось, что когда я писал скрипт для отчета, то сделал так что всем пользователям, которые попадали в несколько вариантов в скрипте по итогу присваивался контроль.

Почти на всех АБ тестах доля тех кто попадал в 2 варианта эксперимента была очень маленькая и там это ни на что не влияло, а там где было около 0,5% пользователей попадающих в 2 варианта, такой расчет вызывал SRM

3. SRM из-за кук предыдущих экспериментов
В одной из платформ АБ тестов с которой я работал мы постоянно ловили дисбаланс выборок. В контроль всегда попадало больше пользователей чем в тест.

Оказалось, что платформа работает следующим образом: например был запущен АБ тест, его завершили, потом запустили новый АБ тест и если пользователь из контрольной группы старого АБ теста возвращался и попадал в новый эксперимент, то его относили к контрольной группе.

Т.е. он не проходил по новой процесс определения варианта в рамках нового АБ теста. Отсюда возникал дисбаланс и контрольная группа всегда получалась больше чем тестовая.

4. SRM из-за редиректов
Этот вариант перекликается с 1 вариантом. Существую схемы организации экспериментов когда пользователь приходит на страницу с экспериментом, сплитование происходит на стороне браузера после определения варианта к которому будет отнесен пользователь если выпал контроль, то продолжают загрузку текущей страницы, а если выпал тест, то пользователя с текущей страницы перенаправляют на другой url адрес.

Как правило редирект занимает какое-то время и тестовая страница грузится дольше чем контрольная и у части пользователей тестового варианта страница не успевает прогрузиться и не успевает улететь событие веб-аналитики в систему трекинга

5. SRM из-за сэмплирования
Системы веб-аналитики, да и некоторые СУБД имеют алгоритм сэмплирования. Это когда берется только часть данных и по ним оценивается реальное число.

Например, у вас по 50000 пользователей в каждом варианте, но включено сэмплирование и система берет 1000 из одного варианта, 800 из другого, по своим алгоритмам определяет "истинное" число.

Потом система вам говорит, что в одном варианте 50000 пользователей, а в другом 48000 пользователей. Вы получаете дисбаланс там где его нет, просто в силу того что в системе работает сэмплирование.

Напоследок напомню, что через 5 дней стартует марафон АБ тестов, где мы тоже будем учиться работать с SRM и другим особенностям АБ