Как формируются группы в A/B тестах

Что проверяют

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

Как отвечать

Каркас такой:

• единица рандомизации: пользователь, сессия, устройство, город, продавец. Выбирается так, чтобы один объект не попал в обе группы и чтобы она совпадала с единицей анализа метрики;
• механизм: детерминированный хеш от user_id и соли эксперимента, например hash(salt + user_id) mod 100. Пользователь стабильно видит один вариант, а разные эксперименты не коррелируют между собой;
• размер выборки: считается до старта по MDE, базовому значению и дисперсии метрики, уровню значимости (обычно 0,05) и мощности (обычно 0,8). Отсюда же длительность теста, минимум полный недельный цикл;
• снижение дисперсии: CUPED с данными предпериода или стратификация по важным признакам, это позволяет обойтись меньшей выборкой;
• проверки: A/A-тест для валидации системы сплитования и SRM-проверка хи-квадратом: если заложили 50/50, а получили заметный перекос, данным верить нельзя;
• сетевые эффекты: в маркетплейсах, такси, соцсетях группы влияют друг на друга, тогда рандомизируют кластерами (город, регион) или используют switchback по времени.

Где спотыкаются

Делят по признаку вместо случайного распределения: новые против старых, Android против iOS, первая неделя против второй. Это уже не эксперимент, и эффект изменения смешивается с различием самих групп.

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

Подглядывают в результаты и останавливают тест при первом p-value ниже 0,05. Без поправки на многократные проверки это резко завышает долю ложных срабатываний. Если смотреть по ходу нужно, используют последовательное тестирование.