Подпишитесь на интересующие вас теги, чтобы следить за новыми постами и быть в курсе событий.
Как улучшить продукт с помощью A/B-тестирования
Рассмотрим жизненный цикл A/B-тестирования на конкретных примерах, а также обсудим, в каких случаях его стоит применять, и разберём ошибки.
1856
Если вы хотите создать по-настоящему качественный продукт, то вам нужно проводить UX-исследования. Одним из ключевых UX-исследований является A/B-тестирование. В этой статье мы рассмотрим его жизненный цикл на конкретных примерах, обсудим, в каких случаях его стоит применять, и разберём ошибки.
Начнём с кейса
В 2019 году популярная социальная сеть изменила пункт меню «Группы» на «Сообщества».
Я считаю, что с точки зрения UX, это катастрофа: слова «Сообщения» и «Сообщества» визуально похожи, а значит люди начнут путаться и переходить в нецелевой раздел (ситуация осложняется ещё и тем, что «Сообщения» и «Сообщества» — самые популярные разделы сети).
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Пройдясь по обсуждениям изменения, я заметил много негатива по этому поводу, что очевидно плохо сказалось на впечатлениях о продукте.
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Этой проблемы можно было избежать с помощью А/В-тестирования.
Что такое A/B-тестирование
У нас есть несколько версий одного проекта. Например, страница с баннером: в первом случае баннер находится вверху страницы, а во втором — внизу (вариантов может быть и больше — всё зависит от количества гипотез и размеров аудитории).
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Мы берём аудиторию, посетителей страницы, и делим её на несколько групп — по количеству версий продукта. Далее каждая группа пользуется своей версией сайта, а мы следим за ключевой метрикой: здесь это количество переходов по баннеру.
В первом случае их 15%, а во втором — 21%. Делаем вывод, что второй вариант лучше, и отправляем его в продакшен.
Этапы исследования:
- определение цели и метрики;
- определение гипотез;
- определение дизайна;
- проведение тестирования;
- анализ результатов.
Рассмотрим каждый этап подробнее на примере из моей практики. Этот кейс я разбирал в докладе на конференции Analyst Days-13.
Однажды мы с командой внедряли систему геймификации в корпоративный портал. Её суть заключалась в том, что сотрудники компании отвечали на вопросы коллег, предлагали идеи по развитию, помогали новичкам, пополняли базу знаний, участвовали в конференциях. За это они получали бонусы, которые могли потратить на призы, например, ноутбук или планшет.
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Система получилась хорошей, но спустя некоторое время пользователи стали реже заходить на сервис. Мы решили, что это повод задействовать A/B-тестирование, и внести изменения в продукт.
Сперва мы определили цель, глобальный результат, которого хотим добиться. В нашем случае, это — повысить вовлечённость. Затем выбрали метрику — показатель, по которому сможем судить о прогрессе. Для нас было важно количество баллов, заработанных пользователями за день.
На следующем этапе мы провели исследование и выяснили, что сервисом пользуются в три временных промежутка: с 9 до 10 часов утра, с 13 до 14 часов дня, и с 17 до 18 часов вечера. Решили протестировать все три периода и определить, когда лучше переводить фокус внутри портала на систему геймификации, чтобы получить лучший результат.
Далее мы разработали новый дизайн:
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
У нас есть главная страница с виджетами. Пользователи могут заходить по ним в нужные разделы или видеть на них важную информацию. Мы увеличили игровой виджет в определенные часы, а также добавили яркую кнопку и рейтинг, который, по идее, мотивирует пользователей переходить в раздел и зарабатывать баллы.
Затем началось само тестирование. Я разделил его на четыре подэтапа:
- Настройка параметров: мы определили, сколько будет длиться A/B-тестирование и как мы будем сегментировать аудиторию. Настраивали работу и систему отслеживания пользователей.
- Запуск.
- Мониторинг: мы следили, что тестирование проходит, как надо, фичи появляются тогда, когда должны, данные поступают и так далее.
- Завершение. Мы закончили тестирование спустя две недели — когда собрали достаточно данных.
В итоге мы получили такие результаты:
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.
Синим отмечены показатели до проведения A/B-тестирования — когда баннеры были стандартной величины. Красным — то что получилось, когда мы увеличивали баннер в два раза и добавляли кнопку и рейтинг.
Благодаря нашим изменениям мы увидели прирост среднего количества баллов. Вовлечённость продолжила снижаться, но уже не так быстро, как в начале работы.
Когда проводить A/B-тестирование
В заключение хочу рассказать, какие условия нужны для проведения исследования:
- Мы хотим получить объективные данные, не зависящие от мнения дизайнера или проектировщика.
- У нас большая выборка — при маленькой мы не сможем получить объективные результаты. По моему мнению, исследование уже можно проводить, если пользователей больше 500.
- У нас достаточно ресурсов. A/B-тестирование может быть очень затратным, особенно если нужно проводить его несколько раз. Мы в компании закладываем ресурсы на три итерации: если в первый раз ничего не получится, во второй получится, но не так, и только в третий раз всё пройдёт гладко.
На этом всё. Задавайте вопросы по теме и делитесь своим опытом в комментариях.
1856
Что думаете?
1 комментарий
Сначала интересные
Что за магическое количество пользователей - 500? Понятие доверительного интервала, хотя бы вкратце, не раскрыто. Хуже отсутствия тестов только тесты, проведенные или интерпретированные неправильно.