Когда я впервые начал изучать тему А/Б тестирования, меня очень сильно вымораживал факт, что, несмотря на факт, что в интернете куча статей и руководств по теории и практике проведения тестов, я не мог найти решение для своего, казалось бы, достаточно стандартного случая — как провести тестирование на сложной динамически меняющейся странице: например, на карточке товара в интернет-магазине или же на странице списка товаров с динамической фильтрацией.
много интернет-магазинов внедряет то или иное решение не столько потому, что 100% знают, что оно эффективно, а потому, что “так сделали конкуренты”.
Первая сотня статей и туториалов, на которые я наткнулся, содержали исчерпывающее руководство с простейшими примерами в качестве примера: как изменить лендинг или страницу корзины, или форму регистрации. Простота примера заключается в том, что все эти руководства показывали примитивный сценарий, похожий на написание программы “Привет мир” на любом языке программирования. Т.е. по факту, настолько простые, что и руководства толком не требовали, т.к. там и так все очевидно и смысла в них немного.
При этом, то решение с помощью Google Optimize, которое я в итоге использовал, меня тоже не сильно устраивало, т.к. в нем присутствовал редирект, который вносил серьезную погрешность при измерении реального поведения пользователей. Т.е. я создавал два варианта страниц, которые менялись по параметру в URL, и затем скрипт определял, какой вариант нужно показать текущему посетителю.
Если непонятно, поясню. Тому, кто первый раз попадал к вам на сайт, просто назначался какой-то вариант показа вашего теста, а для человека, который уже был ранее на сайте с начала времени проведения А/Б теста — нужно было показывать тот вариант, который ему назначили изначально. И в этот момент на один из вариантов надо было редиректить человека…а это некоторая дельта времени задержки, которая неизбежно вносит свою лепту в итоговую конверсию.
Далее буду писать текст, который я хотел бы найти тогда, когда изучал вопрос реализации проведения А/Б теста.
Сейчас для владельцев Интернет-магазинов предлагается внедрить кучу инструментов за скромную или не очень скромную оплату. Оплата может быть единоразовой, а может быть ежемесячной. Однако, по моим наблюдениям, много интернет-магазинов внедряет то или иное решение не столько потому, что 100% знают, что оно эффективно, а потому, что “так сделали конкуренты”.
Примерами таких внедрений могут быть:
- внедрение систем онлайн расчетов логистики;
- внерение омниканальной системы коммуникации;
- внедрение системы подмены телефонных номеров для настройки сквозной аналитики;
- редизайны различных блоков на сайте;
- внедрение модных сегодня систем выбора оплаты по частям;
- внедрение внешних систем умного поиска;
- внедрение различных ловцов лидов
Даже если вы не знаете сейчас, что вам то или иное внедрение принесет… то хотя бы понимание того, как вы будете измерять эффект от этого внедрения — у вас должен быть.
Иначе это не бизнес, а благотворительность.
О важности и практике настройки системы аналитики при ведении онлайн бизнеса писать я не буду — это емкая тема размером с большую книгу. А сконцентрируюсь на конкретном примере — как построить систему А/Б тестирования для динамических страниц Интернет-магазина.
Понятно, что предполагается, что на момент “сейчас” эта система у вас настроена и вы умеете считать такие показатели, как ДРР и конверсию вашей бизнес единицы в виде сайта интернет-магазина.
Общая схема проведения А/Б теста
В Яндекс Метрике есть возможность передать произвольные данные о посетителях. При этом, после того, как вы передадите эти данные, то вы сможете сегментировать своих посетителей в таком виде:
Для любого отчета вы сможете построить срез, в котором будут отображаться данные для ваших сегментов А и Б.
Например, у вас есть гипотеза, что карточка товара сильно перегружена элементами и там нужно перерисовать какой-то блок в облегченном варианте. И вы со своей командой создаете дизайн и предположим, можете на каком-то тестовом сайте видеть результат.
Теперь, чтобы запустить эксперимент, ваши программисты* должны обеспечить следующее:
*Увы и ах — в предлагаемом варианте без привлечения программиста не получится реализовать. В случае, если вы проводите такие штуки регулярно, то лучше не городить код для единичного случая, а написать свой внутренний интерфейс для проведения таких тестов.
Шаг 1 — создаем условное разделение аудитории
Создать два логических сегмента и разделить в некотором процентном соотношении, например, блок.
50% — old_block — такую метку будем давать людям, которым показывается старый вариант
50% — new_block — а такая метка будет цепляться для людей с новой карточкой.
Примечание. Если у вас крепкая уверенность, что новый блок будет работать лучше, то можете процентное соотношение сдвинуть в пользу нового блока. Например, 80/20 и т.п. В любом случае, для принятия решения, нужно достаточно большое число конверсий пользователей за время проведения теста.
Это тоже немаловажный момент. Если у вас интернет-магазин, в котором всего 20 продаж в месяц, то А/Б тесты, скорее всего, пока не для вас.
Шаг 2 — Пометим пользователей
Помечать пользователей необходимо для того, чтобы пользователь, который придет повторно, увидел бы точно такой же вариант страницы, как ранее. Некоторые пользователи, до совершения покупки, могут до 20 раз заходить к вам на сайт… и нельзя допустить, чтобы им показывался в разные посещения, разные варианты страниц.
Как “вешается” метка?
Тут пусть лучше решат ваши разработчики. Есть разные варианты реализации. Можно записать в сессию или в куки, можно привязать к профилю, если тест проводится в зоне авторизованного пользователя. Тут все индивидуально.
Главное в том, что метка вешается на посетителя один раз на время проведения теста, если ее не повесили ранее. Далее сайт должен считывать ее при очередном визите и вести себя для этого посетителя либо по сценарию old_block либо new_block.
Шаг 3 — доработаем сайт так, чтобы показывать разные варианты по меткам
Это чисто ТЗ для программистов. Они уже пометили пользователей сами. Теперь их задача, для тех, кто помечен, как old_block — показывать старый вариант карточки товара, а для new_block, соответственно, новый.
Шаг 4 — размещаем код js для отправки данных параметра визита в Яндекс Метрику
Ну и самое важное. Для каждого визита, мы сообщаем в Яндекс метрику его метку.
Этот пункт описан в документации Метрики https://yandex.ru/support/metrica/data/visit-params_example.html
Ниже скриншот примера кода. в нашем случае это будет код примерно такой:
Ну а далее все просто. Ждем, когда число желаемых конверсий по каждому из вариантов выйдет за пределы влияния случайностей. По хорошему, должно быть не менее 100 конверсий в варианте с мЕньшим трафиком. Тогда можно будет делать хоть какие-то выводы.
Если у вас большой трафик и цена ошибки высока, то делать можно А/Б/А тестирование. Его суть в том, чтобы создать не два, а три сегмента, только в первый и третий сегмент — полностью одинаковые по виду для пользователя, но при этом разделенные по регистрации поведения сегментами.
Такое разделение позволит вам определить время, когда количество собранных данных по эксперименту будет достаточным для окончательных выводов по эффективности вашего эксперимента.
Если нужна помощь или консультация, или есть желание покритиковать, не стесняемся, пишем в комментарии или в личку по контактам.