Перейти к содержимому

A/B-тест на витрине - варианты, доли, цели, чтение результатов

Проверяем гипотезу на витрине: два варианта страницы, деление аудитории, цель теста и честное чтение результата без самообмана.

Что нужно знать заранее

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

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

Кэш готовых страниц мешает такому тесту сильнее всего остального на сайте магазина. Страница, отданная из общего кэша, показывает всем один вариант, а счётчики при этом продолжают исправно считать «участников».

Шаги

  1. Сформулировать гипотезу одним предложением и выбрать для неё одну измеримую цель.
  2. Сделать два варианта страницы, отличающихся ровно одним заметным для посетителя элементом.
  3. Разделить аудиторию поровну и запомнить выбор конкретного посетителя надолго в куке.
  4. Исключить страницу теста из кэша готовых страниц на всё время его проведения.
  5. Дождаться достаточного числа участников в каждом варианте и прочитать результат по цели.

Решение

Запоминаем вариант в куке посетителя:

$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%
# разница в полпроцента на тысяче посетителей - ещё не результат, а шум

Разница на малой выборке ничего не значит. До результата тест доводят числом участников, а не числом дней: на редком трафике честнее проверить гипотезу опросом покупателей.

Типичные проблемы

Все посетители видят один вариант.

Страница отдаётся из кэша готовых страниц целиком и одинаковой для всех. Страницу теста исключают из такого кэша на всё время проведения эксперимента.

Один человек видит то один вариант, то другой.

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

Результат теста невозможно объяснить.

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

Победитель меняется каждый день.

Участников в каждом варианте слишком мало, и разница объясняется обычной случайностью. Тест доводят до достаточного числа участников, а не до красивого числа дней.

После теста на сайте остались оба варианта.

Проигравший вариант не удалили из шаблонов и из условий вывода страницы. Уборку проигравшего варианта планируют заранее, вместе с запуском самого теста.

Частые вопросы

Сколько держать тест?

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

Можно ли тестировать цену?

Технически да, но это спорно по отношению к покупателям и по закону. Тестируют подачу цены, а не саму цену в один и тот же момент.

Мешают ли боты результату?

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

Как быть с кэшем компонентов?

Он не мешает, если вариант определяется до вывода и попадает в ключ кэша. Опасен именно кэш готовых страниц, отдающий разметку целиком.

Что делать после теста?

Оставить победивший вариант и убрать второй вместе со всей обвязкой. Незакрытый тест превращается в неявную развилку, о которой все забывают.

Смежное

Первоисточник