В эксперименте на ранжировании вы используете 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 или наоборот, и различия между группами размоются. Это нарушает предпосылки дизайна и может скрыть реальный эффект или создать ложный. Обычно решают добавлением варианта в ключ кэша и проверкой консистентности назначения и экспозиции.

Проверь себя · 1/3разбор после ответа
Вы тестируете новый экран оплаты. Пользователь может заходить в приложение много раз. Метрика — конверсия в покупку за 7 дней на уровне user_id. Какую unit of randomization (единица рандомизации) выбрать, чтобы минимизировать смешение вариантов?
Тренировать A/B в Telegram

Ещё вопросы по теме «Дизайн эксперимента и рандомизация»