A/B-тест — это контролируемый эксперимент, в котором трафик делится между двумя вариантами одного элемента: оригиналом (A) и изменённой версией (B). Цель — измерить, какой вариант даёт статистически значимый прирост целевого действия. Без расчёта значимости любой результат остаётся случайным совпадением, а не доказанным фактом.
Формулировка гипотез
A/B-тестирование начинается не с инструмента, а с вопроса: почему конверсия сейчас такая, какая есть, и что именно мешает ей быть выше. Гипотеза — это ответ на этот вопрос в форме, которую можно проверить.
Структура рабочей гипотезы
Слабая гипотеза: «поменяем кнопку — станет лучше». Рабочая строится по четырёхзвенной схеме:
- Наблюдение — что видно в данных или записях сессий (например, 70% пользователей уходят, не добравшись до формы).
- Предположение о причине — почему это происходит (форма находится ниже первого экрана и не попадает в зону внимания).
- Изменение — что именно меняем (поднимаем форму в первый экран).
- Ожидаемый эффект — конкретная метрика и направление (CR формы вырастет минимум на 15%).
Гипотезы без наблюдения рождают «косметические» тесты — смена цвета кнопки без понимания проблемы. Данные тепловых карт, воронок и записей сессий дают наблюдения, из которых растут сильные гипотезы.
Дизайн эксперимента
Что тестировать в одном тесте
Классический A/B-тест проверяет одно изменение за раз. Если менять одновременно заголовок, изображение и кнопку — невозможно понять, что сработало. Исключение — многовариантное тестирование (MVT): оно допустимо при больших объёмах трафика и специализированных платформах.
Разделение трафика и длительность
Стандартное разделение — 50/50. Отклонение оправдано только при высоком риске варианта B (тогда пускают 80/20) или при последовательном раскатке фичи.
Минимальная длительность — полный недельный цикл, лучше два. Это нейтрализует дни недели и суточные паттерны поведения. Останавливать тест досрочно при первых обнадёживающих цифрах — распространённая ошибка: она называется «peeking problem» и производит ложных победителей.
Изоляция и рандомизация
Один и тот же пользователь должен всегда видеть один и тот же вариант. Если cookie сбрасываются или тест работает на нескольких устройствах — нужна авторизованная сессия или server-side рандомизация по ID пользователя.
Инструменты для A/B-тестирования и аналитики
| Инструмент | Тип | Когда подходит |
|---|---|---|
| VWO | Client-side / Server-side | e-commerce, лендинги, средние команды |
| Optimizely | Server-side / Feature flags | продуктовые команды, SaaS |
| AB Tasty | Client-side | маркетинг без участия разработки |
| GrowthBook | Open-source, server-side | команды со своей аналитикой |
| Яндекс.Эксперименты | Server-side | сайты в экосистеме Яндекса |
| Convert.com | Client-side / Server-side | агентства, privacy-first среды |
Client-side инструменты проще в запуске, но уязвимы к «миганию» (FOUC — flash of unstyled content): пользователь на долю секунды видит вариант A перед подменой на B. Server-side тесты лишены этого, но требуют участия разработки.
Метрики и статистика
Первичная и guardrail-метрики
Каждый тест имеет одну первичную метрику — ту, на оптимизацию которой направлен эксперимент (CR кнопки, CR формы, Revenue Per Visitor). Дополнительно фиксируют guardrail-метрики — показатели, которые не должны ухудшиться: время на сайте, процент отказов, средний чек. Победа по первичной при деградации guardrail — не победа.
Расчёт размера выборки
Перед запуском рассчитывают минимальный размер выборки. Для этого нужны четыре параметра:
- Baseline CR — текущая конверсия контроля.
- MDE (Minimum Detectable Effect) — минимальный прирост, который нужно обнаружить (обычно 10–20%).
- Уровень значимости (α) — допустимая вероятность ложного срабатывания, стандарт: 0,05.
- Мощность (1−β) — вероятность обнаружить эффект, если он есть, стандарт: 0,80.
При низком трафике имеет смысл поднять MDE до 20–30%: иначе тест займёт месяцы и потеряет актуальность раньше, чем завершится.
p-value против байесовского подхода
Частотный (frequentist) подход даёт p-value: если p < 0,05, результат считается значимым. Байесовский подход считает вероятность того, что вариант B лучше A, и позволяет останавливать тест раньше без инфляции ошибки первого рода. Для команд без штатного статистика байесовский интерфейс нагляднее: вместо «p=0,032» — «вероятность победы B: 94%».
Интерпретация результатов
Типичные ошибки
- Ранняя остановка. Тест «выглядит значимым» на третий день — это иллюзия. p-value флуктуирует, пока выборка мала.
- Множественные сравнения. При десяти вариантах один окажется «значимым» чисто случайно. Нужна поправка Бонферрони или FDR-коррекция.
- Эффект новизны. Пользователи реагируют на изменение само по себе. Прирост первой недели может исчезнуть через месяц — особенно для аудитории с высокой возвращаемостью.
- Сегментный парадокс. Общий CR может не измениться, но вариант B выигрывает на мобильных и проигрывает на десктопе. Смотрите разрезы по устройству, источнику и сегменту аудитории.
Когда результат «нет разницы»
Нулевой результат — тоже результат. Он говорит: это изменение не влияет на конверсию. Сохраняйте его в репозиторий с описанием гипотезы — иначе через полгода та же гипотеза будет протестирована повторно, потратив ресурс впустую.
Репозиторий тестов
Без системного учёта A/B-тесты превращаются в разрозненные эксперименты без накопленного знания. Репозиторий — это база, в которой каждый тест описан единообразно и доступен всей команде.
Что фиксировать по каждому тесту
- Гипотеза в полной форме (наблюдение → причина → изменение → ожидаемый эффект)
- Страница, элемент, сегмент аудитории
- Даты запуска и завершения, инструмент
- Первичная метрика и guardrail-метрики
- Результат: дельта, p-value или вероятность выигрыша, размер выборки
- Решение: внедрить / откатить / повторить с изменениями
- Инсайт — что узнали о поведении аудитории
Удобный минимум — таблица в Notion, Confluence или Google Sheets. Главное — единый формат и обязательное заполнение поля «инсайт»: именно оно питает следующие гипотезы и формирует понимание аудитории глубже, чем любой отчёт.
Приоритизация очереди тестов
Для приоритизации используют фреймворк ICE (Impact, Confidence, Ease) или PIE (Potential, Importance, Ease). Каждая гипотеза оценивается по трём осям от 1 до 10, затем считается средний балл. Тесты с наивысшим ICE идут в очередь первыми. Это убирает субъективный выбор «что тестировать» и делает очередь защищённой от HiPPO-эффекта — когда приоритет определяет человек с самой высокой зарплатой, а не данные.