Проблема «подглядывания» в A/B

Зачем это знать

«Запустил A/B, через 3 дня — p = 0.04, давайте shipим» — классическая ошибка. Частое подглядывание с остановкой при p < 0.05 поднимает FPR с 5% до 20-30%. Тест становится мусором.

На собесах middle+ обязательно: «почему нельзя подглядывать?» — если не ответили, минус балл.

Короткое объяснение

Fixed horizon test: α = 0.05 значит 5% шанс false positive, если проверить один раз в конце.

Если проверять многократно в процессе и останавливаться при первом p < 0.05 → fpr растёт.

Numerical пример

5 проверок: fpr ~ 14%
10 проверок: ~19%
20 проверок: ~25%
Каждый день (30 проверок): ~30%

А должно быть 5%!

Результат: 1/3 «значимых» экспериментов — false positive.

Почему растёт

Под null гипотезой p-value uniform(0, 1).

В какой-то момент p уйдёт < 0.05 случайно. Если поймаете этот момент — считаете это «победа», хотя эффекта нет.

Симуляция

import numpy as np

fpr = 0
for trial in range(10000):
    # Null: эффекта нет
    data = np.random.normal(0, 1, 10000)
    
    for n in range(100, 10001, 100):  # проверяем каждые 100 observations
        sample = data[:n]
        # simplified: если mean > threshold → reject
        if abs(sample.mean()) > 1.96 / np.sqrt(n):
            fpr += 1
            break

print(fpr / 10000)  # ~0.30, не 0.05

Решения

1. Pre-register sample size

Заранее решить N. Проверить только в конце.

Pros: проще всего. Cons: медленно.

2. Sequential testing

Использовать методы вроде SPRT, mSPRT, always-valid inference.

Позволяет peek при сохранении FPR.

3. Bonferroni correction

Если планировали K проверок, использовать α/K.

Pros: простой. Cons: conservative (меньше power).

4. Alpha spending

Разделить α на «бюджет» для каждой проверки. Lan-DeMets — классика.

5. Bayesian approach

Bayesian A/B. Probability, что B лучше A, не зависит от N проверок.

Stopping rules

Obvious harm

Если metric сильно падает (50%+ degradation) — stop для пользователей. Это не «significance», а ethics.

Business issues

Компания решит остановить тест по business reasons (fixed timeline). OK, но не используйте middle-data для decision.

Wrong:

«p = 0.049, stop». Это peek.

На собесе

«Что такое peeking problem?» Подглядывание с ранней остановкой inflates false positive rate.

«Почему это bad?» FPR с 5% до 20-30%, ship wrong decisions.

«Как решать?» Pre-register N, sequential tests, alpha spending.

«Bayesian avoid?» Yes, но требует prior.

В реальности

Small companies

Обычно ignore — делают quick eyeball checks. Risk: wrong ship decisions.

Big tech

Специальные tools: always-valid inference (Optimizely), mSPRT (Microsoft), sequential (Netflix).

Позволяют подглядывать с корректными stats.

Симптомы peeking в компании

• «Experiment looks promising, ship early» — red flag
• Discussion p-value в middle of experiment
• Stopping experiments early based on p < 0.05
• Re-launching experiments когда first didn't work

Правильный процесс

1. Pre-register: метрика, MDE, N, stopping rules
2. Launch
3. Мониторинг guardrails (crashes, errors)
4. Не смотреть на main metric до end
5. End → analyze → decide

Или: use sequential methods для principled peeking.

Частые ошибки

«Just a quick check»

Даже один peek inflates FPR.

Stopping при trend

«Lift растёт 3 дня подряд → shipим» — тоже ошибка.

Игнорировать peeking в пост-анализе

«Я смотрел только 2 раза» — это уже 10% FPR.

Связанные темы

• Sequential testing простыми словами
• p-value простыми словами
• P-hacking простыми словами
• A/B-тест простыми словами

FAQ

Бы peek один раз — сколько FPR?

~10% вместо 5%. Уже double.

Можно ли считать один раз в неделю?

4 peeks → FPR ~13%. Лучше raw sequential.

Bayesian действительно не страдает?

Если prior корректный — да. Peeking не inflates «probability B > A».

---

Тренируйте A/B — откройте тренажёр с 1500+ вопросами для собесов.