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

Красная кнопка или синяя? Короткая форма или подробная? Новый экран действительно помогает пользователю — или просто нравится команде? На такие вопросы опасно отвечать голосованием в рабочем чате. Мнения звучат убедительно, но поведение аудитории часто ломает самые стройные рассуждения.
A/B-тестирование позволяет проверить изменение на реальных пользователях. Одни продолжают видеть текущую версию продукта, другие получают экспериментальную. Затем команда сравнивает заранее выбранные показатели и решает, стоит ли внедрять новинку для всех.
Метод применяют не только на лендингах. С его помощью проверяют заголовки писем, порядок шагов онбординга, алгоритмы рекомендаций, цены, рекламные объявления и даже сценарии работы службы поддержки. Главное — корректно организовать эксперимент и не объявить победителя после первого удачного дня.
Зачем проводить A/B-тест
Представим интернет-магазин, который хочет добавить всплывающее окно со скидкой за подписку. Маркетолог ожидает больше email-адресов. Дизайнер боится, что окно будет раздражать посетителей. Руководитель уверен: конкуренты используют такой приём, значит он работает.
Каждая позиция логична, но ни одна не доказывает результат. После запуска подписок действительно может стать больше, а покупок — меньше. Или окно хорошо сработает на мобильных устройствах и ухудшит опыт на компьютерах. A/B-тест превращает спор во измеримую гипотезу: «Если показать предложение после просмотра двух товаров, доля подписок вырастет, а конверсия в покупку не снизится».
Хорошая гипотеза содержит изменение, аудиторию, ожидаемый эффект и защитную метрику. Последняя не даёт улучшить один показатель ценой другого.

Как устроен эксперимент
Аудиторию случайно делят минимум на две группы. Группа A видит действующую версию — это контроль. Группа B сталкивается с одним изменением — это эксперимент. Если одновременно поменять заголовок, форму, цену и навигацию, определить причину результата будет невозможно.
Один пользователь должен оставаться в одной группе на протяжении всего теста. Иначе сегодня человек увидит старый интерфейс, завтра новый, а его действия попадут в обе выборки. На веб-сайте принадлежность к варианту часто сохраняют в cookie или связывают с идентификатором аккаунта.
Группы измеряют параллельно. Сравнивать новую версию на этой неделе со старой на прошлой рискованно: результат могли изменить выходные, рекламная кампания, сезонный спрос или сбой оплаты. Одновременный запуск распределяет внешние события между вариантами.
Нужно исключить и внутренний шум. Сотрудники тестируют сайт, операторы по-разному обрабатывают обращения, редакция выпускает крупный материал, разработчики исправляют ошибку в середине эксперимента. Такие события фиксируют, служебный трафик фильтруют, а важные изменения не накладывают друг на друга.
Группы необязательно должны быть одинаковыми по размеру. Рискованную функцию разумно сначала показать 5–10% аудитории. Если технические и продуктовые показатели остаются стабильными, долю можно увеличить. Поэтому сравнивают относительные метрики: конверсию, выручку на посетителя, кликабельность или среднее число действий, а не просто количество покупок и кликов.
Какие показатели выбрать
Метрика должна соответствовать цели гипотезы. Если меняется форма регистрации, основной показатель — доля успешно завершивших регистрацию. Для нового блока рекомендаций подойдут кликабельность и последующая покупка. Для поиска — доля успешных сессий, повторные запросы и время до нужного результата.
Популярные группы показателей:
- конверсионные: регистрация, заявка, подписка, покупка, переход к следующему шагу;
- экономические: средний чек, выручка или маржа на пользователя, стоимость заказа;
- поведенческие: глубина просмотра, длительность сессии, возвраты, отказы;
- защитные: ошибки, отмены, обращения в поддержку, скорость загрузки и отток.
Одной цифры часто недостаточно. Допустим, упрощённая карточка товара повышает конверсию, но уменьшает средний чек. Итоговая выручка на посетителя при этом может как вырасти, так и упасть. Заранее назначьте одну основную метрику, несколько диагностических и защитные ограничения. Не выбирайте победителя по тому показателю, который случайно оказался красивее после запуска.
Если вам близка работа на стыке процессов, данных и решений, посмотрите материал о том, чем занимается бизнес-аналитик: умение переводить расплывчатый запрос в проверяемые требования пригодится и при проектировании экспериментов.
Почему разницы средних недостаточно
Допустим, конверсия варианта A составила 10%, а варианта B — 11%. Можно ли считать рост доказанным? Пока нет. Разница могла появиться случайно, особенно если в каждой группе было по сто посетителей.
Любая метрика колеблется. В понедельник средний чек один, в пятницу другой. Даже две одинаковые версии при случайном разделении аудитории покажут немного разные результаты. Поэтому аналитик оценивает не только среднее значение, но и размер выборки, разброс данных и степень перекрытия распределений.

Представьте два холма. Каждый показывает, как часто встречаются значения метрики в своей группе. Если холмы почти полностью накладываются друг на друга, наблюдаемая разница может быть шумом. Чем меньше пересечение относительно эффекта, тем увереннее вывод.
Статистическая значимость отвечает на вопрос: насколько результат совместим со случайностью при условии, что реального эффекта нет. Часто используют порог 95%, но он не превращает вывод в абсолютную истину. Возможны ложноположительные и ложноотрицательные решения. Кроме того, статистически заметный эффект может быть слишком мал, чтобы окупить разработку.
Не останавливайте тест при первом пересечении желаемого порога. Если каждый час смотреть на данные и завершить эксперимент в удачный момент, вероятность ошибки растёт. До запуска определите минимальный полезный эффект, требуемую выборку и длительность, учитывающую полный деловой цикл — обычно хотя бы одну-две недели для ежедневного продукта.
Как проверить значимость
Сначала формулируют две гипотезы. Нулевая утверждает, что существенной разницы между вариантами нет. Альтернативная — что изменение влияет на выбранную метрику. Статистический тест оценивает, достаточно ли данных, чтобы отвергнуть нулевую гипотезу.
Метод зависит от типа показателя. Для конверсии, где пользователь либо совершил действие, либо нет, применяют тесты для долей. Для среднего чека, времени сессии и других числовых величин могут подойти t-тест, непараметрические методы или бутстрэп. Выбор зависит от распределения, объёма данных и устройства эксперимента.
На практике не обязательно считать всё вручную. Платформы экспериментов и статистические калькуляторы покажут интервал неопределённости и вероятность ошибки. Но сервис не исправит неверную метрику, пересечение аудиторий или подглядывание за результатом. Инструмент считает числа; качество дизайна теста остаётся ответственностью команды.
Пошаговый сценарий A/B-теста
- Найдите проблему по аналитике, исследованиям или обращениям пользователей.
- Запишите гипотезу в формате «изменение — аудитория — эффект — метрика».
- Выберите основную, диагностические и защитные метрики.
- Оцените минимальный полезный эффект, размер выборки и срок теста.
- Случайно распределите пользователей и закрепите их за вариантами.
- Проверьте корректность событий аналитики до запуска.
- Ведите эксперимент параллельно и не меняйте условия посередине.
- После набора выборки оцените значимость и практическую ценность.
- Зафиксируйте вывод, включая неудачный или нейтральный результат.
Последний пункт часто пропускают. Команда запоминает победы, повторяет проигравшие идеи и теряет контекст решений. Нулевой результат тоже полезен: он показывает, что конкретное изменение в данных условиях не дало ожидаемого эффекта.
Вымышленный пример: команда сервиса управления проектами заметила, что новые пользователи редко создают вторую задачу. Гипотеза предполагала, что готовый шаблон проекта ускорит первый результат. Половине аудитории оставили пустой экран, второй половине показали шаблон. Создание второй задачи выросло на 14%, но приглашения коллег не изменились. Команда внедрила шаблон и отдельно запланировала эксперимент с совместной работой. Один тест дал конкретный ответ, а не попытался решить весь онбординг сразу.
Хотите проводить эксперименты системно, а не хранить гипотезы в чатах? Попробуйте Nubl бесплатно: создайте доску тестов, фиксируйте варианты, метрики, ответственных и результаты, чтобы каждое следующее решение опиралось на накопленные данные.





