Что это и зачем нужно

Размер выборки в A/B-тесте — это сколько пользователей нужно набрать чтобы с большой вероятностью обнаружить эффект, если он реально есть. Эта вероятность называется statistical power (мощность). Стандарт индустрии — 80%.

Главная ошибка джунов и PM-ов: запустить тест «на день-два, что-то покажется». При маленькой выборке тест не имеет мощности — даже если фича работает на +5%, ты её не увидишь. Получишь шум и неверный вывод «не работает».

В Каспи стандарт для consumer-фичи: минимум 1 неделя, обычно 2-4. Для B2B Halyk — иногда месяцы.

Базовый пример

Расчёт через формулу для двусторонней проверки разности конверсий (на каждую группу):

$$n = \frac{(z_{\alpha/2} + z_{\beta})^2 \cdot 2 \cdot p (1-p)}{MDE^2}$$

где:

  • p — базовая конверсия (например 0.05 = 5%)
  • MDE — minimum detectable effect (минимальная разница которую хотим обнаружить, например 0.005 = 0.5 п.п.)
  • z_{α/2} — critical value для уровня значимости α=0.05 → 1.96
  • z_{β} — critical value для мощности 1-β = 80% → 0.84

Подставляем константы — (1.96 + 0.84)² × 2 = 15.68, округляем до 16:

$$n \approx \frac{16 \cdot p(1-p)}{MDE^2}$$

Пример расчёта для Каспи Магазин:

  • Базовая конверсия checkout: p = 5% = 0.05
  • Хотим увидеть прирост +0.5 п.п. (относительный +10%): MDE = 0.005

$$n = \frac{16 \times 0.05 \times 0.95}{0.005^2} = \frac{0.76}{0.000025} = 30,400$$

Нужно 30,400 пользователей на группу. Итого 60,800.

При трафике 50K юзеров в день на чекаут (после фильтра на bot/test traffic): примерно 2 дня.

Но если хотим увидеть +1% (relative +20%) — изменим MDE на 0.01:

$$n = \frac{16 \times 0.05 \times 0.95}{0.0001} = 7,600$$

Всего 15,200 — половина дня. Чем больше эффект — тем меньше выборка.

Если хотим увидеть +0.1% (relative +2%) — изменим MDE на 0.001:

$$n = \frac{0.76}{0.000001} = 760,000$$

Итого 1.5M — 30 дней. Маленькие эффекты требуют огромных выборок.

Тонкости и pitfalls

1. MDE — это до теста, не «искать после»

MDE задаётся перед запуском теста. Если ты после теста говоришь «я могу обнаружить эффект 0.3% потому что у меня 1M юзеров» — это математически верно, но post-hoc. Тест должен быть spec'нут заранее с фиксированным MDE.

2. Power 80% — это компромисс

80% значит: если эффект реально есть, мы его увидим в 80% случаев. В 20% случаев — false negative (упустим). Можно повысить до 90% — но это увеличит выборку в 1.6 раза.

3. Sample size vs traffic — ловушка интерпретации

«Нам нужно 30K пользователей» — это на каждую группу, не суммарно. Юзер в группе A и юзер в группе B — это два разных юзера.

4. Continuous metrics (revenue, time) — другая формула

Для continuous переменных (например ARPU, длительность сессии) формула:

$$n = \frac{16 \cdot \sigma^2}{MDE^2}$$

где σ — стандартное отклонение метрики. Continuous обычно требуют больше выборки из-за высокой дисперсии. Особенно ARPU где 95% юзеров платят 0, а 5% — большие суммы. Дисперсия огромна, MDE с обычной выборкой плохо.

Workaround: CUPED (Controlled experiment Using Pre-Experiment Data) — снижает variance на основе pre-period behavior, сокращает выборку в 1.5-3 раза.

5. Стратификация vs random split

Если случайно делишь 50/50 — групы могут получиться разными по составу (одна получила больше iOS, другая больше Android). Стратификация (stratified random sampling) гарантирует балансное распределение по ключевым признакам.

6. Multiple testing — не запускай 10 вариантов

Если запускаешь A/B/C/D/E test — нужны поправки Bonferroni (α/N) или FDR. Без них — false positive почти гарантирован.

Когда НЕ применять формулу

  1. Маленький продукт (<1000 юзеров) — A/B-тесты часто бессмысленны. Используй qualitative research (5-10 user interviews).

  2. Сильный эффект очевиден — например полностью новый UI с +50% конверсии не нужно тестировать, понятно что работает.

  3. Bandit/Multi-armed bandit — если важнее быстро catit'ы winner чем измерить точно, MAB алгоритмы (Thompson sampling) работают лучше A/B при unbalanced правильно потоке.

  4. High-stakes решения — для critical changes (например безопасность платежей) — A/B-тест даже на огромной выборке может не покрыть edge cases. Лучше canary release + monitoring.

Кейс из казахстанского бизнеса

В Halyk Bank PM хотел A/B-тест нового onboarding flow. Базовая активация в первый день — 35%. Хотел обнаружить +2% (relative +5.7%).

Аналитик посчитал:

  • p = 0.35, MDE = 0.02
  • n = 16 × 0.35 × 0.65 / 0.02² = 9,100 на группу

При 5000 новых регистраций в день — 4 дня минимум. Но weekly seasonality (вс vs пн разница в 3 раза) → накинули до 2 полных недели.

PM возмущался: «зачем 2 недели если за 3 дня уже видна тенденция?». Аналитик показал simulation: при peeking в первые 3 дня с p<0.05 в 30% случаев получишь false positive (хотя эффекта нет). Через 2 недели — реальный сигнал.

Запустили на 2 недели. Получили +1.8% (CI: +0.5% to +3.1%, p=0.02). Решение catит, эффект подтвердился через месяц на everyone.

Если бы остановились через 3 дня с p=0.04 (как часто случается) — это могла бы быть случайность. Catit'ли бы возможно не работающую фичу, и потеряли бы трафик на «новом» worse onboarding.

Главный урок: PM-ам нужно объяснять статистику. Sample size — не «бюрократия», а защита от ложных выводов и потерянного product time. Senior аналитик умеет это объяснить с цифрами на их языке: «За 3 дня вероятность false positive 30%, за 2 недели — 5%. Хочешь сэкономить 11 дней и в 1 из 3 случаев катить плохую фичу?»