A/B-тест на витрине - варианты, доли, цели, чтение результатов
Проверяем гипотезу на витрине: два варианта страницы, деление аудитории, цель теста и честное чтение результата без самообмана.
Что нужно знать заранее
Тест проверяет одну гипотезу и одно изменение. Два переделанных блока сразу дают результат, который невозможно объяснить: непонятно, что именно сработало и что оставлять на сайте.
Посетитель обязан видеть один и тот же вариант страницы при каждом заходе. Иначе человек попадает то в один вариант, то в другой, и статистика превращается в шум с красивыми, но бессмысленными числами.
Кэш готовых страниц мешает такому тесту сильнее всего остального на сайте магазина. Страница, отданная из общего кэша, показывает всем один вариант, а счётчики при этом продолжают исправно считать «участников».
Шаги
- Сформулировать гипотезу одним предложением и выбрать для неё одну измеримую цель.
- Сделать два варианта страницы, отличающихся ровно одним заметным для посетителя элементом.
- Разделить аудиторию поровну и запомнить выбор конкретного посетителя надолго в куке.
- Исключить страницу теста из кэша готовых страниц на всё время его проведения.
- Дождаться достаточного числа участников в каждом варианте и прочитать результат по цели.
Решение
Запоминаем вариант в куке посетителя:
$response = \Bitrix\Main\Context::getCurrent()->getResponse();$variant = $_COOKIE['ab_checkout'] ?? (random_int(0, 1) ? 'B' : 'A');$response->addCookie(new \Bitrix\Main\Web\Cookie('ab_checkout', $variant, time() + 2592000));// месяц жизни куки: посетитель видит один и тот же вариант при возвратахКука решает главную задачу теста: постоянство варианта для человека. Без неё результат меряет не гипотезу, а случайность, и решение по такому тесту принимать нельзя.
Показываем нужный вариант:
if ($variant === 'B') { $APPLICATION->IncludeComponent('bitrix:sale.order.ajax', 'one_step', $params);} else { $APPLICATION->IncludeComponent('bitrix:sale.order.ajax', 'classic', $params);}// вариант - это шаблон компонента или отдельная страница, а не десяток условийВариантом удобнее делать отдельный шаблон, а не набор условий в разметке. Условия расползаются по файлу и остаются в нём навсегда, а лишний шаблон удаляют одной командой после теста.
Исключаем страницу из кэша готовых страниц:
$APPLICATION->SetPageProperty('composite_frame_mode', 'no');// иначе всем посетителям достанется вариант того, кто зашёл первымСчитаем цель теста:
document.querySelector('#order-submit').addEventListener('click', () => { window.dataLayer?.push({ event: 'ab_goal', variant: document.body.dataset.abVariant });});// вариант передают в аналитику вместе с событием цели, иначе разделить выборки нечемЦель обязана быть одна и измеримая: оформленный заказ, отправленная форма, переход в корзину. «Стало красивее» целью теста не является и в отчёте никак не появляется.
Читаем результат честно:
Вариант A: 1200 посетителей, 48 заказов → 4,0%Вариант B: 1190 посетителей, 55 заказов → 4,6%# разница в полпроцента на тысяче посетителей - ещё не результат, а шумРазница на малой выборке ничего не значит. До результата тест доводят числом участников, а не числом дней: на редком трафике честнее проверить гипотезу опросом покупателей.
Типичные проблемы
Все посетители видят один вариант.
Страница отдаётся из кэша готовых страниц целиком и одинаковой для всех. Страницу теста исключают из такого кэша на всё время проведения эксперимента.
Один человек видит то один вариант, то другой.
Выбор варианта не сохраняется между заходами одного и того же посетителя. Вариант записывают в куку посетителя с длинным сроком жизни, на месяц.
Результат теста невозможно объяснить.
В варианте изменено сразу несколько заметных элементов страницы вместо одного. Тест проверяет одну гипотезу и ровно одно заметное изменение страницы.
Победитель меняется каждый день.
Участников в каждом варианте слишком мало, и разница объясняется обычной случайностью. Тест доводят до достаточного числа участников, а не до красивого числа дней.
После теста на сайте остались оба варианта.
Проигравший вариант не удалили из шаблонов и из условий вывода страницы. Уборку проигравшего варианта планируют заранее, вместе с запуском самого теста.
Частые вопросы
Сколько держать тест?
До набора нужного числа участников по каждому варианту, а не фиксированное число дней. На низком трафике тест может не набрать выборку вовсе.
Можно ли тестировать цену?
Технически да, но это спорно по отношению к покупателям и по закону. Тестируют подачу цены, а не саму цену в один и тот же момент.
Мешают ли боты результату?
Да, поэтому визиты роботов исключают из подсчёта. Иначе один активный обходчик перекашивает выборку целиком.
Как быть с кэшем компонентов?
Он не мешает, если вариант определяется до вывода и попадает в ключ кэша. Опасен именно кэш готовых страниц, отдающий разметку целиком.
Что делать после теста?
Оставить победивший вариант и убрать второй вместе со всей обвязкой. Незакрытый тест превращается в неявную развилку, о которой все забывают.
Смежное
- Шаблон сайта - оглавление подтемы
- Шаблон под раздел и по условию - как показать другой шаблон части посетителей
- Композитный сайт: включение, динамические области, сброс - почему кэш страниц ломает тест
- Электронная торговля в аналитике: события, покупка, сверка - откуда берутся цели и события
- Состояние посетителя в куках: запись, чтение, защищённая кука - как правильно хранить выбор варианта
- Оформление заказа: настройка компонента и правка шаблона - типовое место для такого теста
- Компоненты и шаблоны - устройство шаблонов целиком