Как проводить A/B-тесты на сайте и оценивать результаты в Google Analytics

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

Руководитель IT-проектов Email Soldiers Иван Дудин провёл на эту тему вебинар с практической частью. Для тех, кто пропустил онлайн-встречу, мы подготовили подробный конспект.

---

Наше агентство создаёт CRM-коммуникации, которые включают взаимодействие с пользователем на сайте. Мы реализуем такие коммуникации с помощью всплывающих или встроенных виджетов, модификации существующего контента, переработки user flow (путь пользователя) на сайте. Это множество разных механик:

• лидогенерация;
• информирования;
• social proof-виджеты;
• чат-боты;
• коллбэки;
• подписки на push-уведомления;
• квизы;
• виджеты, транслирующие контент социальных сетей, и прочие.

Внедрение и изменения этих механик могут оказывать как положительное влияние, так и отрицательное, а могут вообще никак не влиять на конверсию.

Читайте также

12 принципов для A/B-тестирования

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

• сама по себе работает эффективно;
• не ухудшает ключевые показатели;
• не снижает конверсию.

Часто случается так, что сама по себе механика работает хорошо: подписывает, собирает заявки, отправляет пользователей в нужную воронку. Однако в тени может оставаться неисследованная её сторона. Например, положительный эффект может быть временным или однобоким, то есть снижать другие показатели сайта.

Чтобы подтверждать эффективность механик, мы используем A/B-тесты двух видов:

1. Сравнение разных вариантов одной механики (например, разные заголовки в блоке, цвет кнопки у лидген-формы, таргет у виджета). Это самый распространённый вариант тестирования на сайтах.
2. Сравнение с контрольной группой. Когда сравниваем вариант с изменениями и вариант без изменений: делим всю аудиторию сайта на равные группы (две, три, четыре), при этом одна из них остаётся контрольной, а по остальным мы включаем механики, эффективность внедрения которых хотим проверить. Такие тесты делают немногие, а инструментов под эти цели меньше, чем для проведения простых A/B-тестов с вариантами. Однако мы отдаём предпочтение именно тестам с контрольной группой, ведь в первую очередь важно понять, нужны ли вообще изменения. И только потом сравнивать варианты этих изменений.

Для чего мы проводим A/B-тесты

Причин для A/B-тестирования несколько:

1. Показать заказчику, что наши механики приносят ему профит — деньги или другую ключевую метрику.
2. Быть уверенными в качестве внедряемых механик.
3. Нарастить собственную экспертизу и опыт.

Наши требования к способу тестирования

Нам важно, чтобы тесты были:

• достоверными и прозрачными — выводы должны быть честными;
• просты в реализации — с минимальным набором инструментов;
• без дорогих внешних решений;
• максимально быстрыми (насколько это вообще возможно для A/B-тестов).

На рынке ПО есть много решений, позволяющих проводить тестирование сайтовых механик какого-то одного или обоих видов. Среди них:

• Retail Rocket Segmentator;
• Mindbox;
• Exponea;
• Flocktory;
• Insider;
• Google Optimize;
• Optimizely;
• ChangeAgain;
• ABTasty;
• Roistat.

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

Проблемы, с которыми мы столкнулись в A/B-тестировании для заказчиков

Не вся аудитория сайта попадала в сегменты теста

Обычно в сегменты не попадают пользователи-отказники, которые провели на сайте всего 3-4 секунды, или боты. Как правило, эти люди не совершают заказов, поэтому мы решили, что если их меньше 5%, то ими можно пренебречь.

Читайте также

Не количеством, но качеством. Как увеличить целевой трафик на сайт

Семплирование при построении отчётов

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

Сэмплирование — это способ выборки данных, на основании которых будет построена отчётность. При сэмплировании для построения отчёта используется только часть данных за период. Высокий процент сэмплирования негативно влияет на достоверность. Чтобы избежать семплирования, мы используем скрипт на R и отчёт в Power BI.

Проблемы с количеством и суммой заказов

Чаще всего эти проблемы связаны с тем, что сотрудники магазина с одной учётной записи делают много заказов. Во избежании этого нужно настроить Google Analytics так, чтобы в неё не попадали сотрудники офиса.

Некорректные настройки Google Analytics

Например, когда счётчик Google Analytics установлен дополнительно на постороннем сайте и собирает смешанную статистику одновременно с двух ресурсов.

Проблемы самих механик

Например, механики с плохой адаптивностью или проблемами в вёрстке.

Читайте также

HTML вёрстка писем — полная инструкция

Ошибки при проведении тестов, которые могут возникнут на старте

Анализ отчётов без деления на десктопную/мобильную аудитории

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

Неудачный выбор показателей

Например, показатели с большой амплитудой, экстремумами — на них нельзя строить корректные отчёты.

Недостаточное время тестирования, оперирование недостаточным количеством данных

Не нужно торопиться, лучше потратить больше времени на тест, но быть уверенными в результатах.

Изменение параметров тестов в процессе

Если что-то меняете в параметрах теста: во внешнем виде, контенте, настройках условий показа, таргетинге показа, — нужно перезапускать счётчик заново.

Ложные выводы при анализе результатов

Понимание, на какие показатели не стоит опираться, пришло к нам с опытом.

Что понадобится для проведения теста

1. Сайт.
2. Предмет тестирования — в практической части вебинара мы тестируем два вариант виджета подписки.
3. Гипотеза или, иными словами, предположение, которое мы хотим проверить с помощью теста — в нашем случае их два:
   • виджет не просаживает главные показатели сайта (проведённое на сайте время, глубина просмотра, показатели отказов, количество заказов, иногда — деньги);
   • какой из вариантов виджета лучше выполняет цель.
4. Шаблон отчёта — это документ, в котором фиксируется всё:
   • A/A-тест: когда начали/закончили, результаты, выводы;
   • первый A/B-тест (A/B/C-тест): что тестировали, с каким дизайном, настройками, когда начали/закончили, отчёты по статистике.

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

5. Установленные на сайт Google Analytics и GTM.
6. Инструмент проведения тестов. Мы используем собственный сервис Lead Plan, через который чаще всего вносим изменения на сайтах заказчиков.

Настраиваем сегментацию аудитории для тестирования.

Реализация механизмов проходит в три шага.

Деление аудитории сайта на сегменты

Делим пользователей на равные части «по головам», а не по сессиям: один и тот же пользователь должен попадать в один и тот же сегмент в течение всего теста.

Передача идентификаторов сегментов в GA

При попадании в сегмент каждый пользователь получает в браузере идентификатор, который передаётся в Google Analytics.

Таргетирование механик на определённые сегменты

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

Читайте также

Разделяем клиентов по лояльности с помощью RFM-анализа

Зачем нужен A/A-тест (A/A/A-тест)

Мы делим всю аудиторию сайта на равные части, но не для того, чтобы им что-то показывать. Так мы определим время, которое необходимо для равномерного распределения пользователей по ключевым параметрам. Обычно A/A-тест длится 1-2 недели, за это время как раз можно спланировать и согласовать параметры A/B-теста (A/B/C-теста). Результат A/A-теста фиксируется в отчёте.

---

Практическую часть по настройке A/B-теста с помощью Google Analytics, Google Tag Manager и «Яндекс» Метрики вы можете посмотреть в записи вебинара на нашем Youtube-канале. Подсказки по настройкам вы также найдёте в презентации.

---

В нашем Телеграм-канале Маркетинг за три минуты мы пересказываем самые интересные материалы про онлайн-маркетинг в формате постов-трёхминуток — подписывайтесь и будьте в курсе. А если вы хотите поболтать и поделиться своими мыслями, приходите к нам в CRM-Chat.