A/A-тест перед запуском: что проверить кроме p-value

Перед большим экспериментом команда делит пользователей на две группы, но показывает всем одинаковый продукт. Ожидает p-value больше 0,05 и считает платформу проверенной. Такой A/A-тест действительно полезен, но один статистический результат слишком узок для этой задачи. Он может случайно оказаться значимым при исправной системе, а ошибки назначения и сбора событий иногда не меняют среднее настолько, чтобы их заметил тест.

Начать с назначения, которое можно восстановить

Для каждого пользователя сохраните идентификатор эксперимента, группу и момент первого назначения. Повторное посещение не должно перебрасывать человека в другой вариант. Проверьте количество разных групп на один идентификатор и долю пользователей без записи назначения. Если после входа меняется анонимный идентификатор, заранее определите, какая единица участвует в распределении и как разрешается конфликт.

Затем сравните фактические размеры групп с плановой пропорцией, учитывая случайное колебание. При большом отклонении просмотрите распределение по платформам и времени назначения. Ошибка может затрагивать только одну версию приложения. Даже идеально равные группы не доказывают исправность: программа способна систематически отправлять платящих пользователей в A и неплатящих в B, сохранив общий баланс численности.

Проверить весь путь от события до метрики

Возьмите несколько назначенных пользователей и восстановите их вклад из исходных событий. Совпадают ли окно, часовой пояс, фильтр внутренних аккаунтов и правило возврата? Есть ли у пользователя без действий явный нулевой вклад после присоединения к таблице назначений? Если отчёт начинает выборку с таблицы покупок, непокупатели пропадут из обеих групп, и конверсия превратится в другую метрику. A/A со случайным распределением может этого не обнаружить.

Для автоматического расчёта статистики полезна отдельная серия симуляций при заведомо равных распределениях. В каждом повторе создаём две независимые выборки с одинаковым законом и считаем тем же методом p-value. При уровне 0,05 около пяти процентов повторов должны отвергать нулевую гипотезу. Точного совпадения в конечной серии ждать нельзя; важны порядок величины и отсутствие систематического перекоса.

import numpy as np
from scipy.stats import ttest_ind
rng = np.random.default_rng(2026)
repetitions = 2000
# Fresh independent samples in every repetition; equal distributions.
a = rng.normal(size=(repetitions,200))
b = rng.normal(size=(repetitions,200))
pvalues = ttest_ind(a,b,axis=1,equal_var=False).pvalue
false_positive_rate = float(np.mean(pvalues < 0.05))
mc_se = (0.05*0.95/repetitions)**0.5
print({'repetitions':repetitions,
       'false_positive_rate':round(false_positive_rate,4),
       'monte_carlo_se_at_005':round(mc_se,4)})
assert pvalues.shape == (repetitions,)
assert 0.03 < false_positive_rate < 0.07

Что доказывает эта симуляция и чего искать в живом A/A

Код проверяет поведение Welch-теста на независимых нормальных данных, а не исправность вашей CRM или SDK. Чтобы проверить реальную тяжёлую метрику, повторите симуляцию на модели с подходящим распределением либо случайно перераспределяйте исторические единицы анализа. При повторных действиях сохраняйте пользователя целиком, при кластерном назначении — кластер. Иначе проверяемая схема окажется проще настоящего эксперимента и даст ложное спокойствие.

В живом A/A отдельно смотрите пропуски исходов, задержку доставки событий и совпадение определений метрик между отчётом и источником. Если одна группа получает события позже из-за маршрута обработки, утром отчёт покажет разницу, которая исчезнет к вечеру. Сопоставьте лаг от события до загрузки по группам и фиксируйте время среза. Так можно найти техническую причину до продуктового теста.

Оформить результат как проверку платформы

Единственный p-value ниже порога — повод расследовать, но не автоматический приговор. При множестве метрик случайные срабатывания особенно ожидаемы. Для готовности платформы нужны заранее выбранные проверки: стабильность назначения, баланс трафика, полнота событий и корректное воспроизведение метрики. Статистические симуляции дополняют их проверкой частоты ложных решений. После исправления конкретной ошибки повторите затронутый путь от назначения до итогового числа, сохранив входные данные и версию расчёта.

Продолжить работу с данными

Чтобы затем перейти от проверки платформы к продуктовому эксперименту, «A/B тесты и анализ данных на Python» предлагает полный цикл: гипотеза, метрика, размер выборки, статистический анализ и интерпретация. Отдельная работа с ошибками первого и второго рода поможет заранее определить, какие сигналы требуют расследования. Откройте программу платного курса «A/B тесты и анализ данных на Python».