Модуль 2. Типы метрик

1. Зачем классифицировать метрику перед тестом

Выбор статкритерия зависит от типа метрики. Не от названия, не от бизнес-смысла — от математической структуры.

Неверная классификация — самая частая причина невалидных результатов A/B-тестов. Аналитик применяет t-test к ratio-метрике, получает p < 0.05 и принимает решение. А потом эффект не воспроизводится.

Прежде чем выбирать тест — определите, что за метрика перед вами.

2. Четыре типа метрик

1. Поюзерная метрика (Per-user)

Одно числовое значение на пользователя. Агрегируется как среднее.

Примеры: количество заказов на пользователя, GMV per user, число сессий.

Подход: t-test / Welch t-test. При heavy tail — bootstrap или winsorization.

Ключевой вопрос: распределение симметричное или с тяжёлым хвостом?

2. Доля (Proportion / Метрика долей)

Каждая единица анализа имеет бинарный исход: 0 или 1. Числитель — подсчёт событий, знаменатель — количество экспозиций. Агрегируется как доля.

Примеры: CR (покупки / пользователи), CTR (клики / показы), refund rate (возвраты / заказы), доля активных.

Подход: z-test / chi-square / bootstrap. Биномиальная интуиция: каждая экспозиция — испытание Бернулли.

Ключевой вопрос: является ли числитель подсчётом бинарных событий знаменателя? Если да — это доля, даже если формально записана как X / Y.

Почему CTR и refund rate — доля, а не ratio?
CTR = клики / показы. Каждый показ либо получил клик, либо нет — бинарный исход. Аналогично, refund rate: каждый заказ либо возвращён, либо нет. Числитель — это подсчёт «успехов» в знаменателе, а не другая физическая величина.

3. Ratio-метрика (Ratio)

Отношение двух величин разной природы. Числитель (деньги, время) — не подсчёт бинарных событий знаменателя.

Примеры: AOV (GMV / заказы), RPM (рекламная выручка / показы), стоимость доставки на заказ.

Подход: delta-method, линеаризация, bootstrap отношения.

Ключевой вопрос: является ли числитель непрерывной величиной, отличной по природе от знаменателя? Если да — это ratio, и t-test на средних некорректен.

Почему AOV — ratio, а не доля?
AOV = GMV / количество заказов. GMV — это сумма денег, а не подсчёт событий. Заказ не «либо стоит X, либо нет» — стоимость варьируется непрерывно. Поэтому здесь нужна delta-method.

4. Условная метрика (Conditional)

Метрика вычисляется только для подмножества, определённого post-treatment поведением.

Примеры: ARPPU (выручка среди покупателей), средний чек среди заказавших, конверсия среди увидевших фичу.

Подход: двухэтапная процедура, bootstrap с коррекцией, регрессия.

Ключевой вопрос: зависит ли состав подвыборки от treatment? Если да — прямое сравнение средних даёт selection bias.

3. Типичные ошибки

Ratio → t-test

AOV = GMV / Orders. Аналитик считает среднее AOV по пользователям и применяет t-test. Проблема: у разных пользователей разное число заказов, знаменатель случаен. Нужен delta-method или bootstrap отношения.

Доля → ratio-подход

CTR = клики / показы. Аналитик применяет delta-method как для ratio. Работать будет, но избыточно: CTR — это доля (каждый показ → 0/1), достаточно z-test. Ошибка не критична, но усложняет анализ без необходимости.

Conditional → наивное сравнение

ARPPU = Revenue / Paying Users. В тесте конверсия в покупку выросла — состав «платящих» изменился. Сравнивать ARPPU между группами некорректно: вы сравниваете разные популяции.

Heavy tail → стандартный t-test

Revenue per user. Один пользователь с чеком в 100× среднего. t-test показывает значимость, которая исчезает при повторном запуске. Нужен bootstrap, trimmed mean или winsorization.

4. Чеклист перед выбором теста

  1. Единица анализа — на каком уровне рандомизация? (user / session / cluster)
  2. Есть ли знаменатель? — если да, случайный ли он?
  3. Метрика бинарная? — 0/1 на пользователя → proportion
  4. Есть ли условие отбора? — если подвыборка зависит от treatment → conditional
  5. Форма распределения — heavy tail? Нужен ли bootstrap?

Практика

Открыть практику

Симуляторы

Открыть симуляторы