Какие есть способы уменьшить размер выборки для A/B теста без потери мощности?

Оптимизация размера выборки в A/B-тестах — экономия времени и денег

Вопрос: Как провести A/B-тест с меньшей выборкой без потери статистической мощности?

Это критически важно, потому что каждый день теста — это потенциально потеря денег (если новый вариант хуже) или неиспользованный потенциал (если вариант лучше).

Расчёт необходимой выборки

Базовая формула размера выборки:

n = 2 * (z_alpha + z_beta)^2 * (p1*(1-p1) + p2*(1-p2)) / (p2 - p1)^2

Где:

• z_alpha = 1.96 (для 95% confidence level, alpha = 0.05)
• z_beta = 0.84 (для 80% power, beta = 0.20)
• p1 = baseline conversion rate
• p2 = expected new conversion rate

Пример:

Baseline: 10% конверсия (p1 = 0.10)
Expected: 12% конверсия (p2 = 0.12)
Detectable difference = 2%

n = 2 * (1.96 + 0.84)^2 * (0.10*0.90 + 0.12*0.88) / (0.02)^2
n = 2 * 7.84 * 0.1776 / 0.0004
n ≈ 6,884 пользователей на вариант

Итого: 13,768 пользователей общей выборки

Способ 1: Увеличить желаемый эффект (Effect Size)

Суть: Если мы ищем большую разницу, нужна меньше выборка.

Пример расчётов:

1% разница (10% → 11%): n ≈ 27,500 на вариант
2% разница (10% → 12%): n ≈ 6,880 на вариант ← Вдвое меньше!
3% разница (10% → 13%): n ≈ 3,060 на вариант ← В 9 раз меньше!
5% разница (10% → 15%): n ≈ 1,100 на вариант ← В 25 раз меньше!

Как применить:

• Стартовать с более кардинальными изменениями
• Тестировать большие UI-изменения, а не marginal tweaks
• Убирать явно плохие элементы вместо «улучшения» хороших

Пример:

❌ Тестирование: Кнопка 10px vs 12px → Нужна большая выборка
✅ Тестирование: Удаление отвлекающего элемента → Эффект больший, выборка меньше

Способ 2: Увеличить Power (мощность теста)

Суть: Согласиться с более высоким риском ошибки (увеличить beta).

Сравнение:

90% power (10% risk): z_beta = 1.28 → n = 6,060
80% power (20% risk): z_beta = 0.84 → n = 5,960
70% power (30% risk): z_beta = 0.52 → n = 5,780

Когда применить:

• Для быстрых экспериментов с низким риском
• Когда стоимость ошибки низкая
• На ранних стадиях product discovery

Когда НЕ применить:

• Для критичных решений
• Для дорогих изменений
• Для привлечения инвестиций

Способ 3: Использовать более чувствительные метрики

Суть: Вариабельность метрики влияет на размер выборки.

Пример с метриками:

Метрика 1: Conversion Rate (вариабельность высокая)
- Baseline: 10%, Expected: 12%
- n ≈ 6,880

Метрика 2: Average Revenue per User (вариабельность ещё выше)
- Baseline: $10, Expected: $10.50
- n ≈ 50,000+ (намного больше)

Метрика 3: Feature Usage (вариабельность низкая, если уже используют)
- Baseline: 80% используют, Expected: 85%
- n ≈ 1,500 (намного меньше)

Как применить:

• Выбирать метрики с низкой вариабельностью
• Использовать ARPU вместо одной покупки
• Использовать engagement score вместо просмотров
• Комбинировать несколько метрик (если все улучшились, это проще детектировать)

SQL для анализа вариабельности:

SELECT 
  'conversion_rate' as metric,
  STDDEV_POP(conversion) as std_dev,
  AVG(conversion) as mean,
  STDDEV_POP(conversion) / AVG(conversion) as coefficient_of_variation
FROM users
UNION ALL
SELECT 
  'revenue_per_user',
  STDDEV_POP(total_revenue),
  AVG(total_revenue),
  STDDEV_POP(total_revenue) / AVG(total_revenue)
FROM users;

Способ 4: Стратификация и ANCOVA

Суть: Контролировать предыдущие различия между пользователями.

Как работает:

• Вместо случайного распределения → группируем похожих пользователей
• ANCOVA (Analysis of Covariance) уменьшает вариабельность
• Результат: нужна выборка в 1.5-2x меньше

Пример:

Простое рандомизирование: n = 6,880
Стратификация по историческому поведению: n = 3,440-4,500
Экономия: 35-50% на размер выборки

Как применить:

• Группировать по платежам в прошлом
• Контролировать по AOV (Average Order Value)
• Выравнивать по country/device/source

SQL для стратификации:

WITH user_strata AS (
  SELECT 
    user_id,
    CASE 
      WHEN lifetime_value < 50 THEN 'Low'
      WHEN lifetime_value < 500 THEN 'Medium'
      ELSE 'High'
    END as value_stratum,
    ROW_NUMBER() OVER (PARTITION BY stratum ORDER BY RANDOM()) as rn
  FROM users
)
SELECT 
  user_id,
  value_stratum,
  CASE WHEN rn % 2 = 0 THEN 'A' ELSE 'B' END as variant
FROM user_strata;

Способ 5: Sequential Testing (Снежинкин тест)

Суть: Проверять результаты по мере накопления данных, может остановить раньше.

Как работает:

• Не ждёшь фиксированный размер выборки
• Проверяешь результаты через каждые 100 или 500 пользователей
• Остаёшь рано, если результат очень очевидный
• В половине случаев экономишь 50% времени

Важно: Нужна коррекция для multiple testing!

Пример:

Стандартный тест: 6,880 пользователей = 30 дней
Sequential testing: 3,440-6,880 пользователей = 15-30 дней

В половине случаев результат ясен за 2 недели

Инструменты:

• Optimizely Sequential Sampling
• Statsig Sequential Testing
• Custom калькулятор с поправкой Bonferroni

Способ 6: Увеличить traffic к тесту

Суть: Не уменьшать выборку, а увеличить скорость набора данных.

Как применить:

• Направить весь traffic в тест (вместо 10% направить 50%)
• Тестировать на основном экране вместо глубокого
• Запустить в разных странах одновременно
• Увеличить трафик за счёт рекламы

Результат:

Нормальный фокус: 10% traffic → тест за 30 дней
Агрессивный фокус: 50% traffic → тест за 6 дней

Выборка та же, но время в 5 раз меньше

Способ 7: Используй существующие данные (Surrogate Metrics)

Суть: Предсказать долгосрочный эффект на основе краткосрочных метрик.

Пример:

Крайне долгосрочная метрика: LTV (нужно год ждать)
Краткосрочная метрика: Day-1 repeat rate (видно через неделю)
Корреляция: 0.9 → Можно использовать

Размер выборки для день-1 repeat: в 10 раз меньше

Как применить:

• Изучи корреляцию между краткосрочными и долгосрочными метриками
• Если корреляция > 0.8, можно использовать краткосрочную
• Тестируй быстро с краткосрочной метрикой
• Верифицируй на долгосрочной раз в полугод

Практический пример оптимизации

Задача: Тестировать изменение рассчитано требовать 30 дней с 6,880 на вариант.

Применяем несколько техник:

1. Увеличить размер эффекта (1% → 2%): n = 6,880 → 1,720 (-75%)
2. Добавить стратификацию: 1,720 → 1,200 (-30%)
3. Использовать краткосрочную метрику: 1,200 → 600 (-50%)
4. Увеличить traffic с 10% → 20%: 30 дней → 15 дней

Результат: 600 пользователей за 15 дней вместо 13,760 за 30 дней
Экономия: 95% выборки, 50% времени

Что НЕ нужно делать

❌ Использовать p-hacking — посмотреть результаты, увидеть незначимость, выбросить половину пользователей ❌ Early stopping без correction — проверять каждый день, останавливаться когда понравился результат ❌ Игнорировать multiple testing — запускать 10 тестов и говорить, что один значимый ❌ Переоцениваете эффект — ожидать 10% прирост когда в реальности будет 0.5%

Выводы

1. Размер выборки зависит от эффекта, которым ты ищешь
2. Стратификация может сэкономить 30-50% выборки
3. Sequential testing экономит в половине случаев
4. Краткосрочные метрики позволяют тестировать быстрее
5. Увеличить traffic проще, чем ждать медленнее

Как Product Analyst, я бы комбинировал эти подходы: стратифицировать по нескольким демографиям, использовать краткосрочные proxy-метрики, и запускать sequential testing. Это может сэкономить недели при выполнении экспериментов.