A/B Testing
Интерактивный гайд: от дизайна эксперимента до анализа результатов. Считайте sample size, визуализируйте p-value, симулируйте множественное тестирование и доверительные интервалы.
Зачем A/B тесты?
Люди принимают решения на основе интуиции, авторитета или прошлого опыта. Проблема в том, что наш мозг полон когнитивных искажений: confirmation bias (видим то, что хотим), survivorship bias (изучаем только «выживших»), anchoring (первое число определяет оценку).
A/B тест — это контролируемый эксперимент, в котором пользователи случайно делятся на группы: контрольная (A) видит текущую версию, тестовая (B) — новую. Разница в метриках между группами говорит о каузальном эффекте изменения, а не просто о корреляции.
Без A/B теста
«Мы раскатили новую кнопку и конверсия выросла на 5%!» — но может это сезонность, маркетинговая кампания или просто шум данных?
С A/B тестом
Две группы в одних условиях, единственное отличие — тестируемое изменение. Если разница статистически значима, это реальный эффект.
Data-driven культура
В компаниях уровня Google, Yandex, Netflix каждое продуктовое изменение проходит через A/B тест. Netflix проводит ~250 тестов одновременно. Это не «научная прихоть» — это инженерная дисциплина, которая экономит миллионы.
Дизайн эксперимента
Перед запуском A/B теста нужно зафиксировать протокол эксперимента: гипотезу, метрики, размер выборки и критерий остановки.
1. Гипотеза
Формулируем нулевую (H₀) и альтернативную (H₁) гипотезы. H₀ — «изменение не влияет на метрику», H₁ — «влияет».
2. Метрики
Primary metric — основная метрика решения (конверсия, revenue per user). Guardrail metrics — метрики-ограничения, которые не должны деградировать (время загрузки, crash rate).
3. Рандомизация
Unit of randomization — на каком уровне делим: по пользователям, сессиям, устройствам? Обычно — по пользователю (user_id → hash → bucket). Это гарантирует, что один пользователь всегда видит одну версию.
Двухсторонняя проверка гипотез: нулевая vs альтернативная
Два типа ошибок: Type I (α) — ложное отвержение H₀ (нашли эффект, которого нет); Type II (β) — не отвергли H₀ при наличии эффекта (пропустили реальное улучшение).
| H₀ верна | H₀ ложна | |
|---|---|---|
| Отвергли H₀ | Type I error (α) | Верное решение (Power) |
| Не отвергли H₀ | Верное решение | Type II error (β) |
На собеседовании
Частый вопрос: «Какие метрики вы бы выбрали для A/B теста рекомендаций?» Правильный ответ: primary — CTR или engagement time; guardrail — latency, diversity, coverage. Обязательно упомяните unit of randomization и потенциальные spillover effects.
Размер выборки (Sample Size)
Главный вопрос перед запуском: «Сколько пользователей нужно в каждой группе?» Ответ зависит от четырёх параметров:
- α — уровень значимости (обычно 0.05). Вероятность ложного срабатывания.
- β — вероятность пропустить реальный эффект. Power = 1−β (обычно 0.8).
- σ² — дисперсия метрики. Чем больше шум — тем больше выборка.
- δ (MDE) — минимально детектируемый эффект. Какую разницу хотим уловить?
Формула для непрерывных метрик (двухсторонний z-test)
Для пропорций (конверсия) формула модифицируется:
Формула для двух пропорций, n — на одну группу
Ключевые наблюдения: выборка растёт квадратично при уменьшении MDE. Хотите детектировать эффект в 2 раза меньше — нужно в 4 раза больше данных. Это фундаментальное ограничение.
Практическая ловушка
Менеджер говорит: «Нам нужен тест на неделю». Но расчёт показывает, что для MDE=0.5% нужно 2 месяца трафика. Варианты: (1) увеличить MDE (если бизнес-ценность мелкого эффекта невелика), (2) снизить α/power, (3) уменьшить дисперсию через стратификацию (CUPED).
Статистические тесты
Когда данные собраны, нужно определить — значима ли разница? Выбор теста зависит от типа метрики и размера выборки:
| Тест | Когда использовать | Метрика |
|---|---|---|
| Z-test | Большая выборка (n > 30), известна σ | Непрерывные, пропорции |
| t-test | Малая выборка, неизвестна σ | Непрерывные (revenue, time) |
| χ²-test | Категориальные данные | Конверсия, CTR |
| Mann-Whitney | Не-нормальное распределение | Revenue (тяжёлые хвосты) |
Z-статистика для разности двух средних:
Z-test: нормированная разность средних
P-value — вероятность получить наблюдаемую (или более экстремальную) разницу при условии, что H₀ верна. Если p-value < α — отвергаем H₀.
Двухсторонний p-value
Доверительный интервал — альтернативный взгляд на значимость. Если CI для разности не содержит 0 — эффект значим:
Доверительный интервал для разности средних
P-value ≠ вероятность H₀
Распространённое заблуждение: «p=0.03 значит вероятность что H₀ верна — 3%». Нет! P-value — это вероятность данных при условии H₀. Для вероятности гипотезы нужен Bayesian подход (posterior = likelihood × prior / evidence).
Множественное тестирование
Если тестировать 20 метрик одновременно с α=0.05, ожидаемое число ложных срабатываний — 1! Это проблема множественных сравнений (multiple comparisons problem).
Family-Wise Error Rate (FWER) при m независимых тестах
Два основных подхода к коррекции:
Bonferroni (контроль FWER)
Порог значимости делится на количество тестов: α/m. Простой, но консервативный. При m=20: α_corrected = 0.0025.
Benjamini-Hochberg (контроль FDR)
Контролирует долю ложных среди отвергнутых (False Discovery Rate). Менее консервативен: порог для k-го p-value = k/m × α. Стандарт в индустрии.
Коррекция Бонферрони: делим α на число тестов m
Проблема peeking — ещё одна форма множественного тестирования. Если проверять результат каждый день, вероятность ложного срабатывания за неделю: 1 − (1−0.05)⁷ ≈ 30%. Решение — sequential testing или фиксированный срок эксперимента.
Реальный пример
Команда запустила тест с 5 вариантами кнопки. Один вариант показал p=0.04 по конверсии. «Ура, значимо!» Нет: с коррекцией Bonferroni порог 0.05/5 = 0.01. Без коррекции — 23% шанс найти хотя бы один «значимый» вариант, даже если все одинаковы.
Sequential Testing
Классический A/B тест требует фиксированного горизонта: собрать N наблюдений, затем один раз проверить гипотезу. Но на практике хочется подглядывать — может, эффект уже очевиден? Sequential testing решает эту проблему строго.
Идея: на каждом шаге t мы проверяем статистику, но используем скорректированные границы, которые гарантируют общий уровень α за весь эксперимент:
O'Brien-Fleming (OBF)
Границы отвержения очень широкие на ранних стадиях и сужаются к концу. Практически не расходует α в начале — финальная граница близка к обычному z-test. Самый популярный метод.
Pocock
Одинаковые границы на каждом шаге. Проще для понимания, но финальная граница строже обычного теста. Менее мощный чем OBF при фиксированном горизонте.
Always-Valid P-values (mSPRT)
Mixture Sequential Probability Ratio Test. P-value валиден в любой момент времени — можно проверять хоть каждую минуту. Используется в Optimizely, Eppo. Платим за это мощностью: нужно больше данных, чем в фиксированном тесте.
Граница O'Brien-Fleming на k-м из K промежуточных анализов
Пример: при 4 промежуточных анализах и α=0.05, границы OBF: 4.05, 2.86, 2.34, 2.02. На первом анализе нужен огромный эффект для остановки. К четвёртому — граница почти как обычный z-test (1.96).
Когда использовать sequential testing
(1) Тест дорогой — каждый день стоит денег (например, акция). (2) Этические причины — медицинские испытания, нельзя долго держать пациентов на плохом лечении. (3) Быстрые итерации — стартап с ограниченным трафиком, хочется быстрее принять решение.
Байесовский A/B тест
Frequentist подход отвечает на вопрос «Какова вероятность данных при H₀?» Байесовский подход отвечает на то, что мы реально хотим знать: «Какова вероятность, что B лучше A, учитывая данные?»
Теорема Байеса: posterior ∝ likelihood × prior
Для конверсий используется Beta-Binomial модель:
Prior: Beta(α₀, β₀)
Начальное представление о конверсии. Неинформативный prior: Beta(1, 1) = Uniform(0, 1). Слабоинформативный: Beta(2, 20) если ожидаем конверсию ~10%.
Likelihood: Binomial(n, p)
Данные эксперимента: s успехов из n попыток.
Posterior: Beta(α₀ + s, β₀ + n − s)
Обновлённое распределение. Сопряжённость Beta и Binomial даёт аналитическое решение — не нужен MCMC.
Вероятность что B лучше A — интеграл по posterior distributions
На практике этот интеграл вычисляется через Monte Carlo сэмплирование: генерируем N выборок из posterior A и B, считаем долю случаев, где sample_B > sample_A. Это и есть P(B > A).
| Frequentist | Bayesian | |
|---|---|---|
| Ответ | p-value < α → отвергаем H₀ | P(B лучше A) = 95% |
| Остановка | Фиксированный горизонт | Когда уверенность достаточна |
| Prior | Не используется | Явно задаётся |
| Интерпретация | P(data | H₀) | P(θ | data) |
Байесовский подход в индустрии
Google (Bayesian Optimization для ad auction), VK, Spotify используют байесовский A/B. Главное преимущество — natural stopping: не нужно заранее фиксировать horizon. Главный недостаток — зависимость от prior: при слабых данных prior доминирует. На практике при n > 1000 prior почти не влияет.
A/B тестирование в рекомендательных системах
Рекомендательные системы — одна из самых сложных областей для A/B тестирования. Здесь возникают уникальные проблемы, которых нет в классическом продуктовом A/B.
Spillover Effects (Network Effects)
Если рекомендации одному юзеру влияют на контент для других (inventory depletion, social sharing), SUTVA нарушается. Решение: кластерная рандомизация — делим по группам связанных пользователей или географии.
Position Bias
Позиция элемента в списке сильно влияет на CTR: первый элемент кликают в 5-10x чаще. При сравнении моделей нужно учитывать, что «лучшая» модель может просто ставить другой контент на первую позицию. Используйте position-debiased метрики.
Interleaving
Альтернатива A/B: две модели формируют рекомендации, которые объединяются в один interleaved список. Каждый клик атрибутируется модели-источнику. В 10-100x чувствительнее классического A/B, но измеряет только preference, не абсолютный эффект на бизнес-метрику.
Долгосрочные эффекты (Long-term Effects)
Рекомендации влияют на формирование привычек пользователя. Краткосрочный рост CTR может привести к filter bubble и снижению diversity. Используйте holdout-группы на месяцы и отслеживайте retention, diversity, exploration rate.
Схема эксперимента для RecSys: типичный пайплайн — offline evaluation (быстро, дёшево) → interleaving (чувствительно, дни) → полноценный A/B (бизнес-метрики, недели) → long-term holdout (retention, месяцы).
| Этап | Метод | Метрики | Сроки |
|---|---|---|---|
| 1 | Offline eval | NDCG, MAP, Coverage | Минуты |
| 2 | Interleaving | Win rate | Дни |
| 3 | A/B тест | CTR, revenue, time spent | 1-4 недели |
| 4 | Long-term holdout | Retention, LTV, diversity | 1-6 месяцев |
На собеседовании в рекомендации
«Как бы вы протестировали новую модель ранжирования?» — покажите знание всей цепочки: offline → interleaving → A/B → holdout. Упомяните spillover effects, position bias, novelty effect, выбор unit of randomization (user vs session). Бонус: CUPED для снижения дисперсии и ускорения теста.
Метрики в ML-продуктах
В ML-системах A/B тестирование имеет свои особенности: offline метрики модели (AUC, NDCG) могут не коррелировать с бизнес-метриками. Нужна связка offline → online.
| Offline | Online | |
|---|---|---|
| Что измеряем | Качество модели на тесте | Влияние на бизнес |
| Примеры | AUC, NDCG@K, BLEU | CTR, revenue, retention |
| Скорость | Минуты | Дни–недели |
| Риск | Нет (исторические данные) | Влияет на реальных юзеров |
Proxy-метрики — промежуточные метрики, которые быстрее реагируют на изменения. Например, вместо 30-day retention (долго ждать) используют session length или dwell time (видно за дни).
Interleaving для RecSys
Альтернатива классическому A/B для ранжирования: обе модели формируют рекомендации, которые объединяются в один interleaved список. Пользователь видит один список, но клики атрибутируются модели-источнику. Требует в 10-100x меньше трафика, но измеряет только preference, не абсолютный эффект на метрику.
Ловушка proxy-метрик
YouTube обнаружил, что оптимизация CTR приводит к clickbait. Переход на «satisfaction» метрики (время просмотра, likes, shares) улучшил долгосрочное качество. Proxy-метрика должна быть validated: подтверждено, что её рост → рост north star.
Продвинутые методы и типичные ошибки
Классический A/B тест с фиксированным горизонтом — не единственный подход. Вот современные альтернативы и частые ошибки:
Sequential Testing
Позволяет проверять результат на каждом шаге, не раздувая α. Используются spending functions (O'Brien-Fleming, Pocock) или always-valid p-values. Можно остановить тест раньше, если эффект большой.
Bayesian A/B Testing
Вместо p-value — posterior distribution эффекта. P(B лучше A | data) — интуитивно понятная метрика. Позволяет учесть prior knowledge и natural stopping: «остановим, когда уверенность > 95%».
CUPED (Controlled-Experiment Using Pre-Experiment Data)
Использует pre-experiment данные (метрика за прошлый период) как covariate для снижения дисперсии. Типичный результат: −30-50% дисперсии → можно быстрее завершить тест или детектировать меньший эффект.
Когда A/B тест НЕ нужен:
- Баг-фикс или юридическое требование — просто выкатываем
- Очевидно большой эффект (новая фича vs полное её отсутствие)
- Мало трафика — тест займёт месяцы, не оправдан
- Необратимые изменения (редизайн всего сайта) — лучше quasi-experiment
Типичные ошибки:
❌ Peeking
Проверка результатов каждый день и остановка «когда значимо». Раздувает α до 30-50%.
❌ Маленький MDE
«Хотим детектировать +0.01% конверсии» → нужен трафик масштаба Google. Нереалистичный MDE = бесполезный тест.
❌ SRM
Sample Ratio Mismatch: в группах не 50/50. Признак бага в рандомизации. Тест невалиден.
❌ Novelty effect
Новая версия показывает рост в первые дни просто потому что она новая. Ждите стабилизации 1-2 недели.
Чеклист перед запуском теста
(1) Гипотеза сформулирована. (2) Primary + guardrail метрики выбраны. (3) Sample size рассчитан. (4) AA-test пройден (проверка что рандомизация работает). (5) Длительность теста зафиксирована ДО старта. (6) Коррекция на множественные сравнения если тестируем несколько метрик/вариантов.
Загрузка интерактивного виджета...