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