23 января 2020

А/Б тестируем по-взрослому: всю воронку от визита до оплаты с аналитикой в Tableau и не только

Ольга Шаврина
Стали сохранять параметр «А» или «Б» в базу данных; прикрутили систему аналитики Tableau, благодаря чему научились отслеживать всю воронку: визит → заявка → предложение → оплата; научились смотреть сводную кросс-доменную аналитику; освоили редирект А/Б тесты без перезагрузки страницы.
А теперь обо всем по порядку
О том, что мы очень любим А/Б тесты и все время их гоняем в Google Optimize, я писала ранее тут и тут. О том, что площадка для А/Б тестирования – это наш боттлнек и мы стараемся его максимально загружать при приоритизации и планировании – здесь.
Вкратце напомню. Мы – «Airbnb для яхт» nautal.com. У нас 9 доменов: com, es, de, fr, ru, it, nl, br, gr. Если сложить весь трафик, то в низкий сезон получается около 400к посетителей в месяц, в высокий сезон – около 1.2м. Бизнес сезонный, средний чек измеряется тысячами евро, конверсии зависят от погоды и культурных особенностей пользователей, поэтому А/Б тестировать очень весело :)
В чем проблема?
В качестве цели в Google Optimize можно брать только событие на сайте, например, посещение страницы или отправка заявки, но адекватно отследить всю воронку продаж не получалось. Т.к. пользователи оплачивают заказ через пару недель после заявки, зачастую с другого устройства или вообще оффлайн банковским переводом, а Google Optimize про это не знает.
В Google Optimize можно тестировать только верх воронки – то, что пользователь может делать на сайте за 1-2 сессии
Что мы придумали
Включаем А/Б тест в Google Optimize. Когда пользователь заходит на сайт, GA ставит ему куки с параметром «А» или «Б». Если пользователь делает заказ на сайте (конверсия #1) – мы просим GA дать нам этот параметр и сохраняем его в базу данных.

В итоге мы знаем, сколько заказов произошло с параметром «А» и с параметром «Б» и можем посчитать конверсии, взяв значение трафика по вариантам из Google Optimize. Схема немного усложняется за счет того, что у меня не 1 домен, а 9 и на каждом нужно запускать свой А/Б тест.
Справедливости ради, должна признаться, что одновременно один и тот же А/Б тест включаю не более чем на 4-х доменах.
Имея в базе данных параметры «А» и «Б», мы можем посчитать и все остальные конверсии – из заявки в отправку предложения, в покупку и др. по каждому варианту. Так как Google Optimize к этому уже отношения не имеет, для нас не важно стоит ли у посетителя в браузере куки, заплатил ли он с другого устройства или вообще перевел деньги оффлайн через банк трансфер (а это случается часто, т.к. средний чек измеряется тысячами евро).
Как я смотрю аналитику
Просто так в базу данных заглянуть нельзя – нужно просить программистов сделать выгрузку в CSV и ковырять его руками. Отвлекать программистов на такую ерунду я не люблю, поэтому мы придумали передавать параметр в аналитическую систему Tableau, которую недавно интегрировали и начали использовать для продуктовой и бизнес аналитики. Система довольно страшненькая с т.з. UI, но мощная и гибкая.

В Tableau я могу вывести на дашборд количество заявок, оплат и т.д. за любой период с любыми условиями. Строю табличку с количеством заявок и покупок по каждому домену для каждого варианта А/Б теста.
Дашборд в Tableau. Верхняя таблица – заявки, нижняя – оплаты. По строкам расположены варианты А/Б теста, по столбцам – домены
Как передавать в Tableau количество визитов из Google Optimize я пока не знаю, поэтому конверсию Визит → Заявка считаю руками в Excel по каждому домену, плюс суммарно по всему сайту. Дешево и сердито.
Табличка в Excel, в которой я свожу результаты А/Б теста и считаю суммарную конверсию
Редирект А/Б тест без перезагрузки страницы
Решили прокачаться не только вглубь, но и вширь и научиться тестировать лейаут целиком. На прошлой неделе запустили первый пробный А/Б тест с двумя совершенно разными дизайнами страницы лодки:
Старый и новый дизайн страницы продукта
Изначально идея была использовать URL redirect A/B test в Google Optimize. Но оказалось, что в этом случае GA перезагружает страницу, и это занимает пару лишних секунд. Для нас, как для маркетплейса, скорость загрузки страницы критична.

Вторым противопоказанием для использования редиректа было SEO. Органическая выдача Google – наш основной источник траффика, поэтому с SEO мы не шутим. Узнав о том, что я хочу запустить redirect A/B test, наш SEO-шник разволновался, выставил 100500 требований и попросил согласовывать с ним каждый шаг так, чтобы он смог мониторить позиции ключевых слов 24/7 и в случае, если что-то пойдет не так – немедленно отключить тест.

Поэтому мы придумали…
Описанный ниже лайфхак подходит для теста внутренней страницы сайта, т.е. страницы, которая не является лендингом – первой страницей, которую видят посетители при заходе на сайт.
… поэтому мы придумали использовать Optimize только для разделения трафика, а вместо редиректа программно подменять лэйаут страницы, используя поставленные куки.

Работает это так – в Google Optimize создаю эксперимент с двумя вариантами «А» и «Б». В самих вариантах ничего не меняю. Настраиваю таргетинг на страницу списка лодок – это основная страница на которую приходит трафик и, по большому счету, только этот трафик нам и интересен.

Посетитель заходит на страницу списка лодок, Google Optimize ставит ему куки «А» или «Б». В тот момент, когда посетитель кликает на карточку лодки, мы проверяем куки и решаем, какой дизайн ему показать. Если видим куки «А» – то старый, если «Б» – то новый. Никакой перезагрузки, все бесшовно. Вуаля!

Когда пользователь отправляет заявку, сохраняем значение «А» или «Б» в базу данных, чтобы, как было описано выше, посчитать потом конверсии для всей воронки.
Результаты на сегодняшний день
Google Optimize оказался полезной штукой, если им аккуратно пользоваться. А в связке с Tableau и пряморукими программистами с ним можно творить чудеса. Важно тщательно тестировать каждый эксперимент и постоянно наблюдать за конверсиями, потому, что довольно легко накосячить и получить получить неверный результат (а то и вообще сломать сайт).

В итоге, за год мы продвинулись от состояния «выкатываем и забываем» до «постоянно тестируем на 7-ми доменах, анализируем воронку от визита до покупки». Я даже не знаю, что еще мы можем улучшить :)

Следующим шагом, наверное, будет технология тестирования мобильного приложения. Пока понятия не имею, с какой стороны к этому подходить. Буду рада, если поделитесь идеями и ссылками о том, где об этом почитать.
Нажимая на кнопку, вы даете согласие на обработку своих персональных данных и соглашаетесь с политикой конфиденциальности
Made on
Tilda