Как вы спроектируете A/B-тест: от гипотезы до решения по результатам?
Короткий ответ
- Сформулировать гипотезу и одну ключевую метрику
- Выбрать alpha, мощность и минимальный детектируемый эффект
- Рассчитать размер выборки и длительность до запуска
- Случайное разбиение, проверка SRM и A/A-тест
- Не останавливать тест досрочно по p-value
- Смотреть guardrail-метрики, а не только целевую
- Решение: эффект, интервал, практическая значимость
Хороший A/B-тест фиксирует метрику, MDE и размер выборки до запуска, контролирует корректность рандомизации и доводится до конца без подглядываний.
Как сказать вслух
пример ответаСначала я формулирую гипотезу и выбираю одну целевую метрику плюс контрольные. До запуска фиксирую уровень значимости, мощность и минимальный эффект, который нам интересен, и из этого считаю размер выборки и длительность. Дальше случайно делю пользователей, проверяю, что группы сопоставимы, и не подглядываю в результаты до конца теста. В финале смотрю не только на значимость, но и на размер эффекта и его ценность для бизнеса.
Подробный ответ
Основной ответ
Дизайн A/B-теста начинается до запуска: формулируем гипотезу, выбираем целевую метрику (и guardrail-метрики, которые нельзя ухудшить), фиксируем alpha (обычно 0.05), мощность (0.8) и MDE — минимальный эффект, который важно уметь обнаружить. Из этих параметров и дисперсии метрики считается размер выборки, из трафика — длительность; её округляют до целых недель из-за недельной сезонности. Единица рандомизации — обычно пользователь; обязательно проверяют SRM (sample ratio mismatch) и полезно прогнать A/A-тест. Во время теста нельзя останавливаться по первому значимому p-value — это раздувает ошибку первого рода (peeking); если нужны промежуточные взгляды, используют последовательное тестирование. По завершении оценивают эффект с доверительным интервалом и принимают решение с учётом практической значимости и затрат.
Ключевые моменты
- Всё фиксируется заранее. Метрика, MDE, alpha, мощность, длительность — до запуска; менять правила по ходу нельзя.
- SRM-проверка. Если фактическое соотношение групп отличается от планового, рандомизация сломана и результатам верить нельзя.
- Проблема подглядывания. Ежедневная проверка значимости многократно увеличивает долю ложных открытий; решение — фиксированный срок или sequential testing.
- Чувствительность. Для снижения дисперсии и ускорения тестов используют CUPED и стратификацию.
Практический контекст
Сквозной кейс-вопрос для продуктовых аналитиков и DS: интервьюер ведёт по цепочке «гипотеза → выборка → запуск → анализ» и смотрит, где кандидат поплывёт. Частые развилки: что делать, если эффект значим, но крошечный; что если метрика выросла, а guardrail упал; сколько ждать при малом трафике. В работе этот процесс обычно стандартизирован платформой экспериментов, но понимание основ проверяют всегда.
Частые ошибки
- Не считают размер выборки заранее и останавливают тест, как только p-value стал меньше 0.05
- Не проверяют SRM и корректность рандомизации перед анализом
- Смотрят десяток метрик без поправки на множественные сравнения и выбирают удобную