В маленьких и больших компаниях часто меняют продукт по ощущениям: кажется, что новая кнопка удобнее и баннер на главной работает лучше слайдера. Проблема в том, что «кажется» не измеряется и ничего не гарантирует.
A/B-тестирование — способ заменить мнение на измеримый результат. Разберём, как устроен метод, зачем он бизнесу и как провести первый тест без типичных ошибок новичков.
Что такое A/B-тестирование
A/B-тест — рандомизированный контролируемый эксперимент: пользователей случайным образом делят на контрольную группу (текущая версия) и экспериментальную (новая версия), а затем сравнивают метрики между группами.
Метод пришёл из медицины — там таким же образом проверяют эффективность лекарств: одна группа пациентов получает препарат, другая — плацебо, и дальше сравнивают результат. В продукте вместо таблеток тестируют кнопки, алгоритмы и интерфейсы, а принцип остаётся тот же.
Для проведения качественного A/B-теста важны два условия: рандомизация и одновременность. Если группы формируются не случайно, они получаются разными по составу ещё до начала теста и сравнение теряет смысл. Если группы существуют в разное время, на результат влияют сезонность, новости и десятки факторов, которые вы не контролируете.
Сравнение метрики до и после изменения — это не A/B-тест.
Схема A/B-теста: рандомизация пользователей по группам и сравнение метрик
Почему без тестов дорого ошибаться
Даже опытные специалисты регулярно ошибаются в прогнозах. По разным оценкам, положительный результат показывают около 30% A/B-тестов — то есть в 70% случаев «улучшение» либо не работает, либо вредит метрикам. Предсказать заранее, какой тест попадёт в удачные 30%, не может ни дизайнер, ни продакт, ни аналитик.
Показательный пример: команда поисковика Bing протестировала десятки оттенков синего цвета для ссылок в поисковой выдаче. Один конкретный оттенок увеличил годовую выручку на десятки миллионов долларов. Угадать такой результат заранее было невозможно — его нашли только через систематический перебор и измерение.
Обратная сторона — цена отказа от тестирования. Один интернет-магазин электроники восемь месяцев откладывал тест порога бесплатной доставки: «и так всё работает». Когда порог всё же снизили с 5 000 до 3 000 ₽, средний чек почти не изменился, а число заказов выросло на 12%. Восемь месяцев роста были упущены просто потому, что тест не запустили вовремя.
Где применяются A/B-тесты
A/B-тесты работают везде, где есть достаточный поток пользователей и измеримые метрики — и это не только кнопки и цвета.
В диджитале тестируют интерфейс, алгоритмы — рекомендации, ранжирование, персонализацию — маркетинг и онбординг. В оффлайн-бизнесе тоже: ритейл тестирует выкладку товаров и ценники по магазинам, логистика — маршруты и упаковку, банки — условия продуктов и скрипты call-центра.
По своему опыту скажу: чаще всего недооценивают email-рассылки и онбординг. Трафика там достаточно, метрики понятны, а системно тестируют их редко.
Этапы A/B-теста
A/B-тестирование — это структурированный процесс из шести этапов:
- Выявление возможности — анализ данных, поиск проблемного места в воронке;
- Формулирование гипотезы — конкретное проверяемое предположение с обоснованием;
- Проектирование эксперимента — метрики, размер выборки, длительность, сплитование;
- Запуск и мониторинг — следите за технической корректностью, но не принимаете решений до окончания;
- Анализ результатов — статистическая значимость, размер эффекта, влияние на другие метрики;
- Принятие решения — внедрить, отклонить или проверить дополнительно.
Приведу пример из своего опыта, чтобы показать, как эти шесть шагов работают в реальности.
Мы работали над e-commerce-проектом и анализировали воронку оформления заказа. Данные показали, что 35% пользователей, положивших товар в корзину, уходили на этапе выбора способа доставки. Это был шаг 1 — мы нашли конкретное проблемное место.
Изучив записи сессий, мы увидели, что пользователи долго скроллили список из 8 вариантов доставки, сравнивали цены, путались в сроках. Мы сформулировали гипотезу (шаг 2): если мы предварительно отсортируем варианты доставки по популярности и добавим тег «Выбор большинства» к самому частому варианту, конверсия этапа вырастет на 10–15%, потому что социальное доказательство снижает тревожность выбора.
На шаге 3 мы рассчитали, что при текущем трафике нужно 2 недели для набора достаточной выборки. Основная метрика — конверсия шага «доставка → оплата». Guardrail — средняя стоимость доставки (мы не хотели, чтобы все выбирали самый дешёвый вариант в ущерб качеству сервиса).
Результат: конверсия этапа выросла на 12%. Но что интереснее — средняя стоимость выбранной доставки выросла на 4%, потому что самым популярным вариантом была не самая дешёвая, а курьерская доставка на следующий день. Люди готовы платить за удобство, когда видят, что другие делают тот же выбор.
Этот кейс научил меня двум вещам: во-первых, guardrail-метрики могут приносить приятные сюрпризы. Во-вторых, записи сессий — бесценный источник гипотез, который многие команды недооценивают.
Частые ошибки новичков при проведении A/B-теста
Шесть этапов ещё не гарантируют корректный тест. Гипотеза может быть точной, а результат всё равно недостоверным, если что-то пошло не так на уровне реализации: как разбили пользователей на группы, хватило ли выборки или в какой момент зафиксировали метрики.
Три ошибки встречаются чаще остальных. Каждая из них незаметна на старте и выясняется только тогда, когда результаты теста уже нельзя пересчитать.
- Неслучайное распределение пользователей. «Чётные ID — в группу A, нечётные — в B» кажется случайным, но нет: если ID присваивается по порядку регистрации, чётные пользователи оказываются более старыми и опытными. Правильный вариант — хеширование ID с солью эксперимента.
- Выборка меньше, чем нужно. Чтобы обнаружить эффект в 10% при текущей конверсии 3%, нужно около 70 000 пользователей в каждой группе. Интуитивно кажется, что хватит и тысячи — в этом разрыве рождается большинство ошибочных выводов.
- Метрики, выбранные после запуска теста. Если проверить 20 метрик вместо одной заранее определённой, с вероятностью 64% хотя бы одна покажет «значимый» результат случайно.
A/B-тестирование не требует бюджета Google или отдельной команды экспериментов. Нужны поток пользователей, чёткая гипотеза и дисциплина: не подглядывать в промежуточные результаты, не менять метрику после запуска и не путать удобную рандомизацию с настоящей.
Первый тест необязательно должен быть масштабным. Важнее, чтобы он был поставлен корректно — тогда даже отрицательный результат даст рабочее знание о продукте, а не случайную цифру, в которую страшно поверить.