TL;DR
Выбор статкритерия — это четыре вопроса, заданные в правильном порядке: какой тип у метрики, есть ли heavy tail, есть ли кластерная структура, можно ли уменьшить дисперсию через ковариату. На каждый вопрос есть рабочий ответ. Эта карта показывает порядок вопросов и куда они ведут — чтобы вместо «какой тест запустить?» ты знал, где в дереве ты находишься, и какой метод соответствует этой точке.
Ниже — карта для практического использования: сначала сценарий, который показывает зачем разные метрики требуют разных подходов, потом четыре группы метрик, потом дерево выбора, потом чеклист допущений, потом сжатая таблица «метрика + контекст → подход» для быстрого lookup.
Сценарий: маркетплейс запустил A/B-тест нового UI поиска. Аналитик хочет оценить эффект и смотрит три метрики:
Хочется применить один тест ко всем трём и быстро написать вердикт. Это самый распространённый источник ошибок в A/B-аналитике.
Каждая из трёх метрик требует своего метода. Применение z-test к выручке (heavy tail) даст ложно-значимый p-value из-за выбросов. Применение t-test к доле — формально сработает, но потеряет мощность. Применение t-test к ratio-метрике — даст неправильный CI из-за того что числитель и знаменатель коррелируют.
Решение «какой тест применить» — это не вопрос вкуса или привычки. Это вопрос соответствия метода свойствам данных. Карта ниже даёт алгоритм: что спросить о метрике и в каком порядке, чтобы дойти до правильного метода.
Каждая единица анализа — бинарный исход: 0 или 1. Числитель — подсчёт событий, знаменатель — количество экспозиций.
Примеры: CR (покупки / пользователи), CTR (клики / показы), retention Day 7, refund rate (возвраты / заказы).
Ключевое свойство: распределение биномиальное. CLT работает быстро при достаточном n.
Одно числовое значение на пользователя. Агрегируется как среднее.
Примеры: число заказов, число сессий, GMV per user, время в приложении.
Ключевое свойство: распределение может быть любым — от нормального до тяжёлых хвостов с zero inflation.
Отношение двух величин разной природы. Числитель — не подсчёт бинарных событий знаменателя.
Примеры: AOV = GMV / заказы, RPM = выручка / показы, стоимость доставки на заказ.
Ключевое свойство: дисперсия зависит от ковариации числителя и знаменателя. Наивный t-test на средних отношениях некорректен.
Метрика считается по подмножеству, определённому post-treatment поведением.
Примеры: ARPPU (среди покупателей), средний рейтинг (среди оставивших отзыв), конверсия среди увидевших фичу.
Ключевое свойство: treatment влияет на состав подвыборки → selection bias.
Дерево начинается с типа метрики и спускается к дополнительным вопросам по необходимости. Вопросы 2 и 3 наслаиваются на путь Вопроса 1; вопрос 4 — независимая оптимизация поверх любого выбранного теста.
Это первый и главный вопрос. Тип метрики определяет класс возможных тестов. Дальше для proportion и per-user и ratio нужны разные дополнительные вопросы; для conditional дополнительных вопросов нет.
→ z-test для долей / chi-square
Стандартный случай. Биномиальная интуиция, CLT обеспечивает нормальность. Пример: CR (покупки/пользователи), 50K на группу → z-test.
→ Точный тест Фишера / permutation-bootstrap
Нормальная аппроксимация ненадёжна при малых n или доле, близкой к 0/1. Пример: CR среди B2B-клиентов, 200 на группу → точный тест.
→ t-test / Welch t-test
Welch — дефолт (не требует равенства дисперсий). Пример: число сессий, 30K на группу → Welch t-test.
→ Bootstrap / trimmed mean / winsorization
Одиночный выброс может перевернуть результат t-test. Пример: revenue per user, 100K на группу, 0.1% пользователей = 40% выручки → bootstrap.
→ Delta-method / линеаризация
Delta-method аппроксимирует дисперсию через Taylor-ряд. Корректно учитывает ковариацию числителя и знаменателя. Пример: AOV, 80K на группу, умеренные чеки → delta-method.
→ Bootstrap отношения
Delta-method чувствителен к выбросам. Пример: RPM, 5K на группу, heavy tail в рекламной выручке → bootstrap.
→ Двухэтапная процедура / регрессия с коррекцией
Наивное сравнение средних смещено. Нужна коррекция на то, что состав подвыборки зависит от treatment. Пример: ARPPU, treatment увеличил конверсию → состав «платящих» изменился → двухэтапная процедура.
Если рандомизация на уровне города, школы, курьера — а метрика на уровне пользователя — нужна cluster-robust адаптация выбранного теста. Этот вопрос наслаивается на любой путь из Вопроса 1. Подробности — в разделе 6 ниже и в Модуле 6.
Если у пользователя есть pre-period значение метрики с высокой корреляцией с post-period — CUPED уменьшит variance поверх любого из выбранных в Вопросе 2 тестов. Подробности — в разделе 7 ниже и в Модуле 5.
Перед применением любого теста проверьте:
Проблема: несколько выбросов определяют среднее всей группы. t-test формально работает (CLT), но при конечных выборках среднее нестабильно.
Что делать:
Пример: Revenue per user. 0.1% пользователей с чеками в 100× среднего. t-test показывает p = 0.03, повторный запуск — p = 0.45. → Bootstrap + winsorization.
Проблема: большинство пользователей = 0 (не купили, не кликнули). Среднее близко к нулю, дисперсия завышена, мощность падает.
Что делать:
Пример: Purchases per user. 85% = 0, 14% = 1, 1% ≥ 2. Обычный t-test требует огромную выборку. Разделение на CR (proportion, z-test) + AOV (ratio, delta-method) — проще и мощнее.
Если рандомизация была не на уровне пользователя, а на уровне группы (город, курьер, школа), наивный тест на пользовательских данных систематически недооценит дисперсию и даст ложно-значимые результаты. Для cluster-randomized экспериментов выбранный тест нужно адаптировать: cluster-robust SE, либо агрегировать на уровне кластера и работать с групповыми средними.
Детали — ICC, формула Design Effect, разбор типичных ситуаций (гео-эксперименты, network effects) — в Модуле 6: Кластерные эксперименты.
CUPED уменьшает дисперсию метрики за счёт корреляции post-period с pre-period значением. Применяется поверх любого из выбранных в дереве тестов. Помогает когда: есть pre-period данные с корреляцией post-period > 0.3, аудитория стабильна между периодами, нет drift в метрике.
Детали — формула, условия применимости, когда не работает или опасен, примеры — в Модуле 5: Ускорение тестов.
| # | Метрика | Контекст | Подход | Почему |
|---|---|---|---|---|
| 1 | CR (покупки/пользователи) | 80K на группу, user-level рандомизация | z-test | Доля, большая выборка, стандартный случай |
| 2 | Revenue per user | Heavy tail, zero inflation, 100K на группу | Bootstrap + winsorization | t-test нестабилен из-за выбросов |
| 3 | AOV (GMV/заказы) | 50K на группу, умеренные чеки | Delta-method | Ratio, знаменатель случаен, но хвосты умеренные |
| 4 | CTR (клики/показы) | Гео-рандомизация, 15 городов | z-test + cluster-robust SE | Доля, но кластерная рандомизация |
| 5 | ARPPU | 200K на группу, pre-period есть | Двухэтапная процедура | Conditional: состав платящих зависит от treatment |
| 6 | Число сессий + pre-period | 40K на группу, корреляция pre-post 0.55 | Welch t-test + CUPED | Поюзерная, CUPED снижает дисперсию ~40% |
Эта карта работает в двух режимах. При планировании теста: спросить себя четыре вопроса до того как код написан — какие метрики я буду смотреть, какого они типа, есть ли у них heavy tail, есть ли кластерная структура. Это занимает 10 минут и определяет половину дизайна эксперимента.
При анализе результатов: если тест уже запущен и нужно быстро интерпретировать результаты — открой таблицу из Section 8, найди свою комбинацию «метрика + контекст», увидь рекомендованный подход. Если в твоей ситуации ничего из таблицы не подходит — иди в дерево выбора и проследи путь.
Главная цель карты — заменить интуицию «какой тест запустить» на воспроизводимый алгоритм. У того кто работает с дюжиной разных метрик в неделю, эта карта быстро становится частью inner loop.