Вопросы по теме «Дизайн эксперимента и рандомизация»
Проверь себя · 1/3разбор после ответа
Есть два фактора: новый дизайн карточки и новая логика рекомендаций. Команда хочет запустить два эксперимента одновременно на одной аудитории. В каком случае разумно выбрать факторный дизайн 2x2 вместо взаимного исключения аудиторий?
Выбор единицы рандомизации (user_id, session_id, device_id), устойчивый bucketing, split-трафик — ошибки на этапе дизайна эксперимента невозможно исправить при анализе. На собеседовании просят объяснить, почему нельзя рандомизировать по сессии, если метрика считается на уровне пользователя. Эти вопросы отделяют тех, кто «запускал тесты», от тех, кто понимает, как они работают.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
1Почему назначение варианта строкой `variant = random.choice([0, 1])` при каждом запросе пользователя — плохая идея для A/B-теста?
AОдин и тот же пользователь будет часто видеть оба варианта, и эффект варианта смешается с эффектом постоянных переключений интерфейса.
BДоли групп заметно перекосятся: функция `random.choice` не способна давать честное разбиение пятьдесят на пятьдесят на больших объёмах данных.
CМощность теста наоборот вырастет: каждый запрос даёт независимое наблюдение, и общее число наблюдений в эксперименте увеличивается.
DЭксперимент станет корректнее: каждый запрос рассматривается как самостоятельный юнит назначения варианта.
Ответ: Назначение варианта на каждом запросе нарушает фиксацию пользователя в одной группе, и эффект варианта смешивается с эффектом мерцания интерфейса.
В A/B-тесте принципиально, чтобы один пользователь стабильно видел один вариант: тогда разница в метрике отражает именно изменение продукта. Если назначение делается на каждый запрос, тот же человек случайно скачет между A и B, и эффект изменения смешивается с тем, что интерфейс постоянно меняется. Запросы внутри сессии нельзя считать независимыми наблюдениями: они сильно скоррелированы через одного пользователя, поэтому формальная «прибавка мощности» обманчива. `random.choice` сама по себе вполне справедлива, проблема не в её распределении.
2Вы тестируете новый экран оплаты. Пользователь может заходить в приложение много раз. Метрика — конверсия в покупку за 7 дней на уровне `user_id`. Какую единицу рандомизации выбрать, чтобы минимизировать смешение вариантов?
AРандомизировать по `session_id`: больше наблюдений и точность оценки эффекта вырастет
BРандомизировать по `device_id`, чтобы корректно учитывать поведение пользователя на разных устройствах
CРандомизировать по `user_id` и анализировать на уровне `user_id`, чтобы один человек видел один вариант
DРандомизировать по каждому показу страницы `pageview` для ускорения набора статистики
Ответ: Юнит рандомизации должен совпадать с юнитом метрики: для конверсии за 7 дней на пользователя — это `user_id`.
Если метрика считается на уровне пользователя за 7 дней, рандомизация тоже должна быть по `user_id`, иначе один человек увидит оба варианта и эффект «размажется». При рандомизации по сессии или показу страницы один и тот же пользователь попадёт сразу в обе группы, и сравнение перестанет отвечать на вопрос «кто бы конвертировался, если бы ему всегда показывали B». `device_id` тоже плох, потому что один пользователь часто заходит с нескольких устройств, и опять смешает группы.
3Вы рандомизируете по `device_id`, но метрика — доля пользователей, совершивших покупку за неделю, считается на уровне аккаунта `user_id` (часть пользователей имеет два устройства). Что корректнее?
AРандомизировать на уровне `user_id` или учётной записи, чтобы один человек не оказался в обоих вариантах через разные устройства.
BОставить рандомизацию по `device_id`, а потом просто суммировать покупки в разрезе `user_id` при подсчёте итоговой метрики на аккаунт.
CРандомизировать по `session_id`, потому что сессия ближе к моменту покупки и метрика будет точнее отражать поведение в варианте.
DРандомизировать по типу устройства (мобильное или десктоп), чтобы распределение пользователей между вариантами было сбалансированным.
Ответ: Если у одного `user_id` несколько устройств, рандомизация по устройству ведёт к смешению вариантов внутри пользователя.
Пользователь с двумя устройствами может одновременно попасть и в тестовую, и в контрольную группу, что размывает наблюдаемый эффект. Это особенно плохо для метрик, которые считаются на уровне аккаунта за период наблюдения. В таких задачах единицу рандомизации выбирают на уровне `user_id` или другой устойчивой учётной записи. Так каждый пользователь получает один и тот же вариант на всех своих устройствах.
4Вы делаете разбивку пользователей на группы как `hash(user_id + day) % 2`, где `day` — текущая дата. Что самое вероятное следствие для эксперимента?
AОдин и тот же `user_id` будет перескакивать между вариантами по дням, что приведёт к смешиванию воздействий
BГруппы будут идеально 50/50 в каждый день, потому что хеш равномерно делит трафик пополам
CЭто снижает риск `SRM`, потому что распределение пересчитывается каждый день и автоматически выравнивается
DЭто автоматически компенсирует сезонность по дням недели за счёт смены ключа разбивки
Ответ: Разбивка на группы должна быть детерминированной и стабильной во времени для одного `user_id`, иначе пользователь увидит разные варианты.
Добавление `day` в ключ делает назначение зависимым от даты, поэтому один и тот же пользователь будет получать разные варианты в разные дни. В результате внутри одного `user_id` происходит смена воздействия, и эффект размывается. Кроме того, такая схема усложняет анализ по когортам и повышает риск непредсказуемых перекосов в данных.
5В эксперименте на ранжировании пользователи разбиты на группы по `user_id`, но общий кэш поиска не учитывает вариант и иногда отдаёт пользователю выдачу другого варианта. Что это за риск?
AЗагрязнение групп: пользователи получают опыт другого варианта через общий кэш, что нарушает предпосылки `SUTVA` и размывает эффект
BЭто `SRM`: общий кэш меняет фактические размеры контрольной и тестовой групп и поэтому ломает соотношение между ними
CЭто только снижение скорости системы из-за общего кэша, на корректность измеряемого эффекта эксперимента это не влияет
DПроблема только в выборе единицы анализа: общий кэш на эту единицу не влияет, поэтому достаточно поправить только её
Ответ: Если инфраструктура смешивает выдачи разных вариантов, происходит загрязнение групп и эксперимент перестаёт измерять чистый эффект.
Кэш, который не учитывает вариант, делает фактический показ несовпадающим с назначением по группам. Тогда часть пользователей контрольной группы увидит поведение тестового варианта или наоборот, и различия между группами размоются. Это нарушает предпосылки `SUTVA` и может скрыть реальный эффект или создать ложный. Обычно решают добавлением варианта в ключ кэша и проверкой согласованности назначения и фактического показа.