A/B тестирование интерфейсов

Введение

A/B тестирование — это контролируемый эксперимент, где две (или больше) версии интерфейса сравниваются на реальных пользователях, чтобы понять, какая версия приводит к лучшим продуктовым метрикам. Цель — снижать неопределенность при принятии решений и улучшать UX через проверяемые изменения, а не мнения.

Когда уместно A/B-тестирование

Есть измеримая цель (конверсия, время до действия, удержание, NPS, скорость задачи).
Ожидаемый эффект неочевиден или может отличаться по сегментам.
Риск изменения достаточно высок, чтобы оправдать эксперимент.
Трафик позволяет быстро собрать статистически значимую выборку.

Когда лучше не тестировать: микрокопии на малоиспользуемых экранах, фичи с сильной сетевой/социальной зависимостью (перелив эффектов), правки, требующие длительного обучения пользователей.

Формулировка гипотезы

• Если мы изменим [X в интерфейсе] для [Y-сегмента/всех], то [метрика Z] изменится на [направление/величина] потому что [поведенческая причина].

Пример: Если перенести основной CTA выше линии сгиба и сократить форму с 6 до 3 полей, то CR первичного действия вырастет на +3–5% за счет снижения трения.

Метрики: целевые и защитные

Primary (основная): одна ключевая — например, завершения целевого сценария / конверсия.
Secondary: глубина скролла, CTR, время до действия, ошибки, скорость страницы.
Guardrails (защитные): стабильность производительности (TTFB, LCP), возвраты/отказы, жалобы/откаты, соблюдение лимитов уведомлений, доступность.

Рекомендуется заранее зафиксировать MDE (минимально детектируемый эффект), окно наблюдения и критерии успешности.

Дизайн эксперимента

Рандомизация и единица анализа

Единица рандомизации: пользователь (user_id), иногда — сессия или организация (кластер).
Стратификация/блокировка: по устройствам/каналам, если есть сильные различия.
Перелив (interference): избегайте, когда поведение одной группы влияет на другую (например, общие списки/ленты). В таких случаях — кластерные тесты.

Размер выборки и MDE (упрощенно)

Приближенно: чем ниже базовая конверсия и чем меньше эффект, тем больше выборка.
Для CR ~10% и MDE ~+5% относительного эффекта нередко требуется десятки тысяч наблюдений на вариант.

Длительность

Ориентируйтесь на полный недельный цикл поведения + запас (обычно 2–4 недели) или до достижения запланированной мощности. Не останавливайте тест преждевременно.

Рамп-ап (постепенный вывод)

1–5% трафика (canary) → 10–25% → 50% → 100%, с мониторингом guardrails.

Качество данных и валидность

SRM (Sample Ratio Mismatch)

Проверьте, что фактическое распределение трафика (A/B) соответствует плановому (например, 50/50). Значимые отклонения = проблема инклюзии/флагов/ботов.

Идентичность и кросс-девайс

Используйте стабильный user_id; учитывайте кросс-устройства, cookie-decay, авторизацию позже в воронке.

Боты и аномалии

Фильтруйте неестественные паттерны (сверхскоростные клики, отсутствующие user-агенты, невалидные рефереры).

Сезонность и события

Не запускайте тесты на сильные «аномальные» периоды (праздники/распродажи), если это не цель теста.

Статистический анализ

Частотный подход (классический)

Фиксируйте альфа (обычно 0,05) и мощность (обычно 80%).
Не «подглядывайте» каждые часы без корректировок — риск ложноположительных.
Для множественных метрик/вариантов применяйте корректировки (Bonferroni/Holm/Hochberg) или иерархию метрик.

Байесовский подход

Оценивает распределение вероятности эффекта и вероятность превосходства варианта.
Удобен для мониторинга в реальном времени и принятия решений «достаточно хорошо».

CUPED/ковариаты

Снижение дисперсии за счет предтестовых ковариат (например, активность за прошлую неделю) → быстрее достигается мощность.

Последовательные/групповые останова