Дизайн эксперимента и рандомизация: вопросы для собеседования (часть 2)
Выбор единицы рандомизации (user_id, session_id, device_id), устойчивый bucketing, split-трафик — ошибки на этапе дизайна эксперимента невозможно исправить при анализе. На собеседовании просят объяснить, почему нельзя рандомизировать по сессии, если метрика считается на уровне пользователя. Эти вопросы отделяют тех, кто «запускал тесты», от тех, кто понимает, как они работают.
Вопросы 6–10 из 20
6Эксперимент рассчитан только на новых пользователей. Критерий «новый пользователь» пересчитывается каждый день из-за особенностей `ETL`, и часть пользователей может внезапно перестать удовлетворять этому критерию в середине эксперимента. Какой риск самый существенный и как его снизить?
AРиска нет: сегментация по «новым пользователям» не влияет на рандомизацию и состав групп при любом способе пересчёта
BЕдинственный риск это уменьшение выборки из-за потерь, смещения оценки не возникает: выпадают пользователи случайно
CСелекция и несопоставимость групп из-за динамической принадлежности к сегменту: фиксируйте принадлежность по `user_id` на момент назначения
DДостаточно увеличить долю тестовой группы для компенсации потерь и анализировать только тех, кто остался в сегменте на конец теста
Ответ: Сегмент, зависящий от времени или данных после старта, может привести к выборочной потере пользователей и несопоставимости групп.
Если пользователь может внезапно перестать удовлетворять критерию, вы фактически меняете состав выборки по ходу эксперимента. Это может происходить неодинаково в тестовой и контрольной группах, особенно если продуктовые изменения влияют на события, из которых строится сегмент. В результате сравнение становится смещённым и плохо интерпретируемым. Надёжный приём — фиксировать принадлежность к сегменту на момент назначения по `user_id` и анализировать по этому фиксированному признаку.
Подробный разбор → 7Эксперимент меняет алгоритм распределения заказов между курьерами. Курьеры обслуживают сразу нескольких пользователей, и решение для одного заказа влияет на время доставки других. Какой подход к рандомизации чаще всего лучше уменьшит взаимное влияние групп?
AРандомизировать по `user_id` по всей стране, чтобы каждый пользователь независимо попал в одну из двух групп эксперимента
BРандомизировать на уровне отдельного заказа, чтобы получить максимум независимых наблюдений и быстрее набрать статистическую мощность
CРандомизировать по кластеру (например, по зоне или смене курьеров), чтобы взаимодействия через общий ресурс не смешивали варианты
DРандомизировать по `session_id` пользователя, чтобы посетители видели одинаковый вариант алгоритма в течение одной сессии заказа
Ответ: При сильной взаимосвязи через общие ресурсы помогает рандомизация на уровне кластера, чтобы взаимодействия оставались внутри кластеров.
Если один курьер одновременно обслуживает тестовую и контрольную группы, изменения в маршрутизации и очередях будут влиять на обе группы. Это приводит к перетеканию эффекта и нарушению предпосылок независимости. Рандомизация по кластеру, связанному с общим ресурсом (зона, смена, склад), уменьшает смешивание вариантов. Цена такого решения — меньшая статистическая мощность, потому что независимых наблюдений становится меньше.
Подробный разбор → 8Ожидаемое разбиение — 50/50. По логам экспозиций видно `N_treat / N_control = 1.30`. Какой вывод и следующий шаг наиболее корректны?
AОбъяснимо статистическим шумом при большой выборке: дисперсия в назначении групп даёт подобные перекосы естественным образом
BПохоже на `SRM` или баг назначения/логирования: проверять `bucketing`, фильтры экспозиции и путь до лог-события
CПерекос в `treat` означает, что `bucketing` корректно отнёс более активных пользователей в тестовую группу для чистоты
DДождаться завершения эксперимента и пересчитать `ratio` на финале: промежуточный перекос обычно исчезает по мере набора
Ответ: Заметный перекос `N_treat / N_control` часто сигнализирует `SRM` (Sample Ratio Mismatch) и требует проверки механики назначения и учета экспозиций.
`SRM` (Sample Ratio Mismatch) означает, что фактическое распределение по группам отличается от ожидаемого сильнее, чем можно объяснить случайностью. Причина может быть в баге `bucketing` (разбивка пользователей на группы), в некорректных фильтрах (например, разные условия попадания в лог экспозиции) или в проблемах идентификации. Правильный шаг — сверить распределение на уровне факта назначения и отдельно на уровне экспозиций, а также проверить `SRM` (Sample Ratio Mismatch) внутри ключевых сегментов. До выяснения причин интерпретировать эффект опасно.
Подробный разбор → 9Из-за взаимного влияния пользователей вы решили рандомизировать по кластеру (например, по магазину), а не по `user_id`. Что обычно происходит с точностью оценки эффекта при том же количестве пользователей?
AТочность растёт, потому что внутри одного кластера меньше шума и наблюдения становятся более однородными
BТочность обычно падает, потому что эффективное число независимых наблюдений ближе к числу кластеров, а внутри кластера есть зависимость
CТочность не меняется, потому что общее число пользователей в эксперименте остаётся тем же самым
DТочность зависит только от выбора хеш-функции для разбиения пользователей на группы и не связана с уровнем рандомизации
Ответ: Кластерная рандомизация уменьшает эффективный размер выборки, потому что наблюдения внутри одного кластера коррелируют между собой.
При рандомизации по кластеру независимых единиц становится меньше, даже если пользователей много. Поведение внутри одного магазина или зоны обычно похоже, поэтому добавление новых пользователей внутри того же кластера даёт меньше новой информации. Это увеличивает дисперсию оценки и требует либо больше кластеров, либо более долгого теста. Кластерная рандомизация часто неизбежна при взаимном влиянии пользователей, но её нужно учитывать в ожиданиях по мощности.
Подробный разбор → 10Назначение групп 50/50 по `user_id` корректно, но в лог экспозиции попадает только событие `page_render`. В тестовой группе страница грузится медленнее, и часть пользователей уходит до `page_render`, поэтому в логах экспозиции виден перекос соотношения. Какой фикс наиболее правильный?
AИзменить функцию хеширования так, чтобы в тестовую группу попадало меньше пользователей и перекос автоматически выровнялся.
BЛогировать факт назначения отдельно от события `page_render` или задать единый критерий экспозиции, одинаковый для контрольной и тестовой групп.
CИгнорировать перекос соотношения групп, считая, что это побочный признак сильного эффекта тестового варианта на поведение.
DСделать рандомизацию по `session_id`, чтобы событие `page_render` происходило чаще и компенсировало пропуски экспозиций.
Ответ: `SRM` (Sample Ratio Mismatch) часто возникает из-за разных путей логирования между вариантами, поэтому событие учёта экспозиции должно быть согласованным.
Если экспозиция фиксируется только после `page_render`, варианты с более высокой задержкой не попадают в лог. Назначение может быть корректным, но анализ по экспозициям даст перекошенную выборку и потенциально смещённую оценку эффекта. Лучшее решение — разделить события назначения и экспозиции или сделать определение экспозиции одинаковым для контрольной и тестовой групп. После фикса полезно пересчитать `SRM` и убедиться, что перекос исчез.
Подробный разбор →