От каких параметров зависит длительность эксперимента?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Параметры, влияющие на длительность эксперимента
Длительность эксперимента (A/B теста) — это не просто выбор: "запустим на неделю". Это расчёт, основанный на статистике и бизнес-логике. За 10+ лет я провёл сотни экспериментов и научился правильно определять оптимальную длительность.
Основной принцип: Statistical Power
Эксперимент должен работать достаточно долго, чтобы:
- Достичь статистической значимости (p-value < 0.05)
- Иметь достаточную мощность (обычно 80%, чтобы не пропустить реальный эффект)
- Учесть weekly seasonality (поведение пользователей отличается в пн, пт, выходные)
- Минимизировать стоимость теста (не бегу месяц, если результат очевиден за неделю)
6 ключевых параметров
1. Размер эффекта (Effect Size, Minimum Detectable Effect)
Это минимальное изменение метрики, которое мы хотим обнаружить. Выбор effect size критичен:
Пример 1: Conversion Rate Optimization
- Текущая CR: 5%
- Хотим обнаружить эффект: +0.5% (до 5.5%)
- Это относительный эффект: 10% улучшение (0.5% / 5% = 0.1)
Пример 2: Retention Improvement
- Текущая 30-day retention: 40%
- Хотим обнаружить: +2% (до 42%)
- Это небольшой эффект, потребует больше пользователей и времени
Как выбрать effect size?
- Спрашиваю бизнес: "Сколько денег должна принести эта фича, чтобы стоить разработки?"
- Если разработка $50K, а фича улучшит выручку на $5K/месяц, нужно обнаружить хотя бы 10% рост
- Если улучшение $0.5K/месяц, то 1% достаточно, но эксперимент займёт месяцы
Правило: Чем меньше effect size, тем дольше эксперимент.
2. Baseline метрика (Current Performance)
Текущее значение метрики влияет на требуемый size sample:
Пример с CR (conversion rate):
- Если текущая CR = 1%, то для выявления +0.2% нужно ~50K пользователей
- Если текущая CR = 20%, то для выявления +2% нужно ~10K пользователей
Почему? Потому что при низкой baseline нужно больше людей, чтобы увидеть абсолютное изменение.
Практический пример: Я тестировал два изменения:
- Новый email subject (baseline open rate 25%) → нужно 5K emails для выявления +2%
- Новый checkout flow (baseline CR 2%) → нужно 100K пользователей для выявления +0.2%
Первый эксперимент закончился за неделю, второй потребовал 2 месяца.
3. Трафик (Sample Size, Traffic Volume)
Сколько пользователей видит вариант в день/неделю:
Расчёт:
Required Sample per variant = (Z-score² × 2 × p(1-p)) / (MDE)²
Для CR:
- Z-score (80% power, 5% significance) ≈ 2.48
- p = baseline CR (0.05)
- MDE = Minimum Detectable Effect (0.01)
Sample = (2.48² × 2 × 0.05 × 0.95) / (0.01)² ≈ 29,000 per variant
Если наш сайт видит 1000 пользователей/день, то для одного варианта нужно:
- 29,000 / 1000 = 29 дней = 4+ недели
Если видим 10,000 пользователей/день:
- 29,000 / 10,000 = 3 дня
Вывод: Больше трафик = короче эксперимент.
4. Дневной variance (Дневная волатильность данных)
Данные часто отличаются по дням и часам:
Пример:
- Понедельник: CR = 4.8% (люди отдохнули на выходных)
- Вторник: CR = 5.2%
- Среда: CR = 5.1%
- Четверг: CR = 4.9%
- Пятница: CR = 5.5% (люди торопятся в выходные)
- Суббота: CR = 6% (другой тип пользователя)
- Воскресенье: CR = 4.5% (выходной)
Если I запущу тест только с Пн по Вт (2 дня), и вариант А попадёт на Вт, а вариант Б на Пн, то Вариант А выиграет просто из-за seasonality, не из-за качества.
Правило: должна быть минимум одна полная неделя, лучше 2-3 недели.
Исключение: если у вас огромный трафик (миллионы пользователей/день), то день-два достаточно, потому что variance сглаживается.
5. Статистическая мощность (Statistical Power)
Это вероятность обнаружить реальный эффект (если он есть):
- 80% power (default) — есть 20% шанс, что пропустим реальный эффект
- 90% power — есть 10% шанс
- 95% power — есть 5% шанс
Когда повышу power?
- Если неудача теста стоит дорого
- Если решение необратимо (например, удаление фичи)
- Если требуется очень надёжный результат
Когда снижу power?
- Если это эксперимент, который легко откатить
- Если скорость разработки важнее уверенности
- Если трафик ограничен
Повышение power на 10% увеличивает требуемый sample на 15-20%.
6. Цена ошибки (Business Impact)
В зависимости от того, насколько дорого стоит ошибка, я выбираю уровень значимости:
5% significance level (p < 0.05)
- Используется в 95% A/B тестов
- Есть 5% шанс false positive (объявить победителя, когда эффекта нет)
- Стандартный выбор
1% significance level (p < 0.01)
- Используется, когда false positive стоит дорого
- Пример: изменение payment flow (можем потерять $100K благодаря bug)
- Требует в 2-3 раза больше трафика
10% significance level (p < 0.10)
- Ранний stage, прототипирование
- Ищем signals, не окончательные доказательства
- Требует меньше трафика, быстрее
Формула для расчёта длительности
Days = (Required Sample per variant × Number of variants) / Daily Traffic
Пример:
- Required sample = 50,000
- Variants = 2 (Control + Variation)
- Daily traffic = 5,000
- Days = (50,000 × 2) / 5,000 = 20 дней
Практические примеры из моего опыта
Тест 1: Email subject line (high traffic)
- Baseline open rate: 25%
- Effect size: +2%
- Daily sends: 50,000
- Duration: 3-5 дней
- Почему: высокая baseline, большой sample, достаточно трафика
Тест 2: Pricing page redesign (medium traffic)
- Baseline CR: 3%
- Effect size: +0.3% (это 10% улучшение)
- Daily visitors: 1,000
- Duration: 2-3 недели
- Почему: низкая baseline, нужно много посетителей
Тест 3: New onboarding flow (small traffic)
- Baseline completion: 40%
- Effect size: +3% (достаточно значимо для бизнеса)
- Daily users: 200
- Duration: 6-8 недель
- Почему: малый трафик, требует много дней
Тест 4: Critical checkout change (high stakes)
- Baseline CR: 5%
- Effect size: +0.3%
- Daily traffic: 10,000
- Significance: 1% (extra safe)
- Duration: 1-2 месяца
- Почему: риск высокий, нужна extra уверенность
Инструменты для расчёта
Использую:
- Online calculators: Evan Miller's AB test calculator
- Statistical software: Python scipy.stats для custom calculation
- Product tools: Amplitude, Mixpanel имеют встроенный calculator
- Excel: сам пишу формулу для быстрого расчёта
Правила, которые я следую
- Минимум неделя — даже если статистика говорит 2 дня, даю неделю для weekly seasonality
- Минимум 100 конверсий — если меньше, результат ненадёжный
- Максимум месяц — если после месяца нет result, либо эффект слишком мал (отклоняю), либо дизайн плохой
- Не подглядываю — не смотрю на результаты каждый день. Это создаёт bias. Смотрю в конец периода.
- Документирую гипотезу — до запуска пишу, что ожидаю. После теста сравниваю.
Частые ошибки
Ошибка 1: Пиковый трафик дня влияет на длительность Кто-то запускает тест на день с аномально высоким трафиком и думает, что неделя достаточно. Не заметит weekly seasonality.
Ошибка 2: Остановка теста, когда видны результаты Это called "peeking" и создаёт false positives. Должна запланированную длительность.
Ошибка 3: Слишком много параллельных тестов Если запущу 20 тестов и каждый даст false positive с 5% вероятностью, то ожидаю ~1 false positive просто случайно (multiple comparison problem).
Ошибка 4: Игнорирование confidence intervals Даже если p-value < 0.05, confidence interval может быть широким: "эффект между -2% и +5%". Это ненадёжно для решения.
Результат
Правильный расчёт длительности эксперимента означает:
- Нет "lucky shots" (false positives)
- Быстрое обучение (не тяну тест месяцы, если результат ясен за неделю)
- Доверие к результатам (команда верит числам)
- ROI от тестирования выше (меньше пустых тестов, больше winning feature releases)