Вопросы по теме «Дизайн эксперимента и рандомизация»
Выбор единицы рандомизации (user_id, session_id, device_id), устойчивый bucketing, split-трафик — ошибки на этапе дизайна эксперимента невозможно исправить при анализе. На собеседовании просят объяснить, почему нельзя рандомизировать по сессии, если метрика считается на уровне пользователя. Эти вопросы отделяют тех, кто «запускал тесты», от тех, кто понимает, как они работают.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1Почему назначение варианта как `variant = random.choice([0, 1])` при каждом запросе пользователя — плохая идея для A/B теста?
AПользователь будет часто видеть оба варианта, и эффект смешается из-за постоянной смены варианта
BЭто гарантированно создаст `SRM` (Sample Ratio Mismatch), потому что `random` не умеет 50/50
CЭто повышает мощность теста, потому что дает больше наблюдений
DЭто делает эксперимент корректнее, потому что каждый запрос независим
Ответ: Назначение должно быть стабильным для одного `user_id`, иначе внутри одного юнита возникает смена варианта.
Если вариант меняется при каждом запросе, один и тот же пользователь получает смешанный опыт. Тогда вы измеряете не эффект варианта, а усреднение двух вариантов внутри пользователя, что обычно ведет к сильному размыванию. Такая схема также усложняет отладку и интерпретацию метрик по времени. Правильнее использовать детерминированный `bucketing` (разбивка пользователей на группы) по `user_id` или по другой устойчивой сущности.
2Вы тестируете новый экран оплаты. Пользователь может заходить в приложение много раз. Метрика — конверсия в покупку за 7 дней на уровне `user_id`. Какую `unit of randomization` (единица рандомизации) выбрать, чтобы минимизировать смешение вариантов?
AРандомизировать по `user_id` и анализировать на `user_id`
BРандомизировать по `session_id`, так будет больше наблюдений
CРандомизировать по `device_id`, чтобы учитывать устройство
DРандомизировать по каждому просмотру страницы, чтобы ускорить тест
Ответ: Единица рандомизации должна быть стабильной для объекта, по которому вы измеряете эффект, иначе один и тот же объект может попасть в обе группы.
Если рандомизировать по `session_id`, один и тот же `user_id` может увидеть оба варианта в разные визиты, и эффект размоется. Это создает contamination и ухудшает интерпретацию конверсии за 7 дней. Рандомизация по `user_id` делает назначение стабильным и согласует `unit of randomization` (единица рандомизации) с метрикой.
3Вы рандомизируете по `device_id`, но метрика — доля пользователей, совершивших покупку за неделю, на уровне аккаунта `user_id` (у части пользователей два устройства). Что корректнее?
AРандомизировать по `user_id` или учетной записи, чтобы один пользователь не получал оба варианта на разных устройствах
BОставить `device_id`, а потом просто суммировать покупки по `user_id`
CРандомизировать по `session_id`, потому что сессия ближе к покупке
DРандомизировать по типу устройства, чтобы распределение было равным
Ответ: Если один `user_id` может иметь несколько `device_id`, рандомизация по устройству ведет к смешению вариантов для одного пользователя.
Пользователь с двумя устройствами может оказаться одновременно в `treat` и `control`, что создает contamination и размывает эффект. Это особенно плохо для метрик, которые считаются на уровне аккаунта за период. В таких задачах корректнее выбирать `unit of randomization` (единица рандомизации) на уровне `user_id` или устойчивой учетной записи.
4Вы делаете `bucketing` (разбивка пользователей на группы) как `hash(user_id + day) % 2`, где `day` — текущая дата. Что самое вероятное следствие для эксперимента?
AОдин и тот же `user_id` будет перескакивать между вариантами по дням, создавая contamination
BГруппы всегда будут идеально 50/50 независимо от трафика
CЭто снижает риск `SRM` (Sample Ratio Mismatch), потому что распределение будет постоянно обновляться
DЭто автоматически компенсирует сезонность по дням недели
Ответ: `bucketing` (разбивка пользователей на группы) должен быть детерминированным и стабильным во времени для одного `user_id`, иначе пользователь увидит разные варианты.
Добавление `day` в ключ делает назначение зависимым от даты, поэтому один и тот же пользователь будет получать разные варианты в разные дни. В результате внутри одного `user_id` происходит смена лечения, и эффект размывается. Кроме того, такая схема усложняет анализ по когортам и повышает риск непредсказуемых перекосов в данных.
5В эксперименте на ранжировании вы используете `bucketing` (разбивка пользователей на группы) по `user_id`, но кэш результатов поиска настроен без учета варианта и иногда отдает пользователю выдачу, посчитанную для другого варианта. Что это за риск?
AТолько снижение скорости системы, на корректность эксперимента это не влияет
BЭто `SRM` (Sample Ratio Mismatch), потому что кэш меняет размеры групп
CПроблема только в `unit of analysis`, кэш на нее не влияет
DЗагрязнение (contamination) и нарушение `SUTVA (Stable Unit Treatment Value Assumption)`, потому что пользователи получают опыт другого варианта через общий кэш
Ответ: Если инфраструктура смешивает ответы разных вариантов, происходит contamination и эксперимент перестает измерять чистый эффект.
Кэш, который не учитывает вариант, делает фактическую экспозицию несовпадающей с назначением по `bucketing` (разбивка пользователей на группы). Тогда часть пользователей из `control` увидит поведение `treat` или наоборот, и различия между группами размоются. Это нарушает предпосылки дизайна и может скрыть реальный эффект или создать ложный. Обычно решают добавлением варианта в ключ кэша и проверкой консистентности назначения и экспозиции.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram