A/B-тестирование — это сравнение двух версий страницы или экрана для определения какая работает лучше. В 2026 году это стандарт для серьёзных продуктов.
Смысл метода не в том, чтобы «проверить дизайн», а в том, чтобы заменить спор мнениями измерением. Пока трафик делится случайно и обе версии живут одновременно, различие в конверсии объясняется только самим изменением, а не сезоном, рекламной кампанией или днём недели. Всё остальное в A/B-тестах — техника: как считать, сколько ждать и как не обмануть себя.
Что тестировать
- Заголовки и CTA-кнопки
- Цены и тарифы
- Шаги чекаута
- Иконки и скриншоты в сторах (через Apple/Google Search Ads)
- Onboarding-флоу
- Push-нотификации
Порядок в этом списке не случаен: сверху то, что дёшево менять, снизу — то, что меняет продукт. Начинать разумно с элементов, которые видит максимум людей. Заголовок первого экрана и главная кнопка на лендинге проходят через 100% трафика, поэтому тест набирает данные быстро. Изменение на пятом шаге оформления заказа увидит доля пользователей, и ждать значимости придётся месяцами.
Отдельный класс тестов — сокращение шагов. Убрать обязательное поле, объединить два экрана, добавить оплату в один клик. Такие изменения обычно дают больший эффект, чем перекраска кнопки, потому что убирают реальное трение, а не украшают его.
Чего тестировать не стоит: мелочи вроде оттенка и радиуса скругления при небольшом трафике. Эффект таких правок меньше статистического шума, и вы потратите месяц, чтобы получить неубедительный результат.
Процесс: от гипотезы до раскатки
Тест начинается не с идеи «а давайте попробуем», а с наблюдения. Данные аналитики показывают, что на шаге доставки отваливается 40% корзин; записи сессий показывают, что люди трижды кликают по неактивному полю. Из этого рождается гипотеза с конкретной формулировкой: «если убрать обязательный ввод адреса до выбора способа доставки, доля завершённых заказов вырастет».
До запуска фиксируются четыре вещи: одна главная метрика, минимальный эффект, который вам интересен, требуемый объём выборки и дата окончания. Всё это записывается заранее — иначе появляется соблазн подгонять критерии под получившийся результат.
После завершения решение принимается по заранее выбранной метрике, а не по той, которая «выстрелила». Если победил вариант B, раскатывайте его на 100% и через две-три недели проверьте, что эффект сохранился на реальных деньгах, а не только на кликах. Отрицательный результат тоже полезен: он закрывает направление и экономит следующий спринт.
Инструменты
VWO, Optimizely, Google Optimize (закрылся в 2024, использовать GA4 + GTM), Firebase Remote Config (для приложений).
Для сайта на своей CMS часто дешевле сделать сплит на стороне сервера: пользователь получает вариант при первом заходе, выбор пишется в cookie, событие уходит в GA4 с параметром варианта. Это надёжнее клиентских скриптов — нет мигания страницы, когда исходная версия успевает отрисоваться до подмены, и нет просадки скорости от внешнего JS.
Для приложений Firebase Remote Config плюс A/B Testing закрывают почти всё: варианты раздаются с сервера, релиз в стор не нужен, эксперимент можно остановить одним переключателем. Важная деталь — конфиг должен приходить до отрисовки тестируемого экрана, иначе часть пользователей увидит дефолтный вариант и попадёт в выборку неправильно.
Статистическая значимость
Минимум 1000 конверсий на вариант. Confidence level 95%. Минимум 7 дней (учесть недельный цикл).
Практический смысл этих цифр такой. Confidence level 95% означает: если разницы на самом деле нет, вы ошибочно объявите победителя примерно в 5% случаев. Запустив двадцать тестов подряд, один «результат» вы получите на пустом месте — это нормальное свойство метода, а не сбой.
Объём выборки считается до старта, а не подбирается по ходу. Зависимость грубо такая: чем меньше эффект вы хотите поймать, тем больше нужно данных, причём нелинейно. Поймать рост конверсии с 2% до 4% можно на нескольких тысячах посетителей; поймать рост с 2,0% до 2,2% — на сотнях тысяч. Если трафика столько нет, честный вывод — этот тест вам недоступен, нужно менять что-то более крупное.
Семь дней — минимум из-за недельной сезонности: поведение в понедельник и в субботу разное, и обрезанный период смещает результат. По той же причине не заканчивайте тест в середине недели — берите целое число недель.
Когда A/B не подходит
Метод бесполезен на малом трафике. Если на лендинге 300 визитов в месяц и 6 заявок, никакой сплит не даст значимого результата за разумное время. В этой ситуации работают другие инструменты: записи сессий, разговоры с клиентами, последовательные изменения с оценкой по кварталу.
Не подходит он и для больших редизайнов. Когда меняется всё сразу, тест отвечает «стало лучше или хуже», но не отвечает «за счёт чего». Если новая версия проиграла, вы не знаете, что именно откатывать. Такие изменения выкатывают поэтапно с мониторингом ключевых метрик, а не как один эксперимент.
Типичные ошибки
- Раннее завершение теста при «победе»
- Тест на маленькой выборке
- Несколько тестов одновременно
- Игнорирование сегментов (новые vs возвращающиеся)
Раннее завершение — самая частая и самая дорогая. В первые дни разница между вариантами скачет, и почти всегда наступает момент, когда один «уверенно ведёт». Если остановиться там, вы зафиксируете шум. Правило простое: дата окончания и объём выборки определены до старта и не двигаются, потому что вам понравился график.
Несколько тестов одновременно допустимы, если они на разных участках воронки и не пересекаются визуально. Два теста на одной странице дают четыре комбинации, и вы не разложите эффект обратно на составляющие без специального дизайна эксперимента.
Ещё две ошибки, которых нет в списке, но которые встречаются постоянно. Первая — неучтённая разница платформ: изменение может выигрывать на десктопе и проигрывать на мобильных, а в среднем давать ноль. Вторая — тест на метрику, которая не связана с деньгами: рост кликов по кнопке «Купить» без роста оплат означает, что вы просто передвинули отвал на шаг дальше. Ту же дисциплину полезно применять и к трафику: тест на странице, которая только что просела в выдаче, покажет что угодно, поэтому поисковую динамику смотрят до, а не после.
Практический вывод: запускайте тесты только там, где хватает трафика для значимости, формулируйте гипотезу до эксперимента и фиксируйте главную метрику, размер выборки и дату окончания заранее. Начинайте с крупных изменений в верхней части воронки — заголовок, оффер, количество шагов. Если трафика мало, не тратьте время на сплиты: сначала приведите сайт в состояние, при котором есть что измерять, а тестирование в мобильном приложении начинайте после того, как накопится стабильная аудитория.