Экспозиция в A/B-тесте: если её нет в логах, «эффект есть», но вы не понимаете где и почему.
Классический сюжет: тест запустили, метрика по вариантам разъехалась, продакт уже хочет катить. А аналитик зависает в разборе: воронка не сходится, у части пользователей фича как будто не показывалась, а у части показывалась, но позже. Итог одинаково плохой: либо катим по миражу, либо неделями спорим про «шум».
Проблема обычно не в статистике, а в трёх разных вещах, которые в данных смешали в одну: assignment: кого система назначила в вариант eligibility: кто вообще мог участвовать по условиям exposure: кто реально столкнулся с изменением
Если вы считаете эффект по assignment, а фича по факту трогает только экспозед, вы получаете размазанный результат. Если exposure разный между вариантами, вы получаете не тест продукта, а тест доставки. Если eligibility плавает и не зафиксирована, вы каждый день сравниваете разные популяции.
Минимальный стандарт логирования, чтобы анализ не развалился:
- Событие назначения в эксперимент: experiment_id, variant, unit_id, timestamp, версия бакетинга. Это должно быть единым источником правды.
- Событие eligibility: факт, что пользователь попал в рамку теста в этот момент. Не «мы фильтром в запросе отрезали», а именно лог с причинами, если есть.
- Событие exposure: момент, когда пользователь мог испытать изменение. Не «экран открыт», если изменение в кнопке ниже, и не «фича включена в конфиге», если UI не дошёл. Экспозиция должна быть привязана к конкретной точке контакта.
- События метрик: конверсии и guardrails должны иметь тот же unit_id, понятные timestamps и стабильную схему атрибутов, иначе вы потом сами себе устроите «переезд метрики».
- Защита от дублей: правило, как считаем повторные exposure и повторные конверсии, и возможность это проверить в сырых логах.
Правильная практика выглядит так: вы можете построить три среза без фантазии и ручных допущений — assignment для ITT, eligibility для контроля рамки, exposure для понимания механики и диагностики доставки. Обычно спорят не про p-value, а про то, что считать экспозицией, и это нормально: важно, чтобы определение было фиксировано и проверяемо.
Исключение простое: если изменение строго серверное и гарантированно применяется ко всем назначенным, экспозиция может совпадать с assignment. Но это надо доказать логами, а не верой в инфраструктуру.
