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