Гайд по АБ-тестам: подготовка, проведение и результаты

Аналитика в AnyQuery занимает особое место: эффективность наших решений строится на огромном количестве данных и выводов. В этой статье мы разберёмся с пользой АБ-тестов, а затем научимся корректно их проводить.

Для начала ответим на вопрос: зачем мы делаем так много АБ-тестов и почему хотим делать еще больше?🙃

Нам приходится решать уникальные проблемы, с которыми никто не сталкивался ранее. Без анализа собственных действий команда AnyQuery рискует наделать кучу ошибок и неудобного UX. А это, в свою очередь, отразится на ваших конверсиях.

АБ-тесты помогают делать меньше ошибок и больше удобного UX😉

Иногда даже самый дружелюбный UX генерирует меньше продаж/выручки для бизнеса. Например, это актуально, когда мы работаем с маркетинговыми акциями / плашками или сортировкой. Подсветить бесплатную доставку — это здорово, но может принести меньше денег, если есть альтернативы.

АБ-тесты помогают понять, сколько денег мы потеряем или заработаем, если внедрим какое-то решение.

Разработка новой функции — это время IT-команды. АБ-тесты MVP-версии (минимально жизнеспособной) помогают понять, есть ли потенциал у гипотезы и стоит ли тратить ресурсы на полноценное решение.

Часто, тестируя одну метрику или фичу, мы находим слабые места на других шагах конверсии. Так АБ-тесты помогают найти направления для исследований через юзабилити-тесты или более глубокого погружения в аналитику

Вы используете АБ-тесты в работе? Поделитесь своим опытом в комментариях, а мы идем дальше.

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

Есть 3 фактора. Если их не устранить, выводы из результатов АБ-теста будут некорректными. А это, в свою очередь, может привести к выбору неправильной гипотезы.

Если собираетесь тестировать новые фичи или элементы интерфейса, советуем пройтись по данному чек-листу.

1️⃣Самая распространенная ошибка — это разница между группами. Например, группа, А — случайные пользователи из Перми, а группа Б — случайные пользователи из Севастополя. Или одна группа больше другой.

2️⃣Баги, неправильные настройки, ошибки в работе отдельных инструментов. Техническая часть очень важна, когда имеешь дело со сбором данных. Перед стартом теста нужно все тщательно перепроверить.

3️⃣Когда в одну из групп попадают т. н. слоны — оптовые покупатели. Если средний чек составляет 20 тысяч рублей, а какой-то юзер делает заказ на 200 тысяч, возникает сильный перекос. Мы стараемся вычищать такие данные.

Какие еще ошибки в проведении АБ тестов вы знаете? Тоже пишите в комментариях.

Теперь, когда мы разобрались с искажениями, давайте пройдемся по способам, которые позволяют этих искажений избегать.

1️⃣Чтобы провести корректный тест, нам нужны 2 абсолютно идентичные группы пользователей. Самый простой способ убедиться, что группы не отличаются между собой — провести АА-тест.

Если группы распределяются равномерно по кол-ву пользователей/сессий и ведут себя одинаково, запускаем основной тест. Ну, а если нет, внимательно изучаем каждую группу, чтобы найти проблему.

2️⃣Не менее важная часть АБ-тестирования — это проверка готовых данных перед их анализом. Часто на этом этапе вылазят аномалии, ошибки и «слоны».

Типичный пример ошибки — это запуск двух АБ-тестов параллельно. К примеру, одновременные эксеприменты с поисковой выдачей и чекаутом. Оба элемента влияют на конверсию, и могут влиять друг на друга. Это может исказить результаты тестирования.

3️⃣Нельзя останавливать АБ-тест до достижения статистической значимости. То есть, такого количества накопленных событий (конверсий), при котором результаты не будут случайными.

Это правило общеизвестно, но им часто пренебрегают. На всякий случай делюсь простым калькулятором АБ-тестов. Он помогает понять, являются ли результаты теста статистически значимыми, или нужно подождать.

4️⃣Если результаты эксперимента кажутся вам странными — вам не кажется. Скорее всего, в тест закралась ошибка или аномалия.

Длительность АБ-теста зависит от двух составляющих: математики и бизнеса. Рассмотрим каждый пункт детально.

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

Самый простой способ для расчета — воспользоваться вот этим калькулятором.

Сколько новых версий мы будем тестировать? Готовы ли мы под эксперимент выделить 100% трафика или ограничимся половиной? Будем ли мы ограничивать региональность? На какие метрики ориентируемся при принятии решения?

Оптимальный стандарт — это АБ-тест (две группы) на 100% трафика с ключевой метрикой: конверсия из трафика (в нашем случае из поиска) в заказ или добавление в корзину.

Однако бывают случаи, когда сроки АБ-теста выходят слишком большими. И что делать в такой ситуации? На этот случай мы также подготовили чек-лист.

1️⃣Не ограничивайте трафик, который участвует в эксперименте. Запустите тест на 100% пользователей, чтобы искусственно не завышать сроки эксперимента.

2️⃣Если у вас 3 и больше вариантов, не тестируйте все сразу. Протестируйте первые 2, а каждый следующий сравнивайте с победителем.

Допустим, вы тестируете 4 гипотезы. Действуйте по следующей схеме:

📍А/Б тест — Б побеждает.

📍Б/В тест — В побеждает.

📍В/Г тест — В снова побеждает.
В итоге из 4-х вариантов остается оптимальный.

3️⃣Поиграйтесь с критериями успеха. Возможно стоит принимать решения не по конверсии в заказ, а по промежуточному шагу — добавление в корзину.

Чем выше изначальная конверсия, тем быстрее и проще зафиксировать статистическую значимость.

4️⃣В крайнем случае, можете попробовать снизить уровень достоверности. Это % вероятности того, что полученные результаты окажутся ложными.

Обычно уровень достоверности равен 5%, но можно поставить 10% или 15%. В таком случае сроки теста уменьшатся, но вместе с тем возрастет риск принять неверное решение.

Естественно, все 4 вышеперечисленных варианта можно комбинировать. В 95% случаев их достаточно, чтобы существенно снизить сроки АБ-тестирования

А для оставшихся 5% есть мы😉

Напоследок давайте разберемся, почему мы не проводим столько АБ-тестов, сколько хотелось бы.

Простой ответ — на АБ-тесты часто не хватает ресурсов.

Для нормального тестирования нам нужен дизайнер, разработчик, PM и аналитик. Либо мы можем провести тест вместе с командой клиента. В любом случае на тест уходит время сотрудников, а время каждого сотрудника — деньги.

Дизайнер должен отрисовать минимум 2 варианта фичи, фронтендер — сверстать, аналитик обработать данные, а менеджер — организовать работу команды. Результат теста должен, как минимум, окупить работу всех этих специалистов.

Но это не единственная проблема.

Чтобы получить корректные результаты тестирования, нужно много трафика. Если трафика будет мало, тест растянется на длительный срок. Либо мы не достигнем статистической значимости и результатам теста нельзя будет доверять.

Поэтому сейчас большинство тестов проводится при соблюдении 2-х условий:

1️⃣У бизнеса клиентская интеграция, в которой мы отвечаем за все работы. То есть, не нужно отвлекать IT-команду клиента.

2️⃣На сайте достаточно трафика, чтобы результаты были корректными и проведение теста не занимало год.

Если у вас есть идеи, как исправить эту проблему — пишите в комментариях😉

А мы на этом заканчиваем наш лонгрид и приступаем к следующему)