Дизайн экспериментов
За пределами обычного A/B — SRM, CUPED, последовательные и switchback-дизайны, кластеры, интерференция, раскатки.
16 вопросов
JuniorТеорияОчень частоКакие три свойства делают результат онлайн A/B теста достоверным?
Какие три свойства делают результат онлайн A/B теста достоверным?
Три вещи: случайное распределение, чтобы группы отличались только воздействием и конфаундеры выравнивались; изоляция, чтобы пользователи одной группы не влияли на другую; и одна основная метрика, зафиксированная до старта, чтобы нельзя было выбрать «победителя» уже после просмотра данных.
Типичные ошибки
- ✗Считать, что достаточно большая выборка снимает нужду в рандомизации
- ✗Полагать, что группы изолированы, даже когда treated влияет на control
- ✗Выбирать метрику после того, как увидели, какая выросла
Уточняющие вопросы
- →Как рандомизация выравнивает конфаундеры, которые вы даже не измеряли?
- →Что ломается, когда пользователи одной группы влияют на другую?
MiddleТеорияОчень частоПочему недомощный A/B тест, «не показавший разницы», ничего не доказывает?
Почему недомощный A/B тест, «не показавший разницы», ничего не доказывает?
Мощность — вероятность обнаружить истинный эффект заданного размера; у недомощного теста высока доля ложноотрицательных, поэтому незначимый результат ожидаем даже при реальном эффекте — отсутствие свидетельства, а не свидетельство отсутствия. «p > 0.05» — не «разницы нет»: интервал слишком широк.
Типичные ошибки
- ✗Читать «p > 0.05» как доказательство равенства групп
- ✗Игнорировать ширину доверительного интервала при трактовке null
- ✗Путать точность (мощность) со смещением точечной оценки
Уточняющие вопросы
- →Что вы посчитаете, чтобы решить, информативен ли null-результат?
- →Чем тест эквивалентности отличается от проваленного теста на превосходство?
MiddleДизайнЧастоВы раскатываете изменение 1% → 5% → 25% → 50%, задерживаясь на каждой стадии. У вас есть операционные guardrail в реальном времени (latency, error rate, crash rate) и более медленные бизнес-метрики (конверсия, выручка на пользователя). Опишите, что вы мониторите на каждом шаге раскатки и что запускает автоматический откат, и объясните, почему вы раскатываете постепенно, а не идёте сразу к тесту 50/50. Будьте конкретны, какой класс сигнала гейтит каждую стадию и как меняется статистика по мере роста охваченной популяции.
Вы раскатываете изменение 1% → 5% → 25% → 50%, задерживаясь на каждой стадии. У вас есть операционные guardrail в реальном времени (latency, error rate, crash rate) и более медленные бизнес-метрики (конверсия, выручка на пользователя). Опишите, что вы мониторите на каждом шаге раскатки и что запускает автоматический откат, и объясните, почему вы раскатываете постепенно, а не идёте сразу к тесту 50/50. Будьте конкретны, какой класс сигнала гейтит каждую стадию и как меняется статистика по мере роста охваченной популяции.
Раскатка ограничивает радиус поражения. На 1% катастрофический баг — краши, 5xx, скачки latency — задевает мало пользователей и срабатывает по быстрым guardrail; они гейтят ранние стадии. Расширение до 25–50% даёт охват, чтобы читать медленные бизнес-метрики с мощностью, гейтя поздние стадии. Откат срабатывает при пробое guardrail за порог.
Типичные ошибки
- ✗Читать бизнес-метрики на 1% так, будто они уже мощны
- ✗Позволять медленной бизнес-значимости, а не быстрым guardrail, гейтить ранние стадии
- ✗Утверждать, что прямой запуск 50/50 безопаснее раскатки
Уточняющие вопросы
- →Почему нельзя доверять метрике конверсии на стадии 1%?
- →Какие пороги guardrail вы бы завели на авто-откат?
MiddleДизайнЧастоВаша команда за квартал выкатывает десятки мелких улучшений ранжирования и UI, каждое по A/B положительно, но north-star растёт лишь медленно. Руководство спрашивает, действительно ли улучшения складываются или метрика растёт сама. Вы предлагаете 1% постоянный holdout: в начале года 1% пользователей случайно назначаются и держатся на старом baseline, не видя ни одного запуска года. Объясните, что этот holdout измеряет такого, чего не могут отдельные A/B, и чего это стоит — для отложенных пользователей и для бизнеса. Скажите, как его размерить и как прочитать в конце года.
Ваша команда за квартал выкатывает десятки мелких улучшений ранжирования и UI, каждое по A/B положительно, но north-star растёт лишь медленно. Руководство спрашивает, действительно ли улучшения складываются или метрика растёт сама. Вы предлагаете 1% постоянный holdout: в начале года 1% пользователей случайно назначаются и держатся на старом baseline, не видя ни одного запуска года. Объясните, что этот holdout измеряет такого, чего не могут отдельные A/B, и чего это стоит — для отложенных пользователей и для бизнеса. Скажите, как его размерить и как прочитать в конце года.
Отдельные A/B меряют каждое изменение поодиночке, упуская взаимодействия и дрейф, так что сумма мелких приростов завышает итог. Постоянный holdout на прошлогоднем baseline меряет истинный кумулятивный эффект всего выкаченного, очищенный от сезонности. Цена: отложенные жертвуют годом улучшений, отсюда ~1%, но с мощностью на малый эффект.
Типичные ошибки
- ✗Считать, что годовой эффект равен сумме приростов по запускам
- ✗Считать 1% holdout бесплатным, потому что он мал
- ✗Верить, что долгий holdout нельзя загрязнить
Уточняющие вопросы
- →Как размерить holdout, чтобы поймать малый совокупный прирост?
- →Что загрязняет долгий holdout и как это обнаружить?
MiddleДизайнЧастоПеред включением эксперимента вы записываете и фиксируете четыре вещи: одну основную метрику, минимально детектируемый эффект (MDE) с размером выборки и длительностью, которые он задаёт, guardrail-метрики и правило решения («катим, если основная значимо положительна и ни один guardrail не просел»). Это пре-регистрация. Для каждого из четырёх обязательств объясните конкретно, какое аналитическое злоупотребление оно предотвращает, когда пойдут данные, и что аналитик мог бы иначе сделать, оставь он его открытым. Затем назовите одну вещь, от которой пре-регистрация не защищает.
Перед включением эксперимента вы записываете и фиксируете четыре вещи: одну основную метрику, минимально детектируемый эффект (MDE) с размером выборки и длительностью, которые он задаёт, guardrail-метрики и правило решения («катим, если основная значимо положительна и ни один guardrail не просел»). Это пре-регистрация. Для каждого из четырёх обязательств объясните конкретно, какое аналитическое злоупотребление оно предотвращает, когда пойдут данные, и что аналитик мог бы иначе сделать, оставь он его открытым. Затем назовите одну вещь, от которой пре-регистрация не защищает.
Фиксация основной метрики останавливает metric shopping; фиксация MDE и размера выборки останавливает optional stopping (подглядывание, объявление при p < 0.05), раздувающее ложные срабатывания; фиксация guardrail мешает игнорировать просадку; фиксация правила решения — пост-хок рационализации. Она не чинит сломанный эксперимент.
Типичные ошибки
- ✗Верить, что пре-регистрация нейтрализует смещение от SRM или интерференции
- ✗Считать зафиксированный план изменяемой документацией, а не обязательством
- ✗Думать, что фиксация размера выборки только про бюджет, а не про уровень ошибок
Уточняющие вопросы
- →Почему optional stopping раздувает долю ложных срабатываний?
- →Как поступить с действительно лучшей метрикой, найденной посреди эксперимента?
MiddleДебаггингЧастоСплит 50/50 в логах даёт 50.8/49.2 на 2M пользователей. О чём сигнализирует этот SRM и как починить назначение ниже?
Сплит 50/50 в логах даёт 50.8/49.2 на 2M пользователей. О чём сигнализирует этот SRM и как починить назначение ниже?
SRM значит, что сплит отклоняется от заданного соотношения сильнее случайного — χ² по счётчикам групп даёт крошечный p-value — назначение или логирование сломано и вывод недействителен. Баг: eligibility проверяется только в ветке treatment, поэтому неподходящие падают в control; отсеките их до бакетирования.
Открыть задачу →Типичные ошибки
- ✗Списывать значимый SRM на безвредный шум округления
- ✗Пытаться перевзвесить или залатать группы вместо починки назначения и перезапуска
- ✗Применять фильтр eligibility или логирования только к одной группе
Уточняющие вопросы
- →Какую χ²-статистику и порог вы бы взяли, чтобы отметить SRM?
- →Почему нельзя спасти смещённые данные перевзвешиванием постфактум?
MiddleТеорияИногдаМигрируя инфраструктуру, вы должны доказать, что новая система не хуже. Как переворачиваются гипотезы в тесте не-хуже?
Мигрируя инфраструктуру, вы должны доказать, что новая система не хуже. Как переворачиваются гипотезы в тесте не-хуже?
Тест на превосходство имеет H0: разницы нет. Тест не-хуже переворачивает: берут маржу δ — наибольшую терпимую просадку — с H0: новая хуже хотя бы на δ. Не-хуже объявляют, когда CI для (new − control) целиком выше −δ. Выбор δ — ключ: слишком мягкая пропускает регрессии, слишком жёсткая требует огромных выборок.
Типичные ошибки
- ✗Читать незначимый тест на превосходство как доказательство не-хуже
- ✗Пропускать маржу терпимости δ или задавать её после просмотра данных
- ✗Брать критерием двусторонний интервал, содержащий ноль
Уточняющие вопросы
- →Как выбрать маржу δ для миграции по latency?
- →Почему δ надо фиксировать до эксперимента, а не после?
SeniorДизайнИногдаВы рандомизируете политику по городам — часть городов в treatment, часть в control — потому что вмешательство влияет на весь локальный рынок. Коллега считает мощность по миллионам пользователей этих городов и рапортует значимый выигрыш на горстке городов в группе. Объясните, почему эффективный размер выборки — это число городов, а не пользователей, какая статистическая величина это задаёт и что это значит для нужного числа кластеров и для того, как считать стандартные ошибки.
Вы рандомизируете политику по городам — часть городов в treatment, часть в control — потому что вмешательство влияет на весь локальный рынок. Коллега считает мощность по миллионам пользователей этих городов и рапортует значимый выигрыш на горстке городов в группе. Объясните, почему эффективный размер выборки — это число городов, а не пользователей, какая статистическая величина это задаёт и что это значит для нужного числа кластеров и для того, как считать стандартные ошибки.
Пользователи в городе делят шоки — погоду, маркетинг, один рынок — поэтому не независимы; воздействие назначено на уровне города, значит город — единица. Внутрикластерная корреляция раздувает дисперсию на design effect 1+(m−1)ρ, поэтому эффективное n идёт по числу городов, а не пользователей. Нужно много городов и кластерные ошибки.
Типичные ошибки
- ✗Считать мощность по числу пользователей, а не кластеров
- ✗Верить, что фиксированный эффект города возвращает валидный пользовательский тест
- ✗Пропускать кластерные стандартные ошибки на уровне города
Уточняющие вопросы
- →Как design effect 1+(m−1)ρ растёт с увеличением городов?
- →Почему кластерные ошибки не спасают при малом числе кластеров?
SeniorТеорияИногдаКогда multi-armed bandit лучше A/B с фиксированным распределением, и чем адаптивное распределение платит в выводе?
Когда multi-armed bandit лучше A/B с фиксированным распределением, и чем адаптивное распределение платит в выводе?
Бандит перегоняет трафик к выигрывающей руке, минимизируя regret — уместен при оптимизации суммарной награды на коротком горизонте или многих руках, не точного эффекта. Цена: распределение зависит от данных, так что интервалы и p-value с фиксированным n смещены, а проигравшая рука даёт шумную оценку. Фиксированный A/B — для долгого решения.
Типичные ошибки
- ✗Считать бандит заменой, сохраняющей вывод уровня A/B
- ✗Верить, что обеднённая проигрывающая рука даёт точную оценку эффекта
- ✗Брать бандит для долгого решения, где нужен несмещённый вывод
Уточняющие вопросы
- →Почему зависящие от данных размеры рук смещают наивный доверительный интервал?
- →Для каких решений минимизация regret стоит более шумной оценки эффекта?
SeniorДизайнИногдаВы тестируете фичу сообщений: новый flow создания заставляет treated-пользователей слать больше сообщений. Но treated пишут control-пользователям, которые отвечают, — поэтому активность control тоже растёт. Объясните, почему эта интерференция смещает обычный пользовательский A/B и в какую сторону, затем — как ego-cluster рандомизация (техника сетевой кластеризации, назначающая целые социальные окрестности в одну группу) сдерживает переток и чем это платится в мощности.
Вы тестируете фичу сообщений: новый flow создания заставляет treated-пользователей слать больше сообщений. Но treated пишут control-пользователям, которые отвечают, — поэтому активность control тоже растёт. Объясните, почему эта интерференция смещает обычный пользовательский A/B и в какую сторону, затем — как ego-cluster рандомизация (техника сетевой кластеризации, назначающая целые социальные окрестности в одну группу) сдерживает переток и чем это платится в мощности.
Treatment перетекает на control через граф, так что control частично «пролечена»: разрыв сжимается, и пользовательский A/B размывает эффект к нулю. Ego-cluster рандомизация кладёт окрестность пользователя в одну группу, и переток остаётся внутри кластера. Цена — независимых кластеров куда меньше, чем пользователей: ниже n и мощность.
Типичные ошибки
- ✗Путать направление — думать, что переток завышает, а не размывает
- ✗Верить, что можно удалить загрязнённый control и сохранить мощность
- ✗Считать, что кластеризация повышает число независимых единиц
Уточняющие вопросы
- →Почему переток смещает оценку к нулю, а не от него?
- →Как задать ego-кластеры, когда граф плотный?
SeniorТеорияИногдаКак последовательные тесты — mSPRT или group-sequential — легитимизируют раннюю остановку, недоступную наивному peeking?
Как последовательные тесты — mSPRT или group-sequential — легитимизируют раннюю остановку, недоступную наивному peeking?
Peeking снова проверяет те же данные при фиксированном α, поэтому каждый взгляд — новый шанс пересечь 0.05, и type-I ползёт выше α. Последовательные методы фиксируют правило остановки и бюджетируют ошибку по взглядам — group-sequential через alpha-spending границы, mSPRT через всегда-валидную статистику, — держа долю на α при ранней остановке.
Типичные ошибки
- ✗Верить, что повторные взгляды при фиксированном α не меняют долю type-I
- ✗Думать, что один строгий порог заменяет поштучный расход ошибки
- ✗Считать, что достаточно большой фиксированный размер узаконивает свободный peeking
Уточняющие вопросы
- →Почему каждый лишний взгляд раздувает долю ложных срабатываний?
- →Чем alpha-spending функция отличается от фиксированного разбиения Бонферрони?
SeniorДизайнИногдаВы тестируете новый алгоритм surge-ценообразования для маркетплейса такси. Пользовательский A/B невалиден: цены и предложение водителей задаются на весь рынок, поэтому райдер в «treatment» всё равно живёт в равновесии, которое помогают создавать control-райдеры, — группы перетекают друг в друга. Разбить рынок по пользователю чисто нельзя. Объясните, как switchback-дизайн — техника рандомизации по времени — позволяет измерить эффект алгоритма: какую единицу он рандомизирует, почему это убирает утечку и какую главную статистическую цену вы платите.
Вы тестируете новый алгоритм surge-ценообразования для маркетплейса такси. Пользовательский A/B невалиден: цены и предложение водителей задаются на весь рынок, поэтому райдер в «treatment» всё равно живёт в равновесии, которое помогают создавать control-райдеры, — группы перетекают друг в друга. Разбить рынок по пользователю чисто нельзя. Объясните, как switchback-дизайн — техника рандомизации по времени — позволяет измерить эффект алгоритма: какую единицу он рандомизирует, почему это убирает утечку и какую главную статистическую цену вы платите.
Switchback рандомизирует весь рынок между treatment и control по слотам, так что всё равновесие — цены, предложение — в окне включено или выключено; on-окна против off-окон меряют эффект уровня рынка без перетекания. Цена: единица — слот, поэтому эффективное n мало, а окна автокоррелируют, что режет мощность.
Типичные ошибки
- ✗Чередовать отдельных пользователей и называть это switchback
- ✗Игнорировать автокорреляцию между соседними временными окнами
- ✗Считать малое число слотов так, будто это число пользователей
Уточняющие вопросы
- →Как выбрать длину каждого switchback-окна?
- →Почему эффекты переноса требуют буферных периодов между переключениями?
SeniorДизайнИногдаИзменение маркетплейса — скрыть контакты продавца до оформления — помогает покупателям, но может вредить продавцам. Покупатели и продавцы взаимодействуют, поэтому чисто рандомизировать обе стороны разом нельзя: treated-покупатель всё равно встречает продавцов, что обслуживают и control-покупателей. Но руководству нужен вывод о чистом двустороннем эффекте до запуска. Опишите дизайн, дающий защитимую оценку вопреки перекрёстной интерференции, почему наивный пользовательский сплит смещён и какой конкретный компромисс навязывает исправление.
Изменение маркетплейса — скрыть контакты продавца до оформления — помогает покупателям, но может вредить продавцам. Покупатели и продавцы взаимодействуют, поэтому чисто рандомизировать обе стороны разом нельзя: treated-покупатель всё равно встречает продавцов, что обслуживают и control-покупателей. Но руководству нужен вывод о чистом двустороннем эффекте до запуска. Опишите дизайн, дающий защитимую оценку вопреки перекрёстной интерференции, почему наивный пользовательский сплит смещён и какой конкретный компромисс навязывает исправление.
Рандомизируйте на уровне, вмещающем обе стороны сделки — рынок/гео или двусторонний кластер, — чтобы treated-покупатель встречал в основном treated-продавцов и переток был внутри группы, давая чистый эффект. Наивный пользовательский сплит переливает воздействие между сторонами, смещая оценку к нулю. Компромисс: независимых единиц меньше — ниже мощность и дольше тест.
Типичные ошибки
- ✗Складывать два односторонних A/B, будто интерференция сокращается
- ✗Игнорировать сторону продавца, раз изменение обращено к покупателю
- ✗Верить, что перевзвешивание убирает перекрёстную утечку без цены в мощности
Уточняющие вопросы
- →Почему пользовательский сплит смещает двустороннюю оценку к нулю?
- →Как размерить гео-эксперимент, чтобы поймать малый чистый эффект?
SeniorТеорияРедкоКак техника снижения дисперсии CUPED использует данные до эксперимента, чтобы поднять мощность, и какой ковариат хорош?
Как техника снижения дисперсии CUPED использует данные до эксперимента, чтобы поднять мощность, и какой ковариат хорош?
CUPED вычитает из метрики Y член θ(X−E[X]), где X — ковариат до эксперимента, а θ=Cov(Y,X)/Var(X); так убирается дисперсия, объяснённая X, — она падает в 1−ρ² раз. Поскольку X измерен до назначения, он не двигает оценку эффекта, только её дисперсию. Хороший ковариат измерен до воздействия и сильно коррелирует с Y.
Типичные ошибки
- ✗Брать ковариат, измеренный во время эксперимента, а не до него
- ✗Верить, что CUPED меняет оценку эффекта, а не только её дисперсию
- ✗Думать, что дисперсия падает от меньшей выборки, а не от корреляции ρ
Уточняющие вопросы
- →Почему ковариат нужно измерять строго до назначения?
- →Насколько упадёт дисперсия, если ρ между Y и X равно 0.7?
SeniorДизайнРедкоДве команды запускают эксперименты на одной странице оформления заказа в одну неделю: команда A тестирует новый цвет кнопки, команда B — новый показ стоимости доставки. Если обе рандомизируют пользователей независимо, часть попадёт разом в A-treatment и B-treatment. Объясните, когда это пересечение создаёт реальную проблему, а когда безвредно, и как слоистая (ортогональная) система назначения позволяет многим экспериментам идти одновременно на одной поверхности без взаимного смешивания. Точно скажите, что делает эффект взаимодействия с каждым выводом.
Две команды запускают эксперименты на одной странице оформления заказа в одну неделю: команда A тестирует новый цвет кнопки, команда B — новый показ стоимости доставки. Если обе рандомизируют пользователей независимо, часть попадёт разом в A-treatment и B-treatment. Объясните, когда это пересечение создаёт реальную проблему, а когда безвредно, и как слоистая (ортогональная) система назначения позволяет многим экспериментам идти одновременно на одной поверхности без взаимного смешивания. Точно скажите, что делает эффект взаимодействия с каждым выводом.
Независимая рандомизация держит назначения ортогональными, поэтому каждый эффект в среднем оценивается верно несмотря на пересечение — чужой тест лишь добавляет шум. Опасность — настоящее взаимодействие: если эффекты не аддитивны, вывод смещён другим. Слоистая система хеширует эксперимент в свой слой, держа группы ортогональными; подозреваемые взаимодействия делят слой.
Типичные ошибки
- ✗Думать, что пересекающиеся эксперименты всегда идут последовательно
- ✗Верить, что выброс ячейки пересечения оставляет оба теста несмещёнными и мощными
- ✗Считать, что рандомизация исключает эффекты взаимодействия
Уточняющие вопросы
- →Почему ортогональное назначение оставляет каждый главный эффект несмещённым?
- →Когда вы намеренно положите два эксперимента в один слой?
