Распространённые ошибки A/B тестирования и как их избежать

1. Подглядывание и досрочная остановка

Самая частая ошибка. Вы проверяете результаты каждый день, видите p < 0.05 на 3-й день и объявляете победителя. Проблема: при 5% номинальной значимости ежедневное подглядывание за две недели даёт ~25-30% реальных ложноположительных.

Почему это происходит — P-значения естественно колеблются в ходе сбора данных. При достаточном числе проверок случайный шум пересечёт порог 0.05.

Решение — Зафиксируйте размер выборки и не смотрите до завершения, либо используйте последовательное тестирование.

2. Слабые тесты

Слабый тест — тот, где недостаточно посетителей для обнаружения нужного эффекта. При 40% мощности тест пропустит реальный эффект в 60% случаев.

Решение — Всегда рассчитывайте размер выборки перед запуском. Знайте, какой MDE ваш трафик может поддержать.

3. Много вариантов без поправок

Каждый вариант увеличивает шанс ложноположительного. 4 варианта против контроля при α = 0.05 дают ~19% шанс хотя бы одного ложного результата.

Решение — Используйте Мультивариантный калькулятор с автоматическими поправками Бонферрони или Холма.

4. Оптимизация неверной метрики

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

Решение — Выберите главную метрику, напрямую связанную с бизнес-ценностью. Отслеживайте второстепенные для защиты.

5. Тестирование без гипотезы

Случайные изменения иногда дают результат, но вы ничего не узнаёте. Без гипотезы нельзя строить на успехах или понимать неудачи.

Решение — Перед каждым тестом запишите: «Мы считаем, что [изменение] приведёт к [эффекту], потому что [причина]».

6. Игнорирование проигрышей

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

Решение — Документируйте все результаты — победы, проигрыши, неопределённые. Изучайте прошлые неудачи перед новыми экспериментами.

7. Ошибки реализации

Даже идеальная статистика не спасёт сломанную настройку теста. Типичные проблемы реализации:

• Несоответствие распределения — неравное разбиение, указывающее на баги рандомизации
• Кеширование показывает контроль пользователям варианта (и наоборот)
• Изменение не загружается из-за JS-ошибок
• Бот-трафик раздувает один вариант

Решение — Проверяйте SRM перед анализом. Проводите A/A тест (идентичные варианты) для валидации настройки.

Чек-лист

1. Рассчитайте выборку до запуска
2. Не подглядывайте — или используйте последовательное тестирование
3. Корректируйте множественные сравнения
4. Предрегистрируйте главную метрику
5. Сформулируйте гипотезу
6. Проверьте SRM после теста
7. Документируйте всё