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% шанс найти хотя бы один «значимый» вариант, даже если все одинаковы.
Метрики в 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) Коррекция на множественные сравнения если тестируем несколько метрик/вариантов.
Загрузка интерактивного виджета...