1. Определение ключевой метрики
Прежде чем считать тестовую выборку, ответьте на три вопроса:
- Что измеряем? Например: конверсия в покупку, CTR кнопки, средний чек.
- Какой текущий показатель метрики (Baseline)?
- Какой ожидается эффект от нововведения (MDE (Minimum Detectable Effect) — минимальный детектируемый эффект), который нам важно заметить. Например: хотим рост конверсии на 2%.
(!) Если MDE слишком низкий потребуется огромная выборка. Если слишком высокий — пропустите реальный, но скромный успех.
2. Определение контрметрик
Это метрики, которые не должны ухудшиться в процессе теста. Они страхуют нас от негативных последствий. Примеры: повышаем количество установок приложения, контрметрикой будет количество платных подписок. Если ускоряем загрузку, контрметрикой может быть количество технических ошибок. Задача контрметрики — убедиться, что рост одной метрики не «убивает» другую.
3. Определение инфометрик
Это вспомогательные метрики, которые помогают понять причину изменений ключевой метрики. Они не влияют на решение «внедрять/не внедрять», но объясняют «почему». Примеры: глубина скролла, время на сайте, клики по конкретным элементам, отток на конкретном шаге воронки. Роль этой метрики объясняющая — если ключевая метрика выросла, инфометрики подскажут, за счет чего (например, кликнули чаще, но купили так же).
4. Расчёт размера выборки, калькулятор Эвана Миллера
Для рассчёта выборки можно использовать подобные калькуляторы по заданным параметрам теста. Что нужно задать в самом калькуляторе:
- Текущая конверсия ключевой метрики (Baseline Conversion Rate);
- Минимально детектируемый эффект (MDE) — на сколько % хотим изменить метрику. Чем меньший эффект хотим поймать, тем больше потребуется выборка;
- Уровень значимости (Significance level α), обычно 5% — риск ложноположительного результата, т.е. ошибки I рода (False Positive);
- Статистическая мощность эксперимента (Statistical power 1−β (β — это вероятность ошибки II рода (False Negative), то есть вероятность не обнаружить эффект, когда он действительно есть (ложное отрицание))) — обычно 80%. Вероятность обнаружить эффект, если он реально есть.
В итоге калькулятор выдаст число пользователей на каждую группу, т.е. для полной выборки полученное число умножайте на ×2. Применительно к тесту на сайте, полученное значение делите на среднее количество посетителей в день, если участвует 100% посетителей. Если участвуют не все посетители, то формула будет следующей:
Дни = (Результат калькулятора × 2) / (Средний дневной трафик × Доля от трафика участвующая в тесте)
5. Единица рандомизации (кто попадает в тест?)
Определите идентификатор, по которому будет происходить разделение: лучше всего — User_ID. Пользователь видит одну версию на всех устройствах.
Cookie / Device_ID — хуже. Если пользователь зайдет с телефона и ПК, он может попасть в разные группы.
Session_ID — плохо для метрик, связанных с долгосрочным поведением.
Разбиение должно быть устойчивым. Один юзер должен быть только в одной группе на весь тест.
До старта теста нужно проверить А/А-тестом на сколько система разделяет группы правильно, а метрики стабильны без внесения изменений. Для этого:
- Разделите трафик 50/50 на две группы (A и A).
- Обеим группам показывайте абсолютно одинаковую версию сайта (контрольную). Никаких изменений в коде.
- Соберите данные за период, аналогичный планируемому A/B-тесту.
- Смотрите на соотношение групп — оно должно быть идеально близким к 50/50 (с учётом статистической погрешности). Если видите 45/55 — проблема в коде разбиения, а не в поведении пользователей.
- Убедитесь, что боты и сотрудники отсеиваются равномерно в обеих группах. Если в одной группе «вычищается» больше трафика — фильтр работает некорректно.
- Запустите статистический тест на проверку статзначимой разности результатов между двумя группами. Результат должен быть отрицательным (p-value > 0.05). Разницы между группами быть не должно. Если разница есть (статзначимая) — измерительная система «шумит» или сплит кривой. Запускать A/B-тест нельзя, пока не исправите техническую часть. Если разницы нет — инфраструктура готова, можно переходить к полноценному A/B-тесту.
6. Валидация попадания и фильтрация
Может ли пользователь попасть в тест некорректно? Да, и всего скорее попадёт. Признаки для отсева на этапе постобработки:
- Сотрудники компании — исключить по домену почты или внутренним IP;
- Боты и скраперы — аномально высокая активность, отсутствие JS, известные User-Agent;
- Технические сбои — пользователи, у которых не загрузился скрипт теста;
- Проверить, действительно ли соотношение групп 50/50. Если 48/52 — это норма, если 40/60 — в системе ошибка, тест невалиден.
7. План действий после получения результата
Заранее определите сценарии:
- Статзначимый рост → Внедряем на 100% аудитории.
- Статзначимый спад → Откатываем. Анализируем почему гипотеза не сработала.
- Если нет статзначимости:
▪ Выборка набрана → гипотеза не подтвердилась, оставляем «старую» версию.
▪ Выборка мала → продлеваем тест (с осторожностью) или пересчитываем мощность.
8. Организация мониторинга во время теста
Настройте дашборд с обновлением (например, раз в сутки):
- Ключевая метрика — динамика по дням;
- Контрметрики — оповещение, если падение превышает порог (например, -5% к выручке);
- Инфометрики — помогают отловить баги (например, резко упало число кликов — возможно, кнопка не работает).
Не останавливайте тест рано, если видите «красивую цифру». Ждите набранной выборки.
9. Постобработка и статистические тесты
Когда тест завершен:
- Удалите выбросы, которые искажают среднее (например, покупка на 1 млн руб. в тесте интернет-магазина);
- Проверка нормальности выборки с помощью теста Шапиро-Уилка или визуальной оценки: гистограмма, QQ-plot;
- Выбор теста:
▪ Нормальное распределение + равные дисперсии: T-тест Стьюдента.
▪ Ненормальное распределение: U-тест Манна-Уитни.
▪ Доли (конверсии): Z-тест для долей или Хи-квадрат. - Считайте не только p-value, но и доверительные интервалы (насколько точно мы оценили эффект).
10. Итоги и выводы
Ответьте на 4 главных вопроса:
- Что я наблюдаю?
Пример: «Конверсия в тесте выше на 3%, p-value = 0.01». - Чем это может быть вызвано? Могу ли я это проверить?
Пример: «Рост за счет мобильной версии. Проверю инфометрику „Время загрузки на мобильном“». - Можно ли сказать, что это имеет положительный эффект?
Пример: «Да, ключевая метрика выросла, контрметрики (возвраты, тех. ошибки) не ухудшились». - Какой следующий шаг?
Пример: «Рекомендую раскатку на 100% пользователей. Следующая гипотеза — оптимизация корзины».
Но есть нюанс... Идеально А/В-тесты проводятся не всегда чаще из-за нехватки времени и/или из-за решения руководства прекратить тест досрочно, но это совсем другая история.