A/B-тест при малом трафике: когда хватит данных

При малом трафике A/B-тест может идти месяцами и всё равно не дать уверенного ответа. До запуска оцените исходную конверсию, минимально полезный эффект и число доступных наблюдений. Если требуемая выборка не набирается за разумный срок, начните с проверки ошибок, пользовательских заданий и более заметной гипотезы.

Не путайте разницу с доказанным эффектом

Пять заявок против трёх ещё не доказывают, что новый вариант лучше. На результат влияют случайность, источники трафика, устройства, рабочие дни и качество измерений. Сравнение «до изменения» и «после» дополнительно смешивает эффект интерфейса с сезонностью. В рандомизированном A/B-тесте посетителей одновременно распределяют между вариантами.

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

Прикиньте необходимую выборку

Для учебной оценки двух долей при равных группах можно использовать нормальное приближение. При двустороннем уровне значимости 5% и мощности 80% число наблюдений на вариант примерно равно:

n ≈ [1,96 × √(2p̄(1−p̄)) + 0,84 × √(p₁(1−p₁)+p₂(1−p₂))]² / (p₂−p₁)²
p̄ = (p₁+p₂)/2

Если исходная конверсия 2%, а нужно обнаружить рост до 2,5%, получается около 13 800 наблюдений на вариант — примерно 27 600 суммарно. При 100 подходящих уникальных посетителях в день это около 276 дней без учёта потерь измерения. Это расчётный пример, не прогноз для конкретного сайта. Для редких событий, зависимых наблюдений и других схем эксперимента требуется подходящий статистический метод.

Разница 2% → 2,5% равна +0,5 процентного пункта и +25% относительно исходной конверсии. Маленький относительный эффект требует ещё больше данных. Основы проверки долей описаны в справочнике NIST; практические требования к экспериментам — в рекомендациях Microsoft.

Какую метрику выбирать

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

Что делать вместо слишком долгого теста

1. Проверьте технический путь: открытие формы, ввод телефона, капчу, доставку в почту и CRM. Явную поломку исправляют без эксперимента.
2. Дайте представителям аудитории реальную задачу: выбрать модель, узнать доставку, оставить запрос. Наблюдайте затруднения, не подсказывая путь.
3. Сопоставьте обращения с записями сессий и поиском по каталогу при соблюдении настроек приватности.
4. Сформулируйте изменение механизма: убрать непонятное условие, показать совместимость, сократить лишний шаг. Замена оттенка кнопки редко решает существенную проблему выбора.
5. После внедрения наблюдайте результат, честно называя его наблюдением, если не было контрольной группы.

Пять интервью не измерят процент роста, но могут обнаружить повторяющуюся непонятную формулировку. Это другой метод с другой задачей, а не «A/B-тест без статистики».

Как избежать ложного победителя

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

Согласуйте обработку результата без значимого различия: это не доказательство полного равенства вариантов. Возможно, выбранный эффект слишком мал для доступной выборки. Сверку обращений с CRM разбираем в статье о кликах, визитах и сделках. Определение метода — в словаре A/B-тестирования.

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