A/B-тесты: как проверять гипотезы и не делать выводов на ложной статистике

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

Зачем вообще нужен A/B-тест, если можно посмотреть на отчёт

A/B-тест нужен там, где обычная аналитика не может отличить причину от совпадения. Вы поменяли кнопку — конверсия выросла на 8%. Вопрос: это кнопка или сезонность, рекламная кампания, которая как раз стартовала на прошлой неделе, или просто колебание выборки? Без контрольной группы ответить нельзя.

Цена ошибки здесь не абстрактная. Если решение о масштабировании изменения на весь трафик или весь продукт принимается на основе совпадения, а не причинности, компания либо тратит бюджет на внедрение того, что не работает, либо, наоборот, отказывается от рабочей идеи, потому что «в отчёте не видно эффекта». Обе ошибки стоят денег, и обе не видны сразу — они проявляются в P&L через квартал, когда никто уже не помнит, из-за какого решения просела конверсия.

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

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

Как сформулировать гипотезу, которую вообще можно проверить

Тест без гипотезы — это не эксперимент, а азартная игра. Гипотеза должна быть сформулирована так, чтобы после теста можно было сказать «подтвердилась» или «опровергнута», а не «ну, как-то так».

Рабочая структура гипотезы:

• Что меняем — конкретный элемент, а не «улучшаем страницу».
• Почему ожидаем эффект — какая механика должна сработать (снижение когнитивной нагрузки, устранение возражения, ускорение принятия решения).
• На какую метрику это повлияет — одна основная метрика, не пять.
• Какой размер эффекта считаем значимым для бизнеса — не «любой рост», а конкретный порог в процентах или деньгах.

Пример плохой гипотезы: «Если сделать кнопку зелёной, конверсия вырастет». Пример рабочей: «Если убрать с формы заказа поле „должность“ (сейчас отваливается 12% пользователей на этом шаге по данным Вебвизора), конверсия в заявку вырастет минимум на 3 процентных пункта, потому что поле воспринимается как избыточное и пугает B2C-аудиторию».

Вторая гипотеза опирается на наблюдение, называет механизм и задаёт порог. Это то, что отличает тестирование от угадывания.

Как рассчитать размер выборки до запуска, а не после

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

Перед запуском нужно знать четыре параметра:

1. Базовая конверсия контрольной группы — историческое значение метрики.
2. Минимальный эффект, который вам важно уловить (minimum detectable effect) — если тест не способен различить эффект меньше 20%, а вы рассчитываете на рост в 5%, тест бессмыслен изначально.
3. Уровень значимости — обычно 95%, то есть допустимая вероятность ложноположительного результата 5%.
4. Статистическая мощность — обычно 80%, вероятность обнаружить эффект, если он реально есть.

Из этих четырёх параметров калькулятор (их много бесплатных онлайн, а также встроенные модули есть у большинства сервисов A/B-тестирования и части аналитических платформ) выдаёт нужный размер выборки на группу. Дальше — простая арифметика: размер выборки делите на дневной трафик, попадающий в эксперимент, и получаете длительность теста в днях. Этот расчёт стоит делать до того, как вы согласовали дизайн варианта Б — если по цифрам тест не наберёт статистику за приемлемый срок, дешевле пересмотреть масштаб гипотезы сразу, а не после недели разработки.

Если у вас низкий трафик — интернет-магазин с 500 заказами в месяц, B2B-лендинг с 50 заявками — классический A/B-тест часто просто не наберёт статистику за разумный срок. В этом случае честнее признать: ресурс не позволяет тестировать мелкие изменения, нужно тестировать крупные гипотезы (смена оффера целиком, а не цвет кнопки) или переходить на качественные методы — интервью с клиентами, анализ записи сессий.

Длительность теста: почему нельзя останавливать раньше срока

Даже если вы правильно посчитали размер выборки, тест нужно докрутить до конца — по времени и по количеству наблюдений одновременно. Правило простое: минимум один полный бизнес-цикл, обычно 1–2 недели, чтобы захватить будни и выходные, разные дни зарплаты, разные когорты трафика.

Останавливать тест в момент, когда результат «наконец стал значимым», — это статистическая ошибка, которая называется peeking (подглядывание). Механика проста: если проверять результат каждый день и останавливаться в момент, когда p-value впервые опускается ниже 0,05, вероятность ложноположительного результата вырастает с заявленных 5% до заметно более высоких значений — по разным оценкам, до 20–30% и выше, в зависимости от частоты проверок. Вы буквально повышаете шанс ошибки, просто чаще смотря на дашборд.

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

Как читать результат: значимость — это не про важность

Статистическая значимость (p-value меньше 0,05) означает только одно: наблюдаемая разница между группами с высокой вероятностью не случайна. Она ничего не говорит о том, насколько эта разница важна для бизнеса.

Пример: тест на выборке в 200 000 пользователей показывает статистически значимый рост конверсии на 0,1 процентного пункта. Значимость есть — эффект реален. Но 0,1 п.п. может не окупить даже разработку варианта Б. И наоборот: на маленькой выборке разница в 15% может быть незначимой просто потому, что данных недостаточно, хотя эффект вполне может быть реальным и крупным. Поэтому решение о внедрении принимается не по факту «тест зелёный», а по совокупности значимости, размера эффекта и его денежного выражения.

Три вещи, которые нужно смотреть вместе:

Доверительный интервал особенно недооценён. Если тест показал рост конверсии на 5%, но доверительный интервал — от минус 2% до плюс 12%, это значит: реальный эффект может быть и отрицательным. Публиковать такой результат как «победу» — манипуляция, пусть и часто неосознанная.

Итоговую бизнес-ценность теста стоит переводить в деньги и смотреть через призму ROMI: рост конверсии на 5% при среднем чеке и объёме трафика конвертируется в конкретную сумму, и только эта сумма — аргумент для масштабирования решения, а не сам факт «мы победили в тесте».

Множественные сравнения: почему нельзя тестировать сразу десять вариантов

Ещё одна системная ловушка — тестирование множества вариантов одновременно (A/B/C/D/E…) или множества метрик в одном тесте без поправки на множественные сравнения.

Логика проста и неприятна: при уровне значимости 95% вероятность случайно получить ложноположительный результат по одной метрике — 5%. Если вы одновременно проверяете 10 независимых метрик, вероятность, что хотя бы одна из них покажет случайную «значимость», подскакивает почти до 40%. Именно так рождаются кейсы «мы поменяли шрифт, и выросли повторные покупки на 22%» — просто одна из двадцати проверенных метрик случайно вышла за порог.

Практические правила:

• Фиксируйте одну основную метрику до запуска теста, остальные — вторичные, для контекста, не для решений.
• Если тестируете несколько вариантов одновременно, используйте поправку на множественные сравнения (например, поправку Бонферрони) или заранее закладывайте больший трафик.
• Не выбирайте метрику победы постфактум, разглядывая все данные, — это называется data dredging и обнуляет статистическую строгость теста.

Дисциплина здесь напрямую связана с общей культурой аналитики в компании — без неё сквозная аналитика превращается в конструктор для подгонки любых выводов под желаемый результат.

Что тестировать в первую очередь, если ресурсов мало

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

• Шаги воронки с максимальным оттоком — если 40% пользователей уходят на одном шаге формы, это выгоднее тестировать, чем цвет кнопки на странице с конверсией 2%.
• Точки с высоким трафиком — тест на странице с 50 000 визитов в месяц наберёт статистику за неделю, тест на странице с 500 визитами — за полгода.
• Гипотезы с понятным механизмом, а не случайные догадки — механизм даёт возможность потом объяснить результат и перенести вывод на другие страницы.
• Изменения с низкой стоимостью внедрения относительно потенциального эффекта — тест ради теста, где разработка варианта Б стоит дороже потенциального выигрыша, не имеет экономического смысла.

Частые ошибки

• Останавливают тест по первому «зелёному» результату. Ежедневное подглядывание в дашборд и остановка теста в момент случайного пересечения порога значимости — самый частый источник ложных побед.
• Путают статистическую значимость с бизнес-значимостью. Значимый, но крошечный эффект по абсолютной величине не окупает затрат на внедрение и поддержку варианта.
• Тестируют без предварительного расчёта выборки. Запуск «на глаз» приводит либо к преждевременным выводам, либо к тестам, которые никогда не наберут нужный объём данных.
• Меняют условия теста на ходу. Добавление трафика, смена сегмента, правки в варианте Б в середине теста обнуляют статистическую корректность — начинать нужно заново.
• Игнорируют сезонность и внешние факторы. Тест, запущенный на неделе распродажи или во время всплеска рекламной активности, покажет искажённый результат, не связанный с тестируемым изменением.
• Тестируют слишком мелкие изменения при низком трафике. На небольшом объёме заявок тест никогда не наберёт статистическую мощность — ресурсы стоит направить на крупные гипотезы или качественные методы исследования.
• Не документируют гипотезу и критерии успеха до запуска. Без письменной фиксации команда задним числом подгоняет интерпретацию под удобный результат.

FAQ

Сколько должен длиться A/B-тест?

Минимум один полный бизнес-цикл, обычно 1–2 недели, чтобы захватить колебания по дням недели и разным сегментам трафика. Точная длительность зависит от расчётного размера выборки и текущего объёма трафика — считать нужно до запуска, а не ориентироваться на календарь произвольно.

Какой трафик нужен, чтобы A/B-тест был осмысленным?

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

Можно ли тестировать несколько вариантов одновременно?

Можно, но это требует либо большего объёма трафика, либо поправки на множественные сравнения. Без этого вероятность случайно получить ложноположительный результат резко растёт с числом одновременно тестируемых вариантов и метрик.

Что делать, если тест не набрал значимость к плановой дате?

Честный ответ — эффекта либо нет, либо он меньше заявленного порога чувствительности теста. Продлевать тест ради «дожать до значимости» нельзя — это тот же peeking. Лучше признать результат неубедительным и перейти к следующей гипотезе или пересчитать выборку под меньший эффект.

Чем A/B-тест отличается от простого сравнения периодов "до и после"?

Сравнение «до и после» не отделяет эффект изменения от эффекта времени — сезонности, рекламных кампаний, внешних событий. A/B-тест разводит трафик на две группы одновременно, поэтому единственная системная разница между ними — тестируемое изменение.

Нужен ли аналитик для проведения A/B-теста или маркетолог справится сам?

Формулировать гипотезу и внедрять вариант может маркетолог, но расчёт выборки, выбор статистического критерия и интерпретацию доверительных интервалов лучше делать с кем-то, кто понимает статистику — ошибка в расчёте мощности теста стоит дороже, чем час консультации с аналитиком.

Как понять, что результат теста можно масштабировать на всю аудиторию, а не только на протестированный сегмент?

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

Если хотите не просто разово настроить A/B-тест, а выстроить систему, где гипотезы формулируются осознанно, тесты не врут, а решения опираются на деньги, а не на красивые проценты в отчёте — приходите на интенсив Marketing OS. Разберём вашу текущую аналитику и договоримся, с чего начать в вашей ситуации.