A/A-тесты: зачем нужны
и что делать,
если падает значимость

A/A-тест — это эксперимент без воздействия. Берёшь юзеров, случайно делишь их на две группы, обе получают одну и ту же версию продукта, а потом считаешь метрику ровно так же, как считал бы её в A/B. Звучит бессмысленно — мы заранее знаем, что эффекта нет. Но в этом и смысл: если «эффект» появился — где-то баг, и пока его не нашёл, любому A/B-результату верить опасно.

Платформа экспериментов — это много слоёв: сплиттер, трекинг, хранилище логов, агрегация метрик, стат-процедура. Каждый слой может тихо ломаться. A/B такие поломки часто маскирует — реальный эффект перекрывает шум, и команда раскатывает фичу, не понимая, что половина «лифта» была артефактом трекинга. A/A ловит это до того, как оно стоит денег.

Без A/A эти три вещи проверить нечем. Можно полагаться на интуицию архитектора платформы, но интуиция не масштабируется на новые метрики и новые кейсы. A/A — это дешёвая формальная проверка, которая поднимает руку, когда что-то отъехало.

Когда команда впервые запускает A/A и получает p < 0.05, реакция всегда одна: «как же так, мы ничего не меняли — а тест значим». Это не баг, это статистика. При уровне значимости α=0.05 ровно 5% A/A-тестов должны давать значимый результат — даже если платформа идеальна. Это и называется False Positive Rate.

Поэтому одного A/A недостаточно. Нужна симуляция: запускаем 1000 (а лучше 10000) A/A на исторических данных и смотрим, какой процент из них дал p < 0.05.

Дальше — простая логика. Идеальный FPR равен α (5%). В реальной выборке из 1000 симуляций будет случайное отклонение — норма примерно 4–6%. А вот выходы за эти границы — повод копать.

Дополнительная проверка — равномерность распределения p-value. В правильно работающем A/A p-value должен быть распределён равномерно от 0 до 1. Гистограмма с перекосом к нулю — анти-консерватизм. Гистограмма с горбом в районе 0.5 — консерватизм. Это короче и нагляднее, чем считать только долю значимых.

A/A-тесты делятся на два формата, и они проверяют разные вещи. Перепутать — потерять время и не найти баг.

Хорошая практика: офлайн A/A — обязательный, продакшн A/A — по событию. Офлайн делают каждый раз перед добавлением новой метрики или нового стат-теста (быстро, дёшево, можно автоматизировать в CI). Продакшн запускают после изменений в инфраструктуре экспериментов или при первом запуске на новой платформе.

Офлайн A/A: код

import numpy as np
import pandas as pd
from scipy import stats

def offline_aa(df: pd.DataFrame, metric: str, n_sim=1000):
    """
    Случайно разбивает юзеров на A и B, считает t-тест, повторяет.
    Возвращает массив p-value длиной n_sim.
    """
    p_values = []
    users = df.user_id.unique()
    for _ in range(n_sim):
        groups = np.random.choice(['A', 'B'], size=len(users))
        mapping = dict(zip(users, groups))
        df['group'] = df.user_id.map(mapping)
        a = df[df.group == 'A'][metric]
        b = df[df.group == 'B'][metric]
        _, p = stats.ttest_ind(a, b, equal_var=False)
        p_values.append(p)
    return np.array(p_values)

p = offline_aa(historical_df, metric='revenue', n_sim=1000)

# Доля значимых — должна быть около 0.05
print(f"FPR: {(p < 0.05).mean():.3f}")

# Распределение p-value — должно быть равномерным
import matplotlib.pyplot as plt
plt.hist(p, bins=20); plt.show()

Если FPR в диапазоне 4–6% и гистограмма равномерная — тест и метрика здоровы. Если нет — иди по чек-листу ниже.

A/A — не ежедневная процедура. Это контроль, который запускают после конкретных событий в инфраструктуре экспериментов. Пять основных триггеров:

Если FPR в твоём A/A зашкаливает, виновата почти всегда одна из этих пяти штук. По частоте — от самых распространённых к более редким.

A/A показал высокий FPR — что дальше? Не паниковать, не отменять A/B вслепую. Пройти по шести шагам в правильном порядке: от самой частой и самой дешёвой проверки к самой редкой и дорогой.

A/A — стандартная тема на middle/senior-собесах в продуктовой аналитике. Спрашивают редко в лоб («что такое A/A»), чаще — в формате кейса: «у нас в A/B вышла странная картина, что бы ты сделал». Правильный ход — предложить A/A как первый шаг диагностики, а не сразу копать в продукт.