Дизайн эксперимента и рандомизация: вопросы для собеседования (часть 3)
Выбор единицы рандомизации (user_id, session_id, device_id), устойчивый bucketing, split-трафик — ошибки на этапе дизайна эксперимента невозможно исправить при анализе. На собеседовании просят объяснить, почему нельзя рандомизировать по сессии, если метрика считается на уровне пользователя. Эти вопросы отделяют тех, кто «запускал тесты», от тех, кто понимает, как они работают.
Вопросы 11–15 из 20
11В тесте поиска рандомизация по `user_id`. Метрика — CTR по каждому запросу, у активных пользователей запросов намного больше. Как выбрать корректную `unit of analysis`, чтобы один супер-активный пользователь не доминировал в результате?
AСчитать каждый запрос независимым и усреднить CTR по всем запросам в целом
BАгрегировать CTR на уровне `user_id` и сравнивать пользователей или использовать методы, учитывающие кластеризацию по `user_id`
CУдалить из анализа пользователей, у которых запросов больше среднего
DСделать рандомизацию по запросу вместо `user_id`, тогда проблема исчезнет
Ответ: Когда `unit of randomization` (единица рандомизации) — `user_id`, обычно безопаснее анализировать на уровне пользователя или учитывать зависимость запросов внутри пользователя.
Если усреднять по запросам, пользователи с большим числом запросов получают непропорционально большой вес. Это может менять интерпретацию эффекта и вести к неверным стандартным ошибкам, потому что запросы одного `user_id` зависимы. Частый подход — считать пользовательский CTR (например, клики делить на показы по пользователю) и сравнивать распределения по `user_id`. Альтернатива — анализ на уровне запросов с корректным учетом кластеризации по пользователям.
12Эксперимент рандомизируется по `store_id` (каждый магазин — `cluster`), потому что сотрудники влияют на опыт всех клиентов в магазине. Метрика — средний чек клиентов. Какой `unit of analysis` чаще всего корректнее для вывода эффекта?
AКаждый чек как независимый, потому что чек отражает решение клиента
BАгрегировать метрику на уровне `store_id` и сравнивать магазины или использовать кластерные ошибки по `store_id`
CСчитать только первые 10 чеков в каждом магазине, тогда зависимость исчезнет
DСменить рандомизацию на `user_id`, чтобы анализировать по пользователям
Ответ: При рандомизации по `cluster` анализ должен учитывать кластерную структуру, иначе стандартные ошибки будут занижены.
Если рандомизируются магазины, то именно магазины являются независимыми единицами назначения. Считать каждый чек независимым значит игнорировать общие факторы внутри магазина, что обычно занижает дисперсию и делает выводы слишком оптимистичными. Типовой подход — считать метрику на уровне `store_id` или применять методы, учитывающие кластеризацию. Это согласует `unit of analysis` с `unit of randomization` (единица рандомизации).
13Часть пользователей не авторизована, и вы используете `device_id` для `bucketing` (разбивка пользователей на группы), а после логина появляется `user_id`. Что лучше сделать, чтобы один человек не увидел оба варианта при переходе в авторизованное состояние?
AНичего, смена варианта при логине не влияет на результат
BКаждый раз пересчитывать вариант от `user_id` и игнорировать прошлый вариант на `device_id`
CСвязать `device_id` и `user_id` и закрепить вариант при первом известном идентификаторе, чтобы вариант не менялся при логине
DНазначать вариант по времени суток, тогда логин не важен
Ответ: В идентификационных цепочках важно обеспечить стабильность назначения при смене идентификатора, иначе появляется contamination.
Если до логина пользователь в одном варианте, а после логина автоматически попадает в другой, то опыт становится смешанным. Это особенно критично для метрик с окном в несколько дней и для сценариев, где пользователь может логиниться часто. Практика — хранить закрепленное назначение и переносить его при объединении `device_id` с `user_id`. Так `bucketing` (разбивка пользователей на группы) остается стабильным для одного человека.
14Эксперимент рандомизируется по `user_id`, а вы считаете метрику на уровне `session_id` (например, длительность сессии) и сравниваете сессии как независимые наблюдения. Что здесь главное методологическое последствие?
AНикакого, если сессий много, то независимость гарантирована
BСтандартные ошибки могут быть занижены, потому что сессии одного `user_id` зависимы, и нужно агрегировать до пользователя или учитывать кластеризацию
CСреднее значение метрики обязательно станет смещенным вверх
DЭто автоматически приводит к `SRM` (Sample Ratio Mismatch) даже при правильном `bucketing` (разбивка пользователей на группы)
Ответ: Если `unit of analysis` мельче `unit of randomization` (единица рандомизации), наблюдения внутри одного объекта коррелируют и стандартные ошибки могут быть занижены.
При рандомизации по `user_id` независимыми являются пользователи, а не их сессии. У одного пользователя поведение по сессиям часто связано, поэтому считать каждую `session_id` независимой ошибочно. Это обычно не обязательно смещает средний эффект, но может дать слишком оптимистичные p-value и доверительные интервалы. Типовые решения — агрегировать метрику на `user_id` или использовать кластерные ошибки на уровне пользователя.
15В тесте нового реферального механизма пользователь из `treat` отправляет приглашения друзьям, которые попадают в `control` и тоже меняют поведение. Какое допущение нарушается и почему это важно?
AНарушается `SRM` (Sample Ratio Mismatch), потому что группы должны быть строго 50/50
BНарушается требование одинаковых средних до старта, потому что у друзей разные интересы
CНарушается `SUTVA (Stable Unit Treatment Value Assumption)`, потому что исход пользователей из `control` зависит от назначения других пользователей через приглашения
DНарушается принцип случайности, потому что рефералы приходят только по выходным
Ответ: `SUTVA (Stable Unit Treatment Value Assumption)` требует отсутствия `interference`, то есть результат одного юнита не должен зависеть от назначения других.
Реферальные механики создают spillover: действия пользователей из `treat` меняют опыт тех, кто формально в `control`. В таком случае сравнение групп перестает измерять чистый эффект изменения, потому что контроль уже частично подвергся воздействию. Это может приводить к смещению оценки и сложной интерпретации причин. Часто помогают сетевые или кластерные дизайны, где минимизируют контакты между вариантами.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram