А/Б тестируем по-взрослому: всю воронку от визита до оплаты с аналитикой в 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. Когда пользователь заходит на сайт, GA ставит ему куки с параметром «А» или «Б». Если пользователь делает заказ на сайте (конверсия #1) – мы просим GA дать нам этот параметр и сохраняем его в базу данных.

В итоге мы знаем, сколько заказов произошло с параметром «А» и с параметром «Б» и можем посчитать конверсии, взяв значение трафика по вариантам из Google Optimize. Схема немного усложняется за счет того, что у меня не 1 домен, а 9 и на каждом нужно запускать свой А/Б тест.

Справедливости ради, должна признаться, что одновременно один и тот же А/Б тест включаю не более чем на 4-х доменах.

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

Просто так в базу данных заглянуть нельзя – нужно просить программистов сделать выгрузку в CSV и ковырять его руками. Отвлекать программистов на такую ерунду я не люблю, поэтому мы придумали передавать параметр в аналитическую систему Tableau, которую недавно интегрировали и начали использовать для продуктовой и бизнес аналитики. Система довольно страшненькая с т.з. UI, но мощная и гибкая.

В Tableau я могу вывести на дашборд количество заявок, оплат и т.д. за любой период с любыми условиями. Строю табличку с количеством заявок и покупок по каждому домену для каждого варианта А/Б теста.

Как передавать в Tableau количество визитов из Google Optimize я пока не знаю, поэтому конверсию Визит → Заявка считаю руками в 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-ми доменах, анализируем воронку от визита до покупки». Я даже не знаю, что еще мы можем улучшить :)

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