Всё, что работает на фронте, теперь моё: A/B-тесты в Вариокубе глазами UX-исследователя

Привет, Хабр! Меня зовут Ирина, я UX/CX-исследователь в отделе RnD финтех-компании. Мы разрабатываем много всего нового, много тестируем, пробуем и изучаем. Я провожу качественные и количественные исследования и запускаю A/B-тесты.

Расскажу, как Вариокуб от Яндекса позволил мне самой запускать тесты, на которые раньше уходили недели разработки, и поделюсь граблями, на которые наступила по дороге. И объясню, почему, на мой взгляд, простые A/B-тесты должен уметь запускать и читать каждый исследователь.

Гипотез много, разработка одна

В RnD гипотез всегда больше, чем рук, чтобы их проверить. В компании было два варианта тестов: через флаги функциональности и через Вариокуб. Через Яндекс быстрее: простой тест, например поменять цвет кнопок или тексты, может запустить любой неспециалист. Всё более сложное всегда делалось через разработку, а там спринты, согласования, очередь. В идеальном варианте только разработка теста затягивалась на 2–3 недели, в более сложных случаях и того дольше. А ведь после разработки тест надо ещё запустить и дождаться результатов. От идеи до ответа легко проходило полтора-два месяца.

Как я пришла в A/B-тесты и нашла в Вариокубе JS

A/B-тесты меня давно интересовали, но полноценно в них погрузиться, научиться собирать, читать и применять не было возможности. А у нас в компании A/B-тесты как раз на RnD-отделе, поэтому я с радостью взяла их на себя и с каждым тестом прокачивала свои скилы. Увлекательное, однако, занятие.

Я не проходила специальных обучений, мне показали куда тыкать, а дальше нужная информация и нейронки в свободном доступе. В визуальном редакторе есть возможность подключить JS для более сложных задач, о чем я и попросила разрабов, ну а дальше началась магия. Базовую разработку я знаю, плюс есть нейронки, которые неплохо пишут код, так что теперь я могу писать JS на сайте всегда, когда нужен тест. Поп-апы, баннеры, дополнительные блоки, флаги для Метрики на время теста, закреплённые и перемещённые кнопки и много всего другого – всё это я теперь делаю сама, понятно, что бэкенд я не приделаю, но всё, что работает на фронте, теперь моё, то на что раньше мог уйти месяц, я делаю за день.

Чтобы было понятно, где теперь проходит граница: что я делаю сама через Вариокуб, а что по-прежнему идёт через разработку.

Да, Вариокуб работает только для сайтов, но в целом закрывает очень большой пласт работы.

Как это выглядит на практике: поп-ап против баннера

Бизнес пришёл с запросом: нужно было проверить, увеличится ли конверсия в целевое действие, если предложить его пользователю поп-апом, и не упадёт ли при этом конверсия всей страницы. Боялись, что поп-ап будет раздражать и конверсия страницы сильно упадёт.

Я сравнивала три варианта:

И две метрики: основная – конверсия в целевое действие, вторая – общая конверсия страницы, чтобы видеть, не вредит ли вариант странице в целом. Оба новых элемента я сделала через JS, клики по ним писались в одну и ту же цель Метрики, иначе варианты не сравнить.

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

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

Что я узнала на каждом этапе теста

1. Ограничения JS в 2000 символов

Каждый тест неповторимый: каждый раз надо работать с ограничениями Вариокуба, самое заметное – лимит в 2000 символов на код. Иногда это даже весело: смотришь и думаешь, где же ещё можно сократить, кажется, что такой лимит – это очень мало, но по факту, ты же пишешь не целую страницу, а добавляешь небольшой элемент.

2. Перед запуском: смотреть глазами на всех устройствах

Сделанное для десктопа может не работать в мобилке и наоборот. На одном из тестов на десктопе всё отрабатывало, а в мобилке никак. Я пробовала выловить ошибку по этапам, всё равно ни в какую, поэтому я скормила ИИ всю ссылку превью, и выяснилось, что Вариокуб при сохранении молча съедает двойные подчёркивания в коде. Теперь я смотрю, как каждый тест отрабатывает на разных устройствах, вылавливаю ошибки и записываю их, чтобы потом не повторять.

3. Пока тест идёт: не подглядывать

Тесты периодически показывают интересные вещи, которых ты совсем не ждёшь. Например, запускаешь на тест две одинаковые страницы, а на второй в первые дни статистически значимо падает конверсия, это пример того, что тест нельзя останавливать в первые 2–3 дня, как только он прокрасился, надо ждать хотя бы 2 полных недели.

Это называется A/A-тест. Ложная значимость в первые дни – нормальное явление: данных мало, а каждое «подглядывание» в результат увеличивает шанс ложноположительного вывода. Полные недели нужны, чтобы захватить все дни с разным поведением пользователей.

4. Когда тест вообще не нужен

Бывает, что ты видишь: это правда будет работать лучше и без теста, и лучше сразу внедрить, но надо доказать на своих цифрах, потому что если у них сработало, не факт, что сработает у нас.

Почему каждому исследователю стоит это уметь

Не каждый UX-исследователь запускает A/B-тесты, но я считаю, что важно уметь делать хотя бы простые через Вариокуб, понимать суть и уметь читать результаты, иначе какой вы специалист по юзабилити?

На интервью люди часто приукрашивают, чтобы казаться лучше, а иногда просто врут. A/B-тест на живой аудитории показывает, что люди на самом деле делают чаще. Тесты через Вариокуб ускоряют проверку гипотез, а время сейчас – самый ценный ресурс.

Про вайбкодинг и то, как я пишу скрипты с ИИ, расскажу в отдельной статье. А пока интересно, как у вас: исследователи сами запускают тесты или отдают аналитикам?