9 апреля 2026 г.

A/A-тест — зачем нужен и как проводить

Что такое A/A-тест

A/A-тест — это эксперимент, в котором обеим группам пользователей показывают одинаковый вариант продукта. Никаких изменений, никакой разницы — контроль против контроля. Звучит бессмысленно? На самом деле это один из самых полезных диагностических инструментов в экспериментировании.

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

Зачем запускать A/A-тест

1. Проверить систему сплитования

Система рандомизации должна делить пользователей на группы равномерно и независимо от их характеристик. A/A-тест проверяет именно это.

Что может пойти не так:

  • Хеш-функция создаёт перекос — одна группа систематически больше другой
  • Баг в логике распределения — новые пользователи всегда попадают в группу B
  • Кеширование на CDN — часть пользователей видит закешированную версию и не попадает в эксперимент

Если при сплите 50/50 в одной группе 52% пользователей — это SRM (Sample Ratio Mismatch). В A/A-тесте SRM — верный признак бага в системе.

2. Проверить метрику на шум

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

3. Оценить реальный уровень ложных срабатываний

Теоретически при alpha = 0.05 вы должны получать ложное срабатывание в 5% случаев. На практике — зависит от корректности статистического теста. Запустите 100 A/A-тестов — и проверьте, действительно ли ровно ~5 из них дают p < 0.05. Если больше — ваш тест некалиброван.

4. Проверить предобработку данных

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

Как провести A/A-тест

Есть два подхода.

Онлайн A/A-тест

Запускаете эксперимент через вашу систему (Optimizely, GrowthBook, самописная) с двумя идентичными вариантами. Пользователи распределяются в реальном времени, всё как в обычном A/B-тесте — но без изменений.

Плюс: проверяет всю цепочку от рандомизации до подсчёта метрик. Минус: занимает время — нужно набрать выборку.

Офлайн A/A-тест (симуляция)

Берёте исторические данные и случайным образом делите пользователей на две группы. Повторяете N раз и смотрите распределение p-value.

import numpy as np
from scipy import stats

# Загружаем метрику: revenue на пользователя
data = np.random.exponential(scale=500, size=10000)  # симуляция

n_simulations = 1000
p_values = []

for _ in range(n_simulations):
    np.random.shuffle(data)
    group_a = data[:5000]
    group_b = data[5000:]
    _, p = stats.ttest_ind(group_a, group_b)
    p_values.append(p)

false_positive_rate = np.mean(np.array(p_values) < 0.05)
print(f"Доля ложных срабатываний: {false_positive_rate:.1%}")
# Ожидаем ~5%

Если доля ложных срабатываний значительно отличается от 5% — проблема в статистическом тесте или в данных. Подробнее о p-value — в отдельной статье.

Как интерпретировать результаты

Всё хорошо

  • Размеры групп примерно равны (SRM-тест не отклоняет H0)
  • p-value распределено равномерно между 0 и 1
  • Доля ложных срабатываний близка к alpha (5%)

Это значит: система работает корректно, можно запускать A/B-тесты.

Что-то не так

  • SRM (перекос в размерах групп) — проблема с рандомизацией. Ищите баг в хеш-функции или в логике распределения.
  • Слишком много ложных срабатываний (>7-8%) — статистический тест некалиброван. Возможные причины: нарушены допущения теста (нормальность, независимость), неправильная формула для SE, или подглядывание в данные.
  • Слишком мало ложных срабатываний (<2-3%) — тест слишком консервативный, вы теряете мощность. Возможно, SE завышена.
  • Систематический сдвиг в метрике между группами — баг в логике подсчёта метрики или в фильтрации данных.

Как часто запускать A/A-тесты

Обязательно — при первом запуске системы экспериментирования. Без A/A-теста вы не знаете, работает ли ваша рандомизация вообще.

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

Периодически — раз в квартал для ключевых метрик. Данные меняются, код обновляется, баги появляются. Регулярные A/A-тесты — как тесты в CI: ловят регрессии до того, как они испортят реальные эксперименты.

Частые проблемы, которые находит A/A-тест

Проблема Как проявляется Как исправить
Баг в рандомизации SRM, неравные группы Проверить хеш-функцию и логику распределения
Подключение бота в одну группу Одна группа стабильно выше по метрике Улучшить фильтрацию ботов
Баг в подсчёте метрики Систематический сдвиг средних Проверить SQL/код расчёта метрики
Неправильный стат-тест >10% ложных срабатываний Перейти на корректный тест (Mann-Whitney, bootstrap)
Выбросы Нестабильные p-value Тримминг или переход на перцентильные метрики

Вопросы с собеседований

  1. Зачем нужен A/A-тест? — Проверить корректность системы экспериментирования: рандомизация, подсчёт метрик, статистический тест. Если A/A-тест показывает значимую разницу — система сломана, результатам A/B-тестов доверять нельзя.

  2. Что делать, если A/A-тест показал значимый результат? — Не паниковать. Проверить SRM (равны ли размеры групп), проверить логику расчёта метрики, убедиться, что нет бага в рандомизации. Один значимый результат из 20 — нормально (alpha = 5%). Но систематическая значимость — сигнал проблемы.

  3. Как отличить баг от случайности в A/A-тесте? — Повторить тест или провести симуляцию. Одно ложное срабатывание — это ожидаемо. Если при 100 симуляциях ложных срабатываний больше 7-8%, проблема системная.

  4. Можно ли заменить A/A-тест проверкой SRM? — Нет. SRM проверяет только равенство размеров групп. A/A-тест проверяет всю цепочку: рандомизацию, подсчёт метрик, корректность стат-теста.

  5. Как A/A-тест связан с мощностью A/B-теста? — Если A/A-тест показывает завышенный false positive rate, значит и реальные A/B-тесты будут давать ложные результаты. A/A-тест — необходимое условие для того, чтобы доверять результатам A/B.

FAQ

Сколько длится A/A-тест?

Столько же, сколько типичный A/B-тест — нужно набрать достаточный объём данных. Для офлайн-симуляции временных ограничений нет: берёте исторические данные и прогоняете за минуты. Онлайн A/A-тест обычно занимает 1-2 недели, чтобы покрыть недельную сезонность.

Обязательно ли проводить A/A-тест перед каждым A/B?

Нет, это избыточно. A/A-тест нужен при запуске системы, после изменений в пайплайне и периодически для проверки. Перед каждым A/B достаточно проверять SRM — это быстрее и ловит основные проблемы с рандомизацией.

Можно ли использовать A/A-тест для оценки baseline метрики?

Да, это побочный бонус. A/A-тест даёт вам понимание естественной вариабельности метрики — сколько она «гуляет» без всяких изменений. Это полезно для калибровки MDE при планировании будущих A/B-тестов.

Потренируйте вопросы по A/B-тестированию на реальных задачах — откройте тренажёр. 1500+ вопросов, которые спрашивают на собеседованиях аналитика. Бесплатно.

Тренироваться в Telegram