← Назад к вопросам
Как правильно спроектировать A/B-тест? Какие параметры нужно определить заранее?
2.0 Middle🔥 171 комментариев
#A/B тестирование#Процессы и планирование#Статистика и математика
Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI26 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Проектирование A/B-теста: Полное руководство
Почему правильное проектирование критично?
Плохо спроектированный тест = пустой траты времени и денег. Нужно определить всё ДО запуска, иначе невозможно интерпретировать результаты.
Этапы проектирования A/B-теста
Этап 1: Определение бизнес-гипотезы
Гипотеза должна быть SMART:
ХОРОШО: "Увеличение размера CTA кнопки на 20% улучшит CTR на 5-10%
среди мобильных пользователей в неделю"
ПЛОХО: "Новый дизайн будет лучше"
Запишите:
- Что меняется? Размер кнопки
- У кого? Мобильные пользователи
- На какой период? Неделя
- Какой ожидаемый эффект? +5-10% CTR
Этап 2: Выбор первичной метрики
Выбирайте ОДНУ основную метрику (не 10 сразу):
Примеры первичных метрик:
- Click-Through Rate (CTR)
- Conversion Rate (CR)
- Order Value (AOV)
- Retention Day 7
- Engagement (action per user)
- Revenue per user
Почему одна? Множественное тестирование → ложные положительные (вспомните ошибку первого рода).
Этап 3: Выбор группирования (Unit of Randomization)
Это КРИТИЧНО. Выбор неправильного unit может испортить весь тест.
ПРАВИЛЬНО: Случайно распределяем пользователей в A или B при первом визите
НЕПРАВИЛЬНО: Распределяем по IP адресам (один пользователь может иметь несколько IP)
НЕПРАВИЛЬНО: Случайный выбор для каждого events (один пользователь может быть в обеих группах)
Правило: Unit должен быть STABLE (пользователь всегда в одной группе) и INDEPENDENT.
Этап 4: Определение исходных размеров
Нужны 3 цифры:
1. Baseline (базовое значение текущей метрики)
Текущее CTR = 5%
Это вы берёте из аналитики за последнюю неделю
2. Минимальный детектируемый эффект (MDE - Minimum Detectable Effect)
Бизнес говорит: "Тест значимый, если улучшение >= 0.5 пункта"
Т.е. 5% -> 5.5% (абсолютно) или 5% -> 5.25% (относительно)
ПРАВИЛО: MDE должна быть:
- Значимой для бизнеса (стоит ли усилий?)
- Реалистичной (возможна ли такая улучшение?)
3. Уровень значимости и мощность теста
α (alpha) = уровень значимости = 0.05
Риск ошибки первого рода (ложное срабатывание)
Стандарт: 5%
β (beta) = уровень ошибки второго рода = 0.20
Риск ошибки второго рода (пропустить реальный эффект)
Мощность теста = 1 - β = 80%
Стандарт: 80% мощность (β = 20%) или 90% (β = 10%)
Этап 5: Расчёт размера выборки
Формула для пропорций (CTR, CR):
n = 2 × (Z_α/2 + Z_β)² × (p(1-p)) / (MDE)²
Где:
- Z_α/2 = 1.96 (для α=0.05)
- Z_β = 0.84 (для β=0.20, мощность 80%)
- p = baseline conversion rate (5% = 0.05)
- MDE = minimum detectable effect (0.005 для 0.5pp улучшения)
Пример:
n = 2 × (1.96 + 0.84)² × (0.05 × 0.95) / (0.005)²
n = 2 × 7.84 × 0.0475 / 0.000025
n ≈ 29,632 пользователей в каждой группе
Итого: 59,264 пользователя нужно для теста
Python для расчёта:
from scipy import stats
baseline = 0.05 # 5% CTR
mde = 0.005 # 0.5 percentage point
alpha = 0.05
power = 0.80 # 80% power
# Используем statsmodels
from statsmodels.stats.proportion import proportions_ztest
effect_size = mde / baseline # relative effect
n_total = stats.power.tt_ind_solve_power(
effect_size=effect_size,
alpha=alpha,
power=power,
alternative='two-sided'
)
print(f"Sample size per group: {n_total:.0f}")
Онлайн калькуляторы:
- https://www.evanmiller.org/ab-testing/sample-size.html
- https://www.optimizely.com/sample-size-calculator/
Этап 6: Определение длительности теста
Нельзя просто сказать "тест 1 неделю"
Нужно учесть:
1. ЦИКЛЫ ПОКУПОК (Purchase Cycles)
- Если товар покупают раз в месяц → минимум 1 месяц теста
- Если раз в неделю → минимум 1 неделя (но 2-3 недели лучше)
- Если раз в день → несколько дней достаточно
2. ДЕНЬ НЕДЕЛИ ЭФФЕКТЫ
- Пн-Пт vs Выходные → разное поведение
- Нужно как минимум 1 полную неделю (Пн-Вс)
3. СЕЗОННОСТЬ
- Праздники, сезон → может быть большой шум
4. СТАТИСТИЧЕСКАЯ МОЩНОСТЬ
- Sample size ÷ Traffic в день = дней нужно
- Если нужно 60k пользователей, а вы привлекаете 1k/день = 60 дней
Формула:
Duration (дни) = Sample size per group / Daily traffic
Пример:
- Нужно 30k пользователей в каждой группе
- 1000 новых пользователей в день
- Duration = 30000 / 1000 = 30 дней в каждой группе
- Итого: 60 дней (30 × 2 группы)
Но минимум 7 дней (неделя), максимум 4 недели (иначе другие факторы влияют).
Этап 7: Определение вторичных метрик
Первичная метрика = основной результат
Вторичные метрики = побочные эффекты, которые нужно мониторить:
Пример: A/B тест увеличенной кнопки
Первичная: CTR
Вторичные:
- Revenue per user (не упала ли монетизация?)
- Bounce rate (не вернулись ли пользователи?)
- Average order value (не поменялась ли сумма чека?)
- User satisfaction (не раздражает ли большая кнопка?)
ВАЖНО: Не интерпретируйте вторичные метрики как результаты! Они для контекста.
Этап 8: Определение критериев остановки
НИКОГДА не смотрите на результаты, пока тест не закончился!
Правильно:
1. Рассчитали, что нужно 60 дней и 30k пользователей
2. Запустили тест
3. Ждали ровно 60 дней
4. Потом смотрим результаты
Неправильно (Peeking - подглядывание):
1. День 15: "Ой, рост на 20%!" - берёшь результат
2. БАЙАС: даже если нет реального эффекта, 5% тестов с p < 0.05 будут
3. Срокируешь тест рано
4. Запускаешь "победитель" - но это была удача
Критерии остановки должны быть ЗАРАНЕЕ:
- Количество дней
- Количество юзеров
- P-value (но смотреть только ДО конца!)
Этап 9: Расчёт доверительного интервала (CI)
После теста вычисляем не просто p-value, но 95% доверительный интервал эффекта:
Пример результата:
- Baseline CTR: 5%
- Test CTR: 5.8%
- Difference: 0.8 percentage points
- 95% CI: [0.3pp, 1.3pp]
- P-value: 0.002
Интерпретация: С 95% уверенностью истинный эффект между 0.3 и 1.3pp
Не просто "есть эффект", а ВО СКОЛЬКО он
Если CI включает 0 → не значимо
Если CI [0.1pp, 0.2pp] → слишком маленький эффект для практики
Если CI [5pp, 15pp] → очень большой эффект
SQL для анализа готовности к тесту
-- Проверяем достаточно ли трафика
SELECT
DATE(event_date) as date,
COUNT(DISTINCT user_id) as daily_users,
COUNT(*) as total_events
FROM events
WHERE event_date >= CURRENT_DATE - INTERVAL 30
GROUP BY DATE(event_date)
ORDER BY date DESC;
-- Проверяем baseline метрики
SELECT
COUNT(DISTINCT CASE WHEN clicked THEN user_id END) as clickers,
COUNT(DISTINCT user_id) as total_users,
ROUND(100.0 * COUNT(DISTINCT CASE WHEN clicked THEN user_id END) / COUNT(DISTINCT user_id), 2) as ctr_pct
FROM events
WHERE event_date >= CURRENT_DATE - INTERVAL 7;
Чеклист перед запуском теста
- Гипотеза четкая и записана
- Первичная метрика выбрана (одна!)
- Unit of randomization определён (user_id, session_id, etc)
- Baseline измерен за последние 7+ дней
- MDE согласована с бизнесом (реалистична?)
- α = 0.05, мощность >= 80%
- Sample size рассчитан
- Длительность теста определена (дни + дата конца)
- Вторичные метрики выбраны (не более 3-5)
- Способ рандомизации валидирован (не пересекаются ли группы?)
- Способ отслеживания метрик (SQL, аналитика инструмент)
- Критерии остановки записаны
- Система мониторинга санитаров (нет ошибок рандомизации)
Типовая таблица для документирования
Название теста: "Large CTA Button"
Дата начала: 2024-02-01
Дата конца: 2024-03-01 (30 дней)
Гипотеза: Увеличение кнопки CTA на 20% повысит CTR на 5-10%
Метрика | Baseline | MDE | N per group | α | Power
CTR | 5% | 0.5pp | 29,632 | 0.05 | 80%
Revenue per user | $10 | $1 | 47,000 | 0.05 | 80%
Вторичные:
- Bounce rate (не должна расти)
- AOV (не должен падать)
Unit: user_id (при первом визите)
Статистический тест: Chi-square для CTR, t-test для Revenue
ДО СМОТРЕТЬ РЕЗУЛЬТАТЫ ТОЛЬКО ПОСЛЕ 2024-03-01!
Итог
Правильное проектирование = 80% успеха теста.
Определите ДО запуска:
- Гипотезу и первичную метрику
- Baseline и MDE
- Размер выборки
- Длительность
- Unit of randomization
- Способ анализа
Не смотрите результаты раньше времени! Peeking = смерть статистики.