Что такое проблема peeking (подглядывания) в A/B-тестах и как её избежать?

Короткий ответ

Peeking — это многократная проверка p-value в ходе теста с остановкой эксперимента сразу, как только результат становится «значимым»; это резко завышает фактическую вероятность ложноположительного вывода по сравнению с заявленным уровнем альфа.

Как это работает подробнее

классический t-test или z-test рассчитан на одну проверку в конце фиксированного периода; при многократных промежуточных проверках накапливается вероятность хотя бы раз случайно увидеть p < 0.05 просто из-за флуктуаций, даже если реального эффекта нет.

Пример кода

Пример на PythonКопировать

import numpy as np
from scipy import stats
np.random.seed(1)
false_positives = 0
for _ in range(1000):
    # симулируем A/A тест без реального эффекта с ежедневной проверкой
    data_a, data_b = [], []
    stopped_early = False
    for day in range(14):
        data_a += list(np.random.normal(0, 1, 50))
        data_b += list(np.random.normal(0, 1, 50))
        _, p = stats.ttest_ind(data_a, data_b)
        if p < 0.05:
            stopped_early = True
            break
    if stopped_early:
        false_positives += 1
print(false_positives / 1000)  # заметно выше 0.05

Что использовать на практике

• На практике. избежать peeking можно несколькими способами: зафиксировать длительность и размер выборки заранее и смотреть на результат только один раз в конце; использовать методы, разработанные для последовательного анализа (sequential testing, группы с alpha spending, байесовские методы с учётом раннего прекращения), которые явно контролируют ошибку первого рода при множественных проверках. Важно заранее выбрать и задокументировать подход, а не решать постфактум. Ещё один практичный вариант — использовать предрасчитанные «alpha-spending» границы, которые заранее определяют, насколько строгим должен быть порог значимости на каждой промежуточной проверке, сохраняя суммарный контроль ошибки первого рода.
• Пример. Sanity check: доля false_positives в этой симуляции A/A-теста с ежедневным подглядыванием окажется существенно выше заявленных 5%, что наглядно демонстрирует проблему.

Подводные камни

• Частые ошибки. смотреть дашборд теста каждый день и останавливать его, как только p-value впервые опускается ниже 0.05; оправдывать досрочную остановку бизнес-давлением («нужно решение уже завтра») без понимания, что это искажает статистические гарантии; использовать обычный t-test формально «один раз», но фактически выбирать момент его применения по уже увиденным промежуточным данным. Ещё одна ошибка — путать легитимный мониторинг технического здоровья теста (сбор ошибок, падение трафика) с подглядыванием за самим результатом по целевой метрике — первое допустимо и нужно, второе требует специальной методологии.