Команда интернет-магазина спорит, какая кнопка сработает лучше: «Купить» или «Оформить заказ». Вместо выбора на вкус можно показать варианты разным группам посетителей и сравнить результат. Именно так работает «A/B-тестирование».
В A/B-тесте одна часть аудитории видит контрольную версию A, а другая — вариант B. Затем результат сравнивают по метрике, которую выбрали еще до запуска эксперимента.
Ну а сегодня разберем, как устроено A/B-тестирование и что именно можно проверять. Кроме того, посмотрим, как считать результат и почему большей конверсии еще мало для победы.
О понятии
Итак, A/B-тестирование, или сплит-тест, — это эксперимент для сравнения двух вариантов. Один служит контрольной версией A, а второй содержит изменение B. Затем сравнивают поведение сопоставимых групп пользователей.
Обращаясь к первоисточнику, документация Firebase A/B Testing описывает этот принцип через варианты пользовательского опыта и заранее выбранную цель. Система распределяет пользователей между вариантами, а затем сравнивает их показатели.
Проще говоря, A/B-тест отвечает не на вопрос «какой вариант красивее». Он показывает, как конкретное изменение связано с выбранной метрикой.
Пример ситуации
Допустим, сервис хочет сократить форму регистрации. Версия A содержит восемь полей, а в версии B оставили пять. Пользователей распределяют между двумя вариантами и сравнивают долю завершивших регистрацию.
Как работает A/B-тест
Прежде всего до запуска нужно сформулировать проверяемую гипотезу. Иначе после эксперимента легко найти интересную цифру, но не понять, что именно проверяли.
Порядок можно выстроить так:
- Сформулируйте гипотезу и ожидаемое изменение.
- Зафиксируйте контрольную версию A и вариант B.
- Выберите основную метрику и дополнительные показатели.
- Распределите подходящую аудиторию между вариантами.
- Соберите заранее необходимый объем данных.
- Сравните результат и только после этого принимайте решение.
При этом один пользователь по возможности должен оставаться в одной группе. Иначе данные будет сложнее интерпретировать.
Кроме того, группы должны быть сопоставимыми. Поэтому пользователей распределяют случайным способом или по методике экспериментальной платформы, а не вручную по принципу «лучшие клиенты в A, остальные в B».
Что можно проверять с помощью A/B-тестирования
A/B-тест подходит не только для цвета кнопки. По сути, проверять можно любое изменение, которое удается показать одной группе и не показывать другой.
Например, тестируют:
- заголовки и тексты на странице;
- кнопки и призывы к действию;
- структуру формы или экрана регистрации;
- порядок шагов в корзине и оформлении заказа;
- варианты писем, уведомлений и рекламных сообщений;
- отдельные элементы интерфейса или функции продукта.
Однако чем больше различий между A и B, тем труднее назвать причину результата. Например, если сразу поменяли заголовок, форму и кнопку, тест сравнит версии целиком. Какое именно изменение дало эффект, из него уже не следует.
Кстати, объект теста полезно искать на этапе, где пользователи чаще всего прекращают движение к покупке. Саму логику таких этапов мы разбирали в статье про воронку продаж.
Как сформулировать гипотезу и выбрать метрику
Хорошая гипотеза связывает изменение с ожидаемым результатом. Например: «Если сократить форму с восьми полей до пяти, то конверсия в отправку вырастет, потому что пользователю потребуется меньше действий».
Затем нужно заранее определить основную метрику. Именно по ней в первую очередь сравнивают варианты.
В частности, это может быть:
- конверсия в регистрацию или покупку;
- кликабельность кнопки или сообщения;
- выручка на пользователя;
- доля завершивших конкретный шаг;
- удержание пользователей после изменения продукта.
Кроме основной метрики полезно выбрать защитные показатели. Например, новая форма может дать больше заявок, но одновременно привести больше нецелевых обращений. В таком случае одной конверсии мало.
Метрику успеха лучше зафиксировать до запуска. Если после завершения перебрать десятки показателей и выбрать только тот, где появилась красивая разница, вывод станет менее надежным.
Если тест касается заявок, результат можно сопоставить и со стоимостью обращения. На нашем сайте отдельно разобрано, как рассчитывают CPL и почему дешевый лид не всегда выгоднее.
Как рассчитать результат A/B-теста
Для тестов на целевое действие часто сравнивают конверсию. Формула выглядит так: конверсия = количество пользователей, совершивших действие / количество пользователей в варианте × 100%.
После этого можно посчитать абсолютную и относительную разницу. Они показывают результат с разных сторон.
Пример расчета
Предположим, вариант A увидели 5 000 пользователей, и 400 из них совершили покупку. Конверсия A составила 400 / 5 000 × 100% = 8%. Вариант B увидели еще 5 000 пользователей, а покупку совершили 450 человек. Его конверсия равна 9%.
Абсолютная разница составляет 1 процентный пункт. А относительный прирост равен: (9% — 8%) / 8% × 100% = 12,5%.
То есть рост на 1 процентный пункт и относительный прирост на 12,5% описывают один пример. Однако это разные способы представить изменение.
Впрочем, 9% против 8% еще не доказывают, что вариант B действительно лучше. Часть разницы могла появиться случайно. Поэтому дальше оценивают статистическую надежность результата.
Что такое статистическая значимость
Статистическая значимость помогает отделить наблюдаемую разницу от случайного колебания данных. Для этого учитывают выбранную модель, размер выборки и показатели эксперимента.
Например, Firebase A/B Testing применяет частотный подход и рассчитывает p-value. В этом сервисе значение ниже 0,05 считают статистически значимым для используемой модели.
Проще говоря, p-value показывает, насколько необычны полученные данные при условии, что реального эффекта нет. Чем меньше значение, тем хуже данные согласуются с таким предположением.
Даже при пороге p-value 0,05 нельзя переводить результат как «у варианта B 95% шансов быть лучше». Эта величина оценивает данные при предположении об отсутствии эффекта, а не вероятность истинности самой гипотезы.
Кроме того, статистическая значимость не равна практической пользе. На огромной аудитории даже маленькая разница может стать статистически заметной. Поэтому после расчета стоит спросить: достаточно ли велик эффект, чтобы ради него внедрять изменение.
Сколько пользователей нужно для теста
Универсального числа нет. Тест на 1 000 человек может быть достаточным для одной задачи и слабым для другой.
Прежде всего на размер выборки влияют:
- исходный уровень метрики, например текущая конверсия;
- минимальный эффект, который бизнес хочет заметить;
- выбранный уровень статистической значимости;
- требуемая статистическая мощность;
- соотношение пользователей между вариантами.
Например, рост конверсии с 10% до 15% заметить легче, чем изменение с 10% до 10,2%. Поэтому для небольшого эффекта обычно нужна большая выборка.
Кроме того, тест должен охватить нормальное поведение аудитории. Если провести его только в необычный день распродажи, вывод может плохо переноситься на обычные недели.
Важно понимать, срок сам по себе не заменяет размер выборки. Документация Firebase связывает полезность результата и с объемом данных, и с репрезентативностью аудитории. Поэтому правило «всегда тестируем семь дней» не подходит для любых проектов.
Если используется классический тест с заранее рассчитанной выборкой, не стоит останавливать его при первом лидерстве B. Впрочем, некоторые платформы применяют последовательные или другие методы анализа. Тогда момент остановки определяют по правилам конкретной методики.
A/B, A/B/n и многовариантное тестирование
Не все эксперименты с несколькими версиями устроены одинаково. Отличие прежде всего в количестве вариантов и способе их комбинации.
| Метод | Что сравнивают | Когда подходит |
|---|---|---|
| A/B | Два варианта | Нужно сравнить контроль A и одну версию B |
| A/B/n | Три и более самостоятельных варианта | Есть несколько альтернатив одной идеи |
| Многовариантный тест | Комбинации изменений нескольких элементов | Нужно оценить сочетания элементов |
Например, три разных заголовка можно сравнить через A/B/n. А если тестируют сочетания заголовков и изображений, речь уже идет о многовариантном эксперименте.
Впрочем, с ростом числа вариантов увеличивается и потребность в данных. Поэтому сложный дизайн имеет смысл, только если аудитории действительно хватает.
Ошибки при A/B-тестировании
Даже аккуратный расчет не спасет эксперимент, если его изначально поставили неправильно. Поэтому перед запуском стоит проверить типичные риски.
В частности, к ним относятся:
- Запуск без четкой гипотезы и основной метрики.
- Слишком маленькая выборка для нужного эффекта.
- Изменение варианта или правил учета уже во время эксперимента.
- Замена множества элементов без понимания, что именно проверяется.
- Выбор победителя только по большей цифре без оценки случайности.
- Игнорирование других метрик, если рост одной ухудшает важный показатель.
Например, новая кнопка может увеличить число кликов, но снизить покупки. В таком случае улучшение промежуточной метрики еще не означает пользу для бизнеса.
Кроме того, важна техническая корректность. Если пользователь попадает то в A, то в B или события считаются по-разному, статистика уже не исправит проблему сбора данных.
Как принять решение после теста
Прежде всего вернитесь к исходной гипотезе. Затем сравните основную метрику, статистическую надежность и дополнительные показатели.
Если B дал значимый и полезный прирост без заметного ущерба другим метрикам, его можно рассматривать для внедрения. Однако тест может закончиться и без победителя. Это нормальный результат.
В таком случае не нужно объявлять A и B одинаковыми навсегда. Эксперимент лишь не дал достаточных оснований утверждать, что выбранное изменение улучшило метрику в заданных условиях.
В итоге A/B-тестирование ценят не за возможность каждый раз найти победителя. Его польза в другом: спор превращается в проверяемую гипотезу, а решение опирается на поведение пользователей и заранее выбранные критерии.