Возможно, вы сталкивались с дилеммой: появилась хорошая идея — и кажется, что она принесет пользу, но в голове мысль: «Что, если этой доработкой мы всё только усложним?» В таких случаях помогут A/B-тесты.
В статье разберемся: как понять предпочтения пользователей, не опираясь на свои идеи и догадки, и как и когда использовать A/B-тесты, чтобы не разочароваться в результате.
Что такое A/B-тестирование и зачем нужно
Пример A/B-теста с изменением цвета элемента
Например, мы делаем лендинг мероприятия и хотим улучшить конверсию. Приходит дизайнер и говорит: «А давайте сделаем кнопку регистрации более яркой». Идея неплохая, но хочется ее проверить так, чтобы не потерять текущих потенциальных посетителей.
A/B-тестирование — инструмент, который помогает выбрать правильный путь развития продукта, при этом не сильно рискуя усложнить жизнь пользователям.
Как это работает? Вернемся к примеру с лендингом. Мы хотим поменять цвет кнопки на более яркий, но боимся сделать хуже. Тогда мы берем небольшой процент потенциальных посетителей, например 15%, и делаем им ярко-красную кнопку. А для остальных 85% всё оставляем как есть. Дальше наблюдаем за 15% пользователей с красной кнопкой и сравниваем количество их регистраций с пользователями со старой кнопкой.
Так мы видим, работает наша теория или нет. Например, можно сделать вывод: у лендинга с красной кнопкой хуже конверсия, потому что дизайнер нарисовал красный фон, который сливается с кнопкой. Или наоборот: видно, что пользователи стали чаще замечать кнопку — и на мероприятие зарегистрировалось намного больше людей.
Кому необходимо
A/B-тесты полезны компаниям с уже устоявшейся аудиторией. В таких проектах важно менять продукт максимально деликатно, чтобы не шокировать текущих пользователей масштабными изменениями.
Если вы только начинаете новый проект или запускаете стартап, важно развиваться быстро. Пока нет четко устоявшейся аудитории, у вас есть возможность динамично запускать свои идеи. Не стоит тратить время на A/B-тесты: развивайтесь смело, не боясь допустить критичных ошибок.
Основные виды
Помимо классического A/B-тестирования, когда меняют какой-то небольшой элемент на одной странице, есть еще несколько смежных видов.
Сплит-тестирование (Split Testing). Их иногда путают, но разница — в подходе.
Сплит-тестирование подразумевает запуск отдельной веб-страницы или экрана мобильного приложения с другим наполнением или структурой. Другими словами, проводят тест достаточно масштабных изменений: например, редизайн лендинга.
A/B-тестирование, наоборот, проводят небольшими итерациями, постепенно что-то меняя или добавляя. Например, сначала меняем цвет кнопки, оцениваем результат — и только потом меняем другие элементы.
Мультивариативное тестирование (Multivariate Testing, MVT). В этом виде тестов комбинируют разные небольшие доработки — и на каждый уникальный набор изменений направляют небольшую часть аудитории.
В примере с кнопкой регистрации на лендинге можно поменять не только цвет, но и расположение кнопки. Нужно составить список со всеми возможными вариациями и направить на каждую часть аудитории:
- вариант «Базовый» — оставляем цвет кнопки, оставляем ее расположение;
- вариант А — меняем цвет кнопки на красный, оставляем ее расположение;
- вариант Б — оставляем цвет кнопки, ставим ее в левый угол;
- вариант В — меняем цвет кнопки на красный, ставим ее в левый угол.
На каждый из этих четырех вариантов мы можем направить 25% аудитории и через время посмотреть, где было больше регистраций.
Пример MVT-теста, где тестируют комбинацию изменений (цвет/расположение)
Мультистраничное тестирование (Multipage Testing). Элемент меняют не на одной странице, а на всех, где он встречается. Например, вы можете поменять цвет кнопки на красный на всём сайте.
Чтобы интерпретировать результаты, потребуется больше времени: нужно будет проверить показатели всех действий, которые выполняет новая кнопка на всех страницах сайта или приложения.
Научиться разрабатывать гипотезы, составлять A/B-тесты и правильно интерпретировать их результаты можно на курсе Skypro «Аналитик данных». А еще сможете визуализировать результаты анализа и аргументированно представлять их коллегам и руководству.
Пример мультистраничного теста, где мы должны проверить конверсию на каждой затронутой странице
Инструменты
На рынке множество инструментов, которые позволяют проводить A/B-тесты.
Google Analytics — самый популярный сервис для аналитики, с его помощью можно создавать A/B-тесты на сайте и управлять ими. Для каждого теста можно настроить ключевые конверсии, чтобы потом наглядно их отслеживать.
Сервис не умеет проводить подобные тесты в мобильных приложениях — зато функционал A/B-тестирования бесплатный.
Результаты A/B-тестирования в Google Analytics
Firebase — сервис нацелен на продуктовые решения: мобильные или веб-приложения. Как и в Google Analytics, для каждого варианта можно настроить ключевые метрики и аудиторию, на которую будет распространяться тест.
Сервис работает с мобильными приложениями, но для информационных сайтов вряд ли подойдет. Функционал A/B-тестирования тоже бесплатный.
Результаты тестирования в Firebase Analytics
Amplitude Experiments — удобный и многофункциональный сервис, который работает в связке с Amplitude Analytics. Больше ориентирован на продуктовую разработку — если у вас информационный сайт или портал, сервис может не подойти. Из минусов: платный.
Результаты тестирования в Amplitude Experiments
Если не уверены, какой инструмент лучше использовать, или еще не работали в сфере аналитики, то в Skypro есть обучение на аналитика данных.
Что нужно тестировать
Часто в A/B-тестировании нужно проверять, как изменение того или иного элемента повлияет на целевые действия аудитории. Например, как добавление кнопки со справочной информацией при авторизации в приложении может повысить конверсию.
Не стоит им злоупотреблять. Если проводить подобные тесты при каждом изменении на сайте или в приложении, можно сильно замедлить развитие продукта. Сразу выкатывайте новое решение, если уверены, что оно будет полезно аудитории (например, клиенты уже несколько месяцев просят добавить новый функционал) и знаете, что оно не усложнит использование продукта. Если что-то пойдет не так — всегда можно исправить или откатить назад.
Как провести A/B-тестирование
Любое проведение A/B-тестов стоит начинать с построения гипотезы. Гипотеза — ваша идея о том, как можно улучшить сайт или приложение. Если она слишком большая, попробуйте разбить ее на более мелкие.
После того как определились с гипотезой, подключите метрики, которые помогут отслеживать целевые показатели. Например, если цель гипотезы — увеличить количество переходов на форму регистрации, добавьте отслеживание переходов на эту форму.
Используйте внешние сервисы — например те, что мы рассмотрели выше, чтобы создать новый A/B-тест. Укажите параметры аудитории, которая должна попасть под него.
Обычно при создании A/B-теста указывают базовое состояние: когда у пользователя ничего не меняется и остается как есть. И дальше вы добавляете сколько угодно вариантов. В классическом A/B-тесте есть только два варианта: базовый и с измененным состоянием. Например, «Базовый» и «Красная кнопка регистрации». Если проводите MVT-тест, можете добавить и другие — например «Синяя кнопка», «Желтая кнопка» и так далее.
Для каждого варианта, кроме базового, можно настроить свои параметры аудитории. Например, указать, что нужно поменять цвет кнопки регистрации не более чем у 10% пользователей, которые:
- еще не зарегистрированы;
- проживают на территории США;
- подходят под любые другие критерии.
После того как запустили тестирование, нужно подождать необходимых результатов. Время проведения теста зависит от объема аудитории. Если у вас мало пользователей, то, чтобы выборка была репрезентативной, потребуется больше времени для сбора достаточного объема данных.
Как только собрали данные — осталось посмотреть на показатели метрик, которые вы добавили раньше в разрезе каждого варианта. Если видите, что выше показатели у варианта с изменениями, — можно считать теорию подтвержденной.
Как оценить результаты
Может быть так, что у базового варианта показатели выше, чем у варианта с изменениями. Прежде чем отметать гипотезу и считать ее неудачной, посмотрите на выборку пользователей, которые попали под тест. Возможно, вы выставили слишком небольшой процент. Тогда надо или ослабить критерии отбора, или увеличить процент пользователей.
В процессе теста может оказаться, что показатели не слишком сильно поменялись. Тогда попробуйте копнуть глубже и найти новые гипотезы, которые будут дополнять текущую, чтобы провести дополнительные тесты.
Научиться разрабатывать гипотезы, составлять A/B-тесты и правильно интерпретировать их результаты можно на курсе Skypro «Аналитик данных». А еще сможете визуализировать результаты анализа и представлять их коллегам и руководству.
Частые ошибки
Самая частая ошибка при проведении A/B-тестов — их чрезмерное использование. Тестирование — полезный инструмент, но не всегда в нём есть необходимость: можно замедлить развитие продукта.
Используйте A/B-тесты в тех разделах, где критически важна конверсия, например при регистрации или покупке. Или когда вы не уверены, полезна идея или она усложняет использование сервиса.
Другая частая ошибка — в недостаточности метрик, через которые отслеживают результаты тестирования. Например, вы видите, что конверсия в результате теста упала. Если вы не добавили метрики на промежуточных шагах, нельзя точно сказать, из-за чего конверсия хуже.
Пример A/B-теста
Представим, что мы делаем мобильное приложение и возникает идея: «Давайте автоматически заполнять логин/пароль пользователя, подтягивая данные из браузера». Идея кажется хорошей: пользователям не нужно будет сидеть и вспоминать свои данные для входа в приложение. Но потом мы задумываемся: что, если у пользователя несколько аккаунтов? Не запутаем ли мы его
Выдвигаем гипотезу: «Если автоматически заполнять логин с паролем, то пользователям будет проще попасть в мобильное приложение. Следовательно, конверсия в авторизацию вырастет».
Чтобы отслеживать показатели этой конверсии, надо добавить следующие метрики:
- Событие успешной авторизации. Мы ожидаем, что данный показатель должен вырасти.
- Событие авторизации с ошибкой вида «Неправильный логин/пароль». Метрика нужна, чтобы отследить, уменьшится ли ввод неправильных логина/пароля. Мы ожидаем, что показатель должен уменьшиться.
- Событие выхода из аккаунта. Мы допускаем, что у пользователя может быть несколько аккаунтов. Если он автоматически войдет не в тот аккаунт, то будет сразу из него выходить. Мы ожидаем, что показатель не будет увеличиваться.
После того как мы добавили необходимые метрики, создаем новый A/B-тест в используемой системе аналитики. Прописываем наш вариант: «Автоматическое заполнение логина и пароля» и указываем созданные события в качестве метрик. Еще указываем процент аудитории и его критерии, например 50%.
Спустя время смотрим на результат. Если все показатели изменились так, как мы ожидали, то считаем тест пройденным: можно добавить автоматическое заполнение логина/пароля для всех пользователей. Если какие-то метрики отличаются от наших ожиданий, то нужно доработать гипотезу.
Главное
- A/B-тестирование хорошо подходит для компаний с уже устоявшейся аудиторией.
- Тестирование может пригодиться, когда критически важна конверсия или когда есть сомнения в полезности идеи.
- Важно четко формулировать гипотезу и ожидаемые результаты.
- Не забывайте максимально полно покрывать проект метриками: в местах, где проводите тестирование, или в разделах, которые могут быть задеты изменениями.
Добавить комментарий