Дизайн эксперимента и рандомизация: вопросы для собеседования (часть 4)
Выбор единицы рандомизации (user_id, session_id, device_id), устойчивый bucketing, split-трафик — ошибки на этапе дизайна эксперимента невозможно исправить при анализе. На собеседовании просят объяснить, почему нельзя рандомизировать по сессии, если метрика считается на уровне пользователя. Эти вопросы отделяют тех, кто «запускал тесты», от тех, кто понимает, как они работают.
Вопросы 16–20 из 20
16Вы тестируете новый алгоритм рекомендаций для части пользователей. В варианте `treat` товар распродается быстрее, из-за чего пользователи из `control` чаще видят сообщение «Нет в наличии». Как лучше всего описать эту проблему?
AЭто `SRM` (Sample Ratio Mismatch), потому что распределение по группам стало не 50/50
BЭто нормальный шум, который всегда есть в экспериментах
CЭто `interference` и нарушение `SUTVA (Stable Unit Treatment Value Assumption)` из-за общего инвентаря, который связывает результаты разных пользователей
DЭто обязательно означает, что `hash()` работает неправильно
Ответ: Общий ресурс (инвентарь, очередь, кэш) может создавать `spillover`, из-за чего исход в `control` зависит от назначения `treat`.
Когда есть общий инвентарь, действия пользователей из `treat` меняют среду для `control`, например через ситуации, когда товар заканчивается (out-of-stock). Тогда разница между группами отражает не только изменение интерфейса или алгоритма, но и косвенные эффекты через ресурс. Это нарушает предпосылку независимости исходов и может как завышать, так и занижать оценку эффекта. Возможные решения — менять `unit of randomization` (единица рандомизации) (например, по категории или складу) или использовать дизайн, который минимизирует конкуренцию между вариантами.
17Вы хотите сегментировать результаты по VIP, где VIP определяется как пользователи с покупками за последние 30 дней. Но тест влияет на покупки, значит статус VIP может измениться из-за самого теста. Как правильно поступить, если цель — честная сегментация эффекта?
AСегментировать по VIP, пересчитанному каждый день, так сегмент будет актуальным
BСегментировать VIP только внутри `treat`, а `control` оставить без сегмента
CЗафиксировать VIP-статус до старта эксперимента по данным pre-period и использовать его как неизменяемый сегмент
DНе сегментировать вообще, потому что сегменты всегда делают анализ неверным
Ответ: Сегменты должны быть определены по данным до назначения варианта, иначе возникнет смещение из-за разбиения после воздействия (post-treatment).
Если VIP-статус меняется под влиянием теста, сегментация превращается в сравнение групп, определенных частично результатом самого эксперимента. Это создает смещение и делает выводы о VIP некорректными. Практичный подход — определить сегмент по данным до назначения и держать его фиксированным на весь период эксперимента. Тогда сегментация отвечает на вопрос, как эффект отличается для заранее известных VIP и не-VIP.
18Маркетплейс: тест меняет ранжирование для покупателей в `treat`, что увеличивает показы и продажи некоторых продавцов. Эти продавцы затем меняют цену или наличие, и это влияет на покупателей из `control`. Какой вывод наиболее корректен?
AЭто чистый эффект, `SUTVA (Stable Unit Treatment Value Assumption)` выполнено, потому что рандомизация по `user_id` корректна
BЭто `SRM` (Sample Ratio Mismatch), потому что продавцы меняют цены, а значит группы стали неравными
CДостаточно увеличить выборку, и проблема исчезнет
DЭто `interference` между сторонами рынка, и может потребоваться другая `unit of randomization` (единица рандомизации) или дизайн, учитывающий двусторонние spillovers
Ответ: На двусторонних рынках часто нарушается `SUTVA (Stable Unit Treatment Value Assumption)`, потому что лечение одной стороны меняет среду для другой.
Даже при корректном `bucketing` (разбивка пользователей на группы) по `user_id` изменения у покупателей могут менять стимулы и поведение продавцов. Эти изменения затем возвращаются в виде другой среды и для пользователей из `control`, создавая spillovers. В такой ситуации простое сравнение групп может не отражать изолированный эффект и требует осторожной интерпретации. Возможны альтернативы: рандомизация по рынку, категории или времени, а также дизайны, которые явно учитывают взаимодействие сторон. Главное — заранее признать риск `interference` и выбирать дизайн под структуру системы.
19Есть два фактора: новый дизайн карточки и новая логика рекомендаций. Команда хочет запустить два эксперимента одновременно на одной аудитории. В каком случае разумно выбрать факторный дизайн `2x2` вместо взаимного исключения аудиторий?
AВсегда, потому что `2x2` автоматически лучше любого другого дизайна
BТолько когда аудитории не пересекаются, иначе эксперимент станет некорректным
CТолько когда нельзя разделить пользователей по `bucketing` (разбивка пользователей на группы)
DКогда важно оценить взаимодействие факторов и есть достаточная мощность на все 4 комбинации вариантов
Ответ: Факторный дизайн полезен, если вы сознательно допускаете пересечение и хотите оценить не только главные эффекты, но и взаимодействие.
В `2x2` вы получаете четыре группы и можете оценить как эффект каждого фактора, так и их взаимодействие. Это удобно, если изменения потенциально влияют друг на друга и вы хотите это измерить. Однако каждая ячейка получает меньшую долю трафика, поэтому требуется больше времени или аудитории для достаточной точности. Если взаимодействие не важно, часто проще и безопаснее использовать взаимное исключение аудиторий.
20Два независимых эксперимента одновременно меняют одну и ту же страницу checkout, оба рандомизируются по `user_id`. Аудитории пересекаются. Какое решение лучше всего, чтобы интерпретация результатов была надежной?
AЗапускать оба как есть и интерпретировать каждый тест отдельно
BОстановить один эксперимент и никогда не запускать параллельные тесты
CИспользовать слои `bucketing` (разбивка пользователей на группы) с взаимным исключением аудиторий или заранее планировать факторный дизайн `2x2`
DПерейти на рандомизацию по `session_id`, тогда пересечения не важны
Ответ: Пересекающиеся эксперименты создают взаимодействия и коллизии аудиторий, поэтому нужны правила разруливания пересечений.
Если аудитория пересекается, один пользователь может одновременно находиться под влиянием двух изменений, и эффекты могут не складываться линейно. Тогда оценка каждого эксперимента по отдельности становится трудно интерпретируемой и может быть смещенной. Практичные решения — взаимно исключающие слои `bucketing` (разбивка пользователей на группы) или факторный дизайн `2x2`, если вы хотите измерять взаимодействие. Важно также логировать участие пользователя в каждом экспериментальном слое.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram