Про A/B-тесты уже не просто слышали, их вам, скорее всего, успели прописать как панацею от всех маркетинговых бед. В каждом втором блоге, на каждом третьем вебинаре и в каждом первом чек-листе: "Тестируйте! Сравнивайте! Побеждайте!"

Да, всё это правда. Да, A/B-тесты важны. Но делать их по-настоящему мало кто почему-то умеет (это мое оценочное суждение на основе опыта взаимодействия, а не аналитика рынка, но все же).

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

А теперь, давайте еще проще, без воды и лишней теории (хотя я так не считаю, что она лишняя), на примере конкретного кейса разберем, как быстро и без боли запустить A/B-тест через Яндекс.Метрику и куки. Даже если вы не дата-сайентист и не гуру аналитики.

А в своем Телеграм канале пишу еще больше про всякое из реального маркетинга.

Итак приступим этапность проведения любого теста такая:

1. Понять, что тест мы все-таки проводим и на какую гипотезу

2. Понять сколько времени будем проводить и какой результат статистически значимый

3. Дело техники: запустить скрипт разделения трафика и начать собирать статистику

4. Анализируем полученный результат

Понимаем, что тест мы проводим и выдвигаем гипотезу

Чтобы это действительно был тест, а не «ощущения маркетолога», нужны три вещи:

• Гипотеза — это ваша идея: «Если мы поменяем Х, то улучшится Y». Например: «Если поменяем цвет кнопки на красный, CTR вырастет».

• Нулевая гипотеза (H₀) — скучная, но нужная: «Никакой разницы между вариантами нет». Именно против неё мы и «воюем».

• Альтернативная гипотеза (H₁) — а вот она уже интересная: «Разница есть, и красная кнопка — топ».

Чтобы было интересней давайте разбираться на живых примерах. Самый частый пример АБ-тестов это либо целиком лендинги (что странно, т.к. там полно факторов влияющих на принятие решение и тем не менее так часто делают, как входной тест), либо важные разделы лендингов. Чаще всего CTA блоки. Вот давайте возьмем такой пример.

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

Отсюда вытекают уже следующие понятия: Вариант А - старый блок CTA без изменений и Вариант Б - новый блок с идеями от гуру UX.
Вариантов всего 2, значит делить пользователей будем на 2 группы. Одним показывать одно, другим другое.

Сколько времени будем тестировать?

Теперь надо понять (тавтология) а как мы вообще-то поймем, что тест удачный или нет? И через сколько поймем?

Для этого все-таки потребуется немного теории, но реально чуть-чуть. Вот такие понятия нам сейчас потребуются:

• Случайное распределение — равновероятное назначение в группы.

• Уровень значимости (α) — вероятность ложноположительного результата. Не паримся и всегда берем 5%, так говорят делать классики, а кто мы такие чтобы быть против.

• Минимальный значимый прирост (MDE) — минимальный прирост, который можно достоверно зафиксировать.

• Статистическая значимость — достаточная уверенность, что разница не случайна.

• Мощность теста (1 - β) — вероятность обнаружить реальный эффект. Не паримся и берем 80%, тоже самое что и с α.

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

Пусть они будут такие:

• Период (полный месяц до даты замера) - 01.04.2025 - 30.04.2025

• Всего визитов - 17 509

• Целевые визиты (визиты в которых достигли цели заявки) с конкретного лендинга - 917

• Конверсия - 917/17509 = 5% (0,0524)

• Уровень значимости (α - константа всегда берем 5%): 5%

• Распределение 50/50

Расчет минимального значимого прироста конверсии (MDE):

Рассчитываем по формуле:

Где:

• p — конверсия (0,0524)

• n — количество визитов в каждой группе (17 509)

• Zα/2=1.96 — квантиль нормального распределения для 5%. Это константа, просто подставляем ее всегда и не заморачиваемся со сложным словом квантиль

• Zβ=0.84 — квантиль для мощности 80%. Аналогично.

Подставим:

Минимально статистически значимый прирост ≈ 0,00667 или 0,67 п.п.

(от 5,24% до 5,91%) — +12,7% прирост по отношению к текущей конверсии.

Почему необходимы статистические расчеты тестов?

Зачем рассчитывать минимальное время проведения теста (MDE)? А вот чтобы не проводить тесты слишком долго или слишком быстро.

Проблема 1: Если остановить A/B-тест слишком рано, результаты могут быть случайными — просто из-за удачи или неудачи в начале.

Проблема 2: Тест уже можно останавливать из-за увеличения трафика на страницу (по любой причине), а мы будем продолжать крутить его.

Зачем рассчитывать статистически значимый прирост

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

Лайвхак: всего этого вам считать не придется, просто воспользуйтесь промптом для chatgpt, по следующему шаблону:

Рассчитай для меня АБ-тест.

Лендинг А:

Период замера 01.04.2025 - 30.04.2025

Всего визитов - 17 509

Заявки - 917

Конверсия - 5%

Уровень значимости α - 5%

Мощность теста (1-β) - 80%

Распределение 50/50

Ладно, отвлеклись, что у нас есть: тест рассчитан на проведение на выборке в 17 509 визитов и статистически значимый прирост конверсии должен составить +12,7%. При такой посещаемости, понимаем, что тест будет длиться примерно 1 месяц. Если необходимо тест провести быстрее, необходимо увеличить трафик. На величину этого трафика меняем данные в расчете.

Дело техники, делим трафик на лендинге и собираем статистику

Здесь я сразу подготовил для вас js скрипт, который будет работать просто в коде сайта или в GTM. Конечно, не без адаптации но тем не менее/ давайте его разберем.

document.addEventListener("DOMContentLoaded", function () {
    // Функция для установки куки
    function setCookie(name, value, days) {
        var date = new Date();
        date.setTime(date.getTime() + (days * 24 * 60 * 60 * 1000));
        document.cookie = name + "=" + encodeURIComponent(value) + ";expires=" + date.toUTCString() + ";path=/";
    }

    // Функция для получения куки
    function getCookie(name) {
        var matches = document.cookie.match(new RegExp(
            "(?:^|; )" + name.replace(/([.$?*|{}\\()\[\]\\/\\+^])/g, '\\$1') + "=([^;]*)"
        ));
        return matches ? decodeURIComponent(matches[1]) : undefined;
    }

    // Определение группы пользователя
    var abTestCookie = getCookie('abtest');

    if (!abTestCookie) {
        abTestCookie = Math.random() > 0.5 ? 'A' : 'B';
        setCookie('abtest-presto', abTestCookie, 365);
    }

    // Перенаправление пользователей в зависимости от группы
    if (abTestCookie === 'A') {
        window.location.href = 'https://site.ru/?var=A';
    } else {
        window.location.href = 'https://site.ru/?var=B';
    }

    // Дождаться загрузки скрипта Яндекс.Метрики
    function waitForYandexMetrika(callback) {
        if (typeof ym !== 'undefined') {
            callback();
        } else {
            setTimeout(function () {
                waitForYandexMetrika(callback);
            }, 100);
        }
    }

    waitForYandexMetrika(function () {
        var abGroup = getCookie('abtest-presto');
        if (abGroup) {
            ym(YOUR_METRIKA_ID, 'params', {
                ab_group: abGroup
            });
        }
    });
});

Скрипт:

1. Определяет, попал ли пользователь в группу A или B (если ещё не попадал — определяет случайно).

2. Сохраняет выбор в cookie abtest.

3. Редиректит пользователя на нужный URL в зависимости от группы.

4. Ждёт загрузки Яндекс.Метрики и передаёт туда имя группы как пользовательский параметр.

Простой, рабочий A/B-тест с делением пользователей, редиректом и логированием группы в Яндекс.Метрике. Для MVP или быстрого эксперимента — отличное решение. Но для продвинутых целей (сегментация, сбор конверсий, аналитика отказов) — нужно доработать механику редиректа и учёт событий.

Что получается по итогу в Метрике?

Самое главное, что спустя рассчитанное время мы идем и снимаем статистику. Не через день, не через неделю, а равно через столько сколько сказала математика. Нет снимать статистику и следить за течением теста можно, никто не запретит, но остерегайтесь ложных выводов, которые так хочется принять на раннем сроке увидев, например разрыв в 50 конверсий на одной из версий. В отчете параметров визитов видим вот такую картину. (Уж простите замазал название параметра).

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

Чтож, вывод здесь один, победила нулевая гипотеза, две версии абсолютно идентичны для пользователей. Наш АБ-тест помечается завершенным, гипотеза не успешной, а очередная книга очередного UX гуру отправляется в помойку. Но мы не отчаиваемся а идем дальше.

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