Дизайн эксперимента и рандомизация: вопросы для собеседования (часть 3)
Выбор единицы рандомизации (user_id, session_id, device_id), устойчивый bucketing, split-трафик — ошибки на этапе дизайна эксперимента невозможно исправить при анализе. На собеседовании просят объяснить, почему нельзя рандомизировать по сессии, если метрика считается на уровне пользователя. Эти вопросы отделяют тех, кто «запускал тесты», от тех, кто понимает, как они работают.
Вопросы 11–15 из 20
11В тесте поиска рандомизация идёт по `user_id`. Метрика — CTR по каждому запросу, у активных пользователей запросов намного больше. Как выбрать корректную единицу анализа, чтобы один сверх-активный пользователь не доминировал в результате?
AСчитать каждый запрос независимым наблюдением и усреднять CTR по всем запросам, не учитывая принадлежность к `user_id`
BУдалить из анализа активных пользователей, у которых число запросов выше среднего, и считать CTR только по оставшимся
CАгрегировать CTR на уровне `user_id` или применять методы, учитывающие кластеризацию запросов внутри одного пользователя
DПерейти на рандомизацию по запросу вместо `user_id`, тогда зависимость наблюдений в группах исчезнет автоматически
Ответ: Когда единица рандомизации — `user_id`, обычно безопаснее анализировать на уровне пользователя или явно учитывать зависимость запросов внутри одного пользователя.
Если усреднять по запросам, пользователи с большим числом запросов получают непропорционально большой вес. Это меняет интерпретацию эффекта и ведёт к занижению стандартных ошибок, потому что запросы одного `user_id` зависимы. Частый подход — считать пользовательский CTR (клики делить на показы по каждому пользователю) и сравнивать распределения по `user_id`. Альтернатива — анализ на уровне запросов с корректным учётом кластеризации по пользователям.
Подробный разбор → 12Эксперимент рандомизируется по `store_id` (каждый магазин — кластер), потому что сотрудники влияют на опыт всех клиентов в магазине. Метрика — средний чек клиентов. Какая единица анализа чаще всего корректнее для вывода эффекта?
AСчитать метрику на уровне `store_id` и сравнивать магазины, либо использовать стандартные ошибки с поправкой на кластеры по `store_id`.
BСчитать каждый чек по `receipt_id` независимым наблюдением, потому что чек отражает решение клиента и не зависит от других чеков магазина.
CБрать только первые 10 чеков в каждом `store_id` за период наблюдения, чтобы предполагаемая зависимость между наблюдениями стала пренебрежимо мала.
DСменить единицу рандомизации на `user_id` и анализировать эффект по пользователям, не учитывая, что назначение шло на уровне магазинов.
Ответ: При рандомизации по `cluster` анализ должен учитывать кластерную структуру, иначе стандартные ошибки будут занижены.
Если рандомизируются магазины, то именно магазины являются независимыми единицами назначения. Считать каждый чек независимым значит игнорировать общие факторы внутри магазина, что обычно занижает дисперсию и делает выводы слишком оптимистичными. Типовой подход — считать метрику на уровне `store_id` или применять методы, учитывающие кластеризацию. Это согласует единицу анализа с единицей рандомизации.
Подробный разбор → 13Часть пользователей не авторизована, и вы используете `device_id` для разбивки на группы, а после логина появляется `user_id`. Что лучше сделать, чтобы один человек не увидел оба варианта при переходе в авторизованное состояние?
AНичего не делать: смена варианта при логине не влияет на результаты, потому что метрика всё равно считается на уровне пользователя
BНазначать вариант случайно по часу суток входа в приложение, тогда логин не влияет на принадлежность к группе и эксперимент сохраняет балансировку
CКаждый раз пересчитывать вариант от `user_id` после логина и игнорировать прошлый вариант на `device_id`, чтобы все события писались под новым идентификатором
DСвязать `device_id` и `user_id` в единый идентификатор и закрепить вариант при первом известном идентификаторе, чтобы вариант не менялся при логине пользователя
Ответ: В цепочках идентификаторов важно обеспечить стабильность назначения варианта при смене идентификатора, иначе появляется загрязнение групп.
Если до логина пользователь в одном варианте, а после логина автоматически попадает в другой, то опыт становится смешанным. Это особенно критично для метрик с окном в несколько дней и для сценариев, где пользователь логинится часто. Практика — хранить закреплённое назначение и переносить его при объединении `device_id` с `user_id`. Так разбивка на группы остаётся стабильной для одного человека.
Подробный разбор → 14Эксперимент рандомизируется по `user_id`, а вы считаете метрику на уровне `session_id` (например, длительность сессии) и сравниваете сессии как независимые наблюдения. Что здесь главное методологическое последствие?
AПри большом числе сессий независимость наблюдений выполняется автоматически и стандартные ошибки можно считать обычным способом
BСтандартные ошибки занижены: сессии одного `user_id` зависимы, нужно агрегировать метрику до пользователя или учесть кластеризацию
CСреднее значение метрики становится смещённым вверх из-за повторных наблюдений одного `user_id` в подсчёте
DВозникает `SRM` даже при правильной разбивке пользователей по группам из-за неравномерного распределения сессий
Ответ: Если единица анализа мельче единицы рандомизации, наблюдения внутри одного объекта коррелируют и стандартные ошибки могут быть занижены.
При рандомизации по `user_id` независимыми являются пользователи, а не их сессии. У одного пользователя поведение по сессиям часто связано, поэтому считать каждую `session_id` независимой ошибочно. Это обычно не смещает средний эффект, но может дать слишком оптимистичные `p-value` и доверительные интервалы. Типовые решения — агрегировать метрику на `user_id` или использовать кластерные ошибки на уровне пользователя.
Подробный разбор → 15В тесте нового реферального механизма пользователь из тестовой группы отправляет приглашения друзьям, которые попадают в контрольную и тоже меняют поведение. Какое допущение нарушается и почему это важно?
AНарушается баланс долей групп, потому что соотношение тестовой и контрольной должно быть строго 50/50 в каждый момент времени
BНарушается требование одинаковых средних значений метрики до старта, потому что у друзей пользователя обычно разные интересы
CНарушается допущение `SUTVA`: исход пользователей из контрольной группы зависит от назначения других пользователей через приглашения
DНарушается принцип случайности, потому что приглашения от рефералов приходят неравномерно и в основном по выходным
Ответ: Допущение `SUTVA` требует отсутствия взаимного влияния между пользователями: исход одного юнита не должен зависеть от назначения других.
Реферальные механики создают перетекание эффекта: действия пользователей из тестовой группы меняют опыт тех, кто формально в контрольной. В таком случае сравнение групп перестаёт измерять чистый эффект изменения, потому что контроль уже частично подвергся воздействию. Это может приводить к смещению оценки и сложной интерпретации причин. Часто помогают сетевые или кластерные дизайны, где минимизируют контакты между вариантами.
Подробный разбор →