Каждый раз, когда продуктовая команда спорит «давайте сделаем кнопку зелёной» или «вынесем форму наверх», по сути идёт спор о том, изменится ли поведение пользователей. A/B тест — это способ ответить на этот вопрос не мнением, а данными.
Проблема интуиции в продукте
Люди плохо предсказывают, что понравится другим людям. Даже опытные продакты и дизайнеры ошибаются в 60–70% случаев, когда прогнозируют результат изменения без данных. Это подтверждают внутренние исследования Microsoft, Google и Booking.com.
A/B тест решает простую проблему: вместо того, чтобы спорить о гипотезах, мы проверяем их на реальных пользователях и измеряем эффект. Но чтобы делать это правильно — нужно понять математику за процессом.
Прежде чем говорить об A/B тестах, нужно разобраться с тем, на чём они стоят: статистической проверкой гипотез. Это общий инструмент науки — A/B тест в продукте это его конкретное применение.
Нулевая и альтернативная гипотезы
В основе любого теста лежат две гипотезы. Нулевая гипотеза (H₀) — это позиция «ничего не изменилось, эффекта нет». Альтернативная гипотеза (H₁) — это то, что мы хотим доказать.
Ключевой момент: мы не доказываем H₁. Мы лишь пытаемся опровергнуть H₀. Это принципиально важно для понимания того, что означают результаты теста.
Идея: поменяем текст кнопки с «Оформить заказ» на «Купить сейчас»
H₀: конверсия в покупку одинакова в обеих группах (нет эффекта)
H₁: конверсия в покупку различается (есть эффект)
Тест позволит нам решить: достаточно ли данных, чтобы отвергнуть H₀ с разумным уровнем уверенности?
«Не отвергнуть H₀» ≠ «H₀ истинна». Если тест не нашёл эффекта, это может означать: а) эффекта нет, б) выборка была слишком маленькой, чтобы его увидеть. Разница критическая.
p-value: самая неправильно понимаемая концепция
p-value — это вероятность получить наблюдаемый результат (или более экстремальный) при условии, что нулевая гипотеза истинна. Звучит запутанно — разберём конкретно.
Вы подозреваете, что монета нечестная. Бросаете 10 раз — выпадает орёл 9 раз.
H₀: монета честная (вероятность орла = 0.5)
p-value: вероятность получить 9 или 10 орлов при честной монете ≈ 1%. Это очень мало — значит, либо нам невероятно повезло, либо монета всё-таки нечестная.
Мы отвергаем H₀ на уровне значимости 5% (потому что 1% < 5%).
Традиционно используют порог α = 0.05 (5%). Это значит: мы готовы ошибиться в 1 случае из 20, случайно «найдя» эффект там, где его нет.
❌ «p=0.03 значит вероятность что H₀ истинна — 3%» — неверно. p-value не говорит о вероятности гипотез.
❌ «p=0.05 значит эффект точно есть» — неверно. Это лишь означает, что мы решаем отвергнуть H₀ при принятом пороге.
❌ «p=0.06 значит результат незначим и эффекта нет» — неверно. Граница 0.05 условна. Разница между p=0.049 и p=0.051 статистически несущественна.
✅ Правильно: p-value — это степень несовместимости наблюдаемых данных с нулевой гипотезой. Чем меньше — тем меньше шанс, что мы видим случайный шум.
Ошибки I и II рода: ложные тревоги и пропущенные сигналы
Когда мы принимаем решение по тесту, мы можем ошибиться двумя способами. Важно понимать оба, потому что они находятся в постоянном противоречии.
Правильно не внедрили
Пропустили реальное улучшение
Внедрили бесполезное изменение
Правильно внедрили
Ошибка I рода (α) — ложноположительный результат. Мы решили, что эффект есть, а его нет. Уровень значимости α = 0.05 означает, что мы допускаем такую ошибку в 5% случаев. Это «ложная тревога».
Ошибка II рода (β) — ложноотрицательный результат. Эффект реально есть, но мы его не увидели — слишком маленькая выборка или слабый эффект. Типичное значение: β = 0.20 (20%).
H₀: лекарство не работает. H₁: лекарство работает.
Ошибка I рода: решили что лекарство работает, а оно не работает → внедрили бесполезное лекарство.
Ошибка II рода: решили что лекарство не работает, а оно работает → отказались от хорошего лекарства.
В зависимости от цены каждой ошибки выбирают разные значения α. В A/B тестах продукта α=0.05, β=0.20 — стандарт индустрии.
Мощность теста: способность найти эффект, если он есть
Мощность (power) = 1 - β. Это вероятность обнаружить эффект, если он реально существует. Стандарт: мощность ≥ 80% (β ≤ 0.20).
На мощность влияют три вещи: размер выборки, величина эффекта (MDE), и дисперсия данных. Именно поэтому расчёт выборки — обязательный шаг перед запуском.
Мощность теста — это как острота зрения. Если вы в очках (большая выборка, чистые данные) — увидите маленькую букву (слабый эффект). Без очков (маленькая выборка) — увидите только крупные буквы (сильные эффекты).
Механика: две группы, одна разница
A/B тест — это контролируемый эксперимент. Мы случайным образом делим пользователей на две группы: контрольную (A) и экспериментальную (B). Группа A видит старую версию, группа B — новую. Всё остальное — одинаково.
Ключевое слово — случайным образом. Рандомизация гарантирует, что группы в среднем похожи по всем характеристикам (возраст, платформа, частота визитов). Без неё мы не можем утверждать, что разница в метриках вызвана именно изменением.
Как происходит рандомизация на практике: обычно хешируют user_id или device_id и делят на N бакетов. Пользователь с четным хешем → группа A, нечётным → группа B. Это гарантирует: один пользователь всегда видит одну версию.
Выбор метрик: что именно мерить
Метрика — это сердце A/B теста. Неправильно выбранная метрика сделает весь тест бессмысленным, даже если статистика безупречна. Используют три типа метрик одновременно.
Primary: доля пользователей, завершивших онбординг (activation rate)
Secondary: время прохождения онбординга, число кликов, drop-off по шагам
Guardrail: Day-7 retention не должен упасть — онбординг не должен обещать то, чего нет в продукте
Пошаговый процесс проведения теста
Расчёт размера выборки: главный шаг перед запуском
Размер выборки определяет, сколько пользователей нужно набрать в каждую группу, чтобы тест мог обнаружить эффект нужной величины с заданной надёжностью.
Чем меньший эффект вы хотите обнаружить — тем больше нужна выборка. Хотите поймать изменение конверсии с 5.0% до 5.1% (+2%)? Нужно ~100 000 пользователей в группу. Хотите поймать изменение с 5% до 6% (+20%)? Хватит ~5 000.
Практический вывод: устанавливайте MDE исходя из того, при каком минимальном эффекте внедрение оправдано бизнесом. Если изменение не окупается при росте ниже 10% — ставьте MDE = 10%.
Какой статистический тест использовать
Выбор теста зависит от типа метрики. Вот шпаргалка для основных случаев:
| Тип метрики | Примеры | Тест | Когда использовать |
|---|---|---|---|
| Пропорция | Конверсия, CTR, Retention | Z-тест | Большие выборки (n > 1000), нормальное приближение работает |
| Среднее (норм.) | Session length, время отклика | t-тест Стьюдента | Данные близки к нормальному распределению |
| Среднее (скошен.) | Revenue, LTV, чек | Mann-Whitney или Bootstrap | Тяжёлые хвосты, выбросы (большие покупки). t-тест ненадёжен |
| Ratio-метрика | ARPU = revenue/users, CTR = clicks/shows | Delta-метод | Числитель и знаменатель — разные случайные величины |
| Категориальная | Тип девайса, категория | Chi-square | Сравнение частотных распределений |
AA-тест: как проверить, что всё настроено правильно
AA-тест — это A/B тест, в котором обе группы видят одинаковую версию продукта. Никаких изменений нет. Цель — убедиться в том, что система рандомизации работает корректно.
Логика: если группы действительно равнозначны, статтест при AA должен давать p-value, равномерно распределённый от 0 до 1. Если вы регулярно видите p < 0.05 на AA тестах — в системе есть сбой.
🔧 Систематическое смещение — один сегмент пользователей всегда попадает в одну группу (например, iOS → контроль, Android → тест).
🔧 Утечку трафика (SRM) — Sample Ratio Mismatch: в группах не 50/50, а, например, 52/48. Это признак проблемы в рандомизации.
🔧 Плохую изоляцию — пользователи «перетекают» между группами (очистили куки, сменили устройство).
Основная проблема A/B тестов в бизнесе — нужно слишком много пользователей и слишком много времени. Следующие методы позволяют обнаружить тот же эффект при меньшей выборке, «убирая» лишний шум из данных.
CUPED: убираем шум с помощью предэкспериментальных данных
CUPED — Controlled-experiment Using Pre-Experiment Data. Метод из Microsoft Research (2013), сейчас стандарт в Яндексе, Авито, Booking.com.
Идея проста: большая часть дисперсии в метрике объясняется тем, каким пользователь был до эксперимента. Активный пользователь останется активным, неактивный — неактивным. Если мы «вычтем» эту предсказуемую часть, оставшийся сигнал будет намного чище.
В задачах с хорошей корреляцией (доход пользователя неделя к неделе, ρ ≈ 0.7–0.8) CUPED позволяет сократить нужную выборку вдвое при той же мощности. Это означает, что тест, который раньше шёл 4 недели, теперь идёт 2.
Стратификация: контролируем состав групп
Рандомизация в среднем даёт похожие группы, но при малых выборках группы могут случайно оказаться несбалансированными — например, в группе B окажется больше новых пользователей, которые хуже конвертируются.
Стратификация решает это: мы делим пользователей на страты (сегменты) и рандомизируем внутри каждой страты. Это гарантирует, что соотношение сегментов в группах будет одинаковым.
Страты: платформа (iOS / Android / Web), тип пользователя (новый / вернувшийся / активный).
Без стратификации: случайно в тестовую группу попало 60% новых пользователей, в контроль — только 40%. Результат теста смешан с эффектом новизны.
Со стратификацией: и в контроле, и в тесте ровно 45% новых пользователей. Группы сопоставимы по составу.
Стратификация — это «страховка» рандомизации. Особенно важна при небольших выборках (< 10 000 пользователей) и когда метрика сильно зависит от сегмента.
Bootstrap: статтест без предположений о распределении
Классические тесты (t-тест, z-тест) предполагают, что данные нормально распределены или что выборка достаточно большая (ЦПТ). Но метрики вроде дохода, LTV, среднего чека — с тяжёлыми хвостами и выбросами. Здесь t-тест ненадёжен.
Bootstrap — непараметрический метод. Мы многократно «переиспользуем» данные, каждый раз случайно сэмплируя из них, и строим эмпирическое распределение статистики.
- Метрика с тяжёлыми хвостами (доход, чек)
- Нестандартные метрики (медиана, перцентили)
- Малые выборки, ЦПТ не применима
- Нужен точный доверительный интервал
- Вычислительно дороже (10 000 итераций)
- Медленнее при огромных выборках
- Требует корректной реализации
Peeking problem: нельзя смотреть на результаты до конца теста
Самая распространённая ошибка в A/B тестировании. Peeking — это когда вы смотрите на промежуточные результаты и останавливаете тест, как только увидели p < 0.05.
Проблема в том, что p-value в процессе теста случайно болтается туда-сюда. При случайных данных (без реального эффекта) p-value рано или поздно случайно опустится ниже 0.05 — и если вы остановите тест в этот момент, вы совершите ошибку I рода.
Симуляции показывают: если смотреть на результаты каждый день и останавливать тест при p<0.05, реальный уровень ложных срабатываний может достигать 30% вместо заявленных 5%. Шесть из двадцати «открытий» окажутся случайностью.
Решения:
1. Фиксированный горизонт: считаете нужную выборку заранее, запускаете, смотрите результат ровно один раз в конце. Это классический подход.
2. Sequential testing (mSPRT): математически корректный способ смотреть на тест в любой момент. Использует always-valid p-values. Применяется в Spotify, Yandex.
Novelty effect: пользователи реагируют на новизну, а не на изменение
Когда вы меняете что-то в интерфейсе, часть пользователей взаимодействует с новым элементом просто потому что он новый. Этот эффект временный: через 2–3 недели поведение возвращается к норме.
Вы добавили новый раздел «Рекомендации» в навигацию. В первую неделю его CTR — 15%. Через месяц — 3%. Тест, проведённый только первую неделю, показал бы «значимый» эффект, который в реальности не устойчив.
Обратный случай (Novelty suppression): постоянные пользователи избегают нового элемента, потому что привыкли к старому. Эффект кажется нулевым или отрицательным, но на новых пользователях он положительный.
Решение: разделяйте анализ по сегментам — новые пользователи vs вернувшиеся vs очень активные. Эффект у новых пользователей (у которых нет привычки) — более надёжный сигнал. Для очень активных пользователей прогоняйте тест дольше — 2–4 недели.
Network effects: пользователи влияют друг на друга
Классический A/B тест предполагает независимость пользователей: то, что видит пользователь A, не влияет на пользователя B. Но в социальных сетях, маркетплейсах и двусторонних платформах это не так.
👥 Соцсети: если пользователи группы B видят новый формат постов и начинают постить больше — это влияет на пользователей группы A (их лента тоже меняется). Контроль и тест «заражают» друг друга.
🛒 Маркетплейсы: продавец попадает в тест с новым ранжированием → его товары видят покупатели из контроля. SUTVA нарушен — изменение цены или ранга влияет на весь рынок, а не только на тестовую группу.
🚗 Uber/Яндекс.Такси: если водителям в группе B показывать другие стимулы, они могут «перетечь» в зоны, где больше пассажиров из группы A — и тест загрязнён.
Решение для маркетплейсов — Switchback experiments: вместо разделения по пользователям, тест разделяется по времени или гео-зонам. Одна гео-зона в чётные часы видит версию A, в нечётные — версию B. Пользователи внутри зоны всегда в одной группе.
Для соцсетей — Ego network / Cluster-based randomization: рандомизируем не пользователей, а кластеры социального графа. Все друзья попадают в одну группу — интерференция минимальна.
Другие типичные ошибки
| Ошибка | Что происходит | Как избежать |
|---|---|---|
| Multiple testing | Тестируете сразу 20 метрик → одна случайно окажется значимой (5% × 20 ≈ 1 ложная тревога) | Одна primary метрика. Поправка Бонферрони для вторичных: α/n |
| Слишком короткий тест | Не учтена недельная сезонность: пользователи по будням и выходным разные | Минимум 1 полная неделя. Лучше 2–4. Проверяйте по дням недели |
| Post-hoc сегментация | Результат незначим → ищете «выигрывающий» сегмент. Это p-hacking | Сегментация планируется ДО теста и прописывается в протоколе |
| Survivor bias | Анализируете только пользователей, которые остались активны. Ушедшие игнорируются | Анализируйте всех пользователей, попавших в тест с момента старта |
| Изменение теста на ходу | Меняете версию B в процессе теста → данные несравнимы | Зафиксируйте версию перед запуском. Любые изменения = новый тест |
| HARKing | Hypothesis After Results Known: формулируете гипотезу под уже полученный результат | Пре-регистрируйте гипотезу и метрику до запуска теста |
A/B тест — мощный инструмент, но не для каждой ситуации. Вот три случая, когда нужно другое решение.
Multi-Armed Bandit: когда важно минимизировать потери
Классический A/B тест «тратит» 50% трафика на явно проигрывающий вариант до самого конца. Multi-Armed Bandit (MAB) адаптируется: направляет больше трафика на лучшую версию по мере накопления данных.
Алгоритмы: ε-greedy, Thompson Sampling, UCB. Используется там, где каждый «неоптимальный» показ стоит денег: рекламные баннеры, ценообразование, email-рассылки.
Минус: сложнее интерпретировать, не подходит для долгосрочных метрик (retention, LTV), адаптация «загрязняет» данные для классического анализа.
Quasi-experiments: когда нельзя рандомизировать
Иногда рандомизация невозможна: функция выкатывается на всех сразу, или нельзя дать разным пользователям разные цены. Для таких случаев есть методы причинно-следственного вывода без рандомизации.
Difference-in-differences (DiD): сравниваем изменение в группе до/после с изменением в контрольной группе, которую не затронуло изменение. Используется для оценки влияния маркетинговых акций и фичей, выкатываемых по регионам.
Regression Discontinuity Design (RDD): используем «пороговые» правила — например, скидка только тем, кто зарегистрировался до определённой даты. Пользователи прямо около порога — почти случайно разделены.
Causal Impact (Google): байесовский подход на основе временных рядов — строим прогноз что было бы без изменения, и сравниваем с реальностью.
Holdout groups и долгосрочные эффекты
Обычный A/B тест длится 2–4 недели и измеряет краткосрочный эффект. Но что если изменение влияет на retention через 3 месяца? Или на LTV через год?
Holdout group — это постоянная контрольная группа (обычно 5–10% пользователей), которая не получает никаких новых фич. Сравнивая их с остальными через 3–6 месяцев, можно оценить кумулятивный эффект от всех изменений.
Практикуют LinkedIn, Netflix, Airbnb. Требует дисциплины — holdout нельзя «загрязнять» промежуточными тестами.
Чек-лист перед запуском A/B теста
Главное, что нужно запомнить
A/B тест — это не кнопка «запустить и посмотреть». Это строгий научный процесс. Большинство ошибок совершается не в анализе данных, а до старта теста.
- Сначала гипотеза с механизмом, потом запуск. Никогда наоборот.
- Рассчитывайте выборку до старта. Тест без расчёта — игра в угадайку.
- Не смотрите на промежуточные результаты для принятия решений.
- Нет эффекта — это тоже результат. Запишите и двигайтесь дальше.
- CUPED и стратификация дают те же результаты быстрее. Это не магия — это математика.
- Если метрика сложная (доход, LTV) — используйте bootstrap, не t-тест.
- Понимайте, когда A/B тест не применим: сети, маркетплейсы, мало трафика.
За рамками этого гайда остались: байесовский подход к A/B тестированию, sequential testing (mSPRT, always-valid confidence intervals), interleaving для ранжирования, долгосрочные holdout-эксперименты и платформы для экспериментов (Statsig, GrowthBook, Eppo). Эти темы — для следующего уровня после освоения основ.