A/B-тестирование: как правильно настроить эксперименты на сайте

A/B-тестирование — способ принимать решения на основе данных, а не на основе мнения самого громкого человека в комнате. Тест отвечает на вопрос «работает ли изменение?» цифрами, а не догадками. Но за внешней простотой метода скрывается набор статистических подводных камней: маленькая выборка, преждевременная остановка, игнорирование сезонности — каждая ошибка приводит к решениям, противоположным правильным.

В этой статье — практическое руководство по A/B-тестированию: гипотезы, размер выборки, статистическая значимость, ошибки I и II рода, обзор сплит-систем для русскоязычного рынка в 2026 году и список ошибок, которые обнуляют результаты эксперимента.

Что такое A/B-тест и для чего он нужен

A/B-тест — эксперимент, в котором две (или больше) версии чего-либо сравниваются на статистически одинаковых аудиториях. Половина пользователей видит вариант A (контрольный), половина — вариант B (тестовый). Через определённое время сравниваются ключевые метрики: какая версия даёт больше конверсий, выше средний чек, дольше время на сайте.

Метод пришёл в digital из фармакологии, где случайные контролируемые испытания — золотой стандарт доказательной медицины. Логика та же: пока сравнение не контролируется (не на одинаковых группах, не за один период), любые различия можно объяснить случайностью.

Применяется A/B-тестирование почти везде, где есть пользовательский трафик и измеримые действия: тестирование заголовков лендингов, цветов и текстов кнопок, дизайна форм, ценовых стратегий, алгоритмов рекомендаций, формулировок email-рассылок, последовательности экранов в мобильных приложениях.

Гипотеза, метрики, варианты

Грамотный тест начинается не с того, «что бы такое потестить», а с трёх элементов: гипотезы, метрики, варианта.

Гипотеза

Формулируется по шаблону: «Если мы изменим [что-то], то [метрика] изменится на [сколько] из-за [причины]». Без чёткой гипотезы любой результат теста можно интерпретировать как угодно.

Пример хорошей гипотезы: «Если мы заменим текст кнопки с „Купить“ на „Заказать со скидкой 10%“, конверсия в покупку вырастет на 15%, потому что слово „скидка“ снижает воспринимаемый риск.»

Пример плохой гипотезы: «Давайте сделаем кнопку красной и посмотрим». Без причинно-следственной связи и ожидаемого эффекта тест превращается в случайный поиск.

Метрика

Главная метрика теста определяется заранее. Менять её по ходу эксперимента — манипуляция, ведущая к ложным выводам. Метрика должна быть:

• Измеримой автоматически. Не «качество восприятия», а конверсия, выручка, время.
• Чувствительной. Реагирующей на изменение в тесте.
• Бизнес-релевантной. Связанной с реальной целью бизнеса.

Часто помимо главной метрики отслеживают вторичные (для контроля побочных эффектов): если новый призыв повышает клик, но снижает покупки, это не победа.

Варианты

Минимум — два: контрольный (как было) и тестовый (изменение). Иногда — больше: A/B/C/D-тесты позволяют сравнить несколько вариантов одновременно, но требуют пропорционально большей выборки.

Статистическая значимость и доверительные интервалы

Если на сайт пришло 100 человек, 5 из контрольной группы купили и 8 из тестовой — нельзя сразу заявлять «вариант B лучше на 60%». Разница может быть случайной.

Статистическая значимость — мера уверенности в том, что наблюдаемая разница — не случайность. Стандартный порог в маркетинге: p-value < 0.05, что означает «вероятность случайной разницы меньше 5%».

Доверительный интервал (confidence interval) — диапазон, в котором с заданной вероятностью лежит истинное значение метрики. Если конверсия в варианте B = 8% с доверительным интервалом [6.5%; 9.5%], это значит: с вероятностью 95% истинная конверсия лежит между 6.5% и 9.5%.

Уровень значимости

Стандарт — 95% (p < 0.05). Для критичных решений можно повышать до 99% (p < 0.01). Для исследовательских — снижать до 90% (p < 0.1), но с пониманием рисков.

Power (мощность теста)

Способность теста обнаружить реально существующий эффект. Стандарт — 80%. Низкая мощность означает, что даже работающие изменения могут быть упущены — результат теста окажется «нет разницы», хотя на самом деле она есть.

Размер выборки: сколько нужно

Главная ошибка начинающих — запуск теста на 100–200 пользователях с ожиданием значимых результатов. На малых выборках почти любое колебание выглядит как «разница», но статистически она недостоверна.

Размер выборки зависит от трёх параметров:

• Базовая конверсия — текущий уровень метрики
• Минимальный обнаруживаемый эффект (MDE) — какую разницу хотим обнаружить
• Уровень значимости и мощности — обычно 95% и 80%

Примерные требования к выборке:

Числа — на каждый вариант теста. Для A/B-теста с базовой конверсией 2% и MDE 10% нужно суммарно 38 000 пользователей (по 19 000 на вариант).

Калькуляторы выборки доступны бесплатно: Optimizely Sample Size Calculator, Evan Miller’s tool, calculator на сайтах VWO и AB Tasty. Все они используют один и тот же статистический аппарат.

Ошибки I и II рода

Два типа возможных ошибок в выводах A/B-теста.

Уровень значимости 95% означает 5% риска ошибки I рода. Мощность 80% означает 20% риска ошибки II рода. Эти числа — компромисс: повышение значимости снижает риск ошибки I, но требует больше выборки или повышает риск ошибки II.

Бизнес-следствия различны. В критичных решениях (изменение основной формы оплаты) дороже ошибка I рода — лучше пропустить хорошую идею, чем внедрить плохую. В исследовательских (тестирование контентных решений) дороже ошибка II — лучше ложно сработавший тест, чем пропущенная инсайтная гипотеза.

Этапы проведения теста

1. Формулировка гипотезы. Что меняем, какую метрику хотим сдвинуть, почему ожидаем эффект.
2. Расчёт выборки. Сколько пользователей нужно для достоверных выводов.
3. Оценка сроков. При текущем трафике — через сколько дней наберём нужную выборку.
4. Подготовка вариантов. Реализация изменений в системе сплит-тестирования.
5. QA-проверка. Контрольный и тестовый варианты работают корректно, метрика считается правильно.
6. Запуск. Включение распределения трафика 50/50.
7. Мониторинг. Контроль технической работоспособности теста — без анализа результатов до завершения.
8. Завершение. Когда выборка достигнута, считаем результаты.
9. Анализ. Главная метрика, побочные эффекты, сегменты пользователей.
10. Решение. Внедрить, откатить или провести дополнительный тест.

Полный цикл занимает от двух недель до нескольких месяцев в зависимости от трафика и MDE. Попытка ускорить любой шаг — короткий путь к недостоверным результатам.

A/B vs A/B/n vs мульти-вариант

Базовый формат — A/B: два варианта, 50/50 трафика. Развитие — A/B/n: больше двух вариантов с равным распределением. Мульти-вариант тестирует разные сочетания нескольких элементов одновременно.

Bandit-алгоритмы (Multi-Armed Bandit) — современный подход, когда система постепенно увеличивает долю лучшего варианта по мере накопления данных. Используется в Google Ads, Яндекс Директе для оптимизации ставок и в продвинутых сплит-системах.

Обзор сплит-систем 2026

Google Optimize, бывший лидер бесплатных решений, был закрыт в сентябре 2023 года. С тех пор рынок инструментов A/B-тестирования перестроился.

Для малого бизнеса — Яндекс Эксперименты или Mida. Для среднего — VWO или Convert. Для крупного — Optimizely, AB Tasty или собственная сборка на open-source.

На чём тестировать

Не каждое изменение стоит тестирования. Тестируется то, что обещает значимый эффект и оправдывает затраты на эксперимент.

Часто тестируемые элементы

• Заголовки лендингов. Меняют конверсию на 5–25%.
• CTA-кнопки. Текст, цвет, размер, расположение.
• Формы. Количество полей, последовательность, формулировка.
• Цены и ценовые стратегии. Различные тарифы, фреймы (от 99 vs 100), пакетные предложения.
• Главное изображение. Особенно для e-commerce и SaaS-лендингов.
• Социальные доказательства. Отзывы, кейсы, число клиентов.
• Email-рассылки. Темы, прехедеры, время отправки.
• Алгоритмы рекомендаций. Разные модели, разные принципы сортировки.
• Push-уведомления. Тексты, частота, время.

Что не нужно тестировать

• Мелкие визуальные изменения (отступы, оттенки) — нужна огромная выборка для измеримого эффекта.
• Очевидные технические улучшения (исправление багов).
• Изменения, противоречащие закону или ГОСТу (нет смысла тестировать «работает ли без обязательной информации»).
• Решения, по которым невозможно «откатиться» (например, изменение названия бренда).

Типичные ошибки

• Малая выборка. Запуск теста на 200 пользователях с ожиданием значимых результатов — самая частая ошибка.
• Peeking (подглядывание). Анализ результатов до окончания запланированной выборки. Каждая «промежуточная проверка» с принятием решения увеличивает риск ошибки I рода.
• Разные сегменты в группах. Если в группу A случайно попало больше пользователей из платных каналов, а в B — больше органических, разница может объясняться сегментацией, а не самим изменением.
• Изменение метрики по ходу теста. Тестировали конверсию, на третий день увидели большой рост среднего чека — отчитались по нему. Это p-hacking, искусственное натягивание значимости.
• Тестирование во время аномалий. Чёрная пятница, новогодние праздники, крупная акция — поведение пользователей в эти периоды не репрезентативно.
• Одновременные конфликтующие тесты. Два теста, влияющие на одну и ту же метрику, дают непредсказуемые взаимодействия. Без координации тестов результат каждого недостоверен.
• Игнорирование long-term эффектов. Кликбейтный заголовок может повысить кратко конверсию, но снизить долгосрочный retention. Тест нужно продолжать достаточно долго, чтобы увидеть эти эффекты.
• Запуск без QA. Тестовая версия работает с багом, который никто не заметил — результаты теста бессмысленны.
• Survivorship bias. Учёт только тех пользователей, кто дошёл до целевого действия. Если изменение увеличивает отвал на ранних шагах, итоговая конверсия выглядит лучше, но абсолютные числа хуже.
• Слепое следование за результатом. Тест показал, что красная кнопка лучше зелёной. Внедрили во всех точках сайта без проверки. Через месяц общая конверсия упала: красный конфликтует с брендингом, доверие снизилось.

Гайдлайны по длительности

Помимо математически рассчитанной выборки, есть практические правила минимальной длительности.

• Минимум одна неделя. Чтобы захватить недельный цикл поведения (рабочие дни, выходные).
• Минимум два полных недельных цикла. Если в нише сильная недельная сезонность.
• Максимум 4–6 недель. Дальше внешние факторы (новости, тренды, сезонность) начинают сильнее влиять на результаты, чем сам тест.
• Для долгосрочных эффектов — отдельный тест. Краткосрочные результаты ограничены 4 неделями, долгосрочные требуют сегментации когорт на 3+ месяцев.

Часто задаваемые вопросы

Сколько пользователей нужно для значимых результатов?

Зависит от базовой конверсии и MDE. Для типичной конверсии 2% и MDE 10% — около 38 000 пользователей. Точный расчёт через калькуляторы выборки.

Можно ли остановить тест досрочно при явном победителе?

Нет, если использовалась классическая частотная статистика. Преждевременная остановка повышает риск ошибки I рода. Для досрочных решений используются sequential testing или Bayesian-методы.

Что делать, если тест показал «нет разницы»?

Анализировать сегменты — возможно, эффект есть в одной группе. Проверять побочные метрики. Если действительно разницы нет — изменение не работает, переходить к следующей гипотезе.

Как тестировать на низком трафике?

Использовать большие MDE (искать только сильные эффекты), тестировать ярко различающиеся варианты, использовать sequential testing для адаптивных решений. Для критичного выбора при низком трафике лучше провести качественное исследование, чем A/B-тест на недостаточной выборке.

Стоит ли тестировать всё подряд?

Нет. Каждый тест стоит ресурсов — времени на подготовку, недель в эксперименте, упущенных альтернатив. Приоритизируйте по ожидаемому эффекту: тестируйте изменения, которые могут дать 10%+ изменения метрики, а не 0.5%.

Что важнее — статистическая значимость или практическая?

Статистическая значимость говорит, что эффект реален. Практическая — что он достаточно велик, чтобы оправдать внедрение. Тест может быть статистически значимым (p < 0.05), но показывать прирост 0.3% — внедрение часто не окупает усилий по сопровождению изменения.

Заключение

A/B-тестирование — не магия, а статистический инструмент со своими правилами и ограничениями. Команды, которые соблюдают методологию, накапливают за год десятки достоверных инсайтов о пользователях и продукте. Команды, которые «тестируют по чуйке» на недостаточных выборках с подглядыванием, получают набор противоречивых выводов, которые в итоге выкидывают и возвращаются к решениям по мнению самого опытного сотрудника. Базовая дисциплина — расчёт выборки до запуска, защищённая метрика, выдержка до конца теста — стоит на порядок дешевле, чем последствия внедрения «победивших» изменений, которые на самом деле случайны.