Какой статистический метод выбрать: t-тест, хи-квадрат, бутстреп, Байес или регрессия

Коротко

Порядок всегда один: сначала вопрос превращается в величину, потом у величины появляется единица наблюдения, и только третьим шагом выбирается метод. Если начать с метода, он всё равно что-то посчитает — просто ответ будет про другую задачу.

• Сравниваешь средние — t-тест Уэлча; сравниваешь доли — z-тест для двух долей или хи-квадрат на таблице 2×2.
• Сравниваешь состав категорий — хи-квадрат, а на редких ячейках точный тест Фишера.
• Метрика кривая, это медиана, перцентиль или отношение — бутстреп по пользователям.
• Нужна вероятность, что вариант B лучше, и есть исторический baseline — байесовский апдейт с явно названным prior.
• Нужно разложить число на вклады факторов — линейная регрессия; вероятность события у конкретного пользователя — логистическая.
• Ни один из шести методов не превращает наблюдение в причину и не чинит смещённую выборку.

Сначала переведи вопрос в величину, которую можно посчитать

Фраза «проверь, есть ли разница» методом не является: под ней скрывается минимум четыре величины. Доля активаций, средний доход, сдвиг медианы времени до первой ценности и состав платформ считаются по-разному и дают разные по ширине интервалы на одной выборке.

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

21% против 27%: доля считается z-тестом, средний доход — t-тестом Уэлча

В эксперименте «Маяка» две метрики живут рядом, и методы у них разные. Первая — доля активированных: 105 из 500 против 135 из 500. У доли дисперсия не оценивается отдельно, она выводится из самой доли как p(1−p), поэтому здесь работает z-тест для двух долей: разница 6 процентных пунктов, z ≈ 2,22, двусторонний p ≈ 0,026.

Вторая метрика — средний доход на пользователя за 14 дней: 148 ₽ против 163 ₽. Плюс 15 ₽ выглядит как рост на 10%, но у этой величины нет фиксированной связи между средним и разбросом: платящих мало, покупки крупные, стандартное отклонение 1 240 ₽ в контроле и 1 410 ₽ в тесте. Дисперсию приходится оценивать по данным — это случай t-теста, в версии Уэлча, потому что разбросы в группах разные.

Стандартная ошибка разницы равна √(1 240²/500 + 1 410²/500) ≈ 84 ₽. Разница 15 ₽ даёт t ≈ 0,18, а 95-процентный интервал растягивается от −150 до +180 ₽. Один эксперимент: по доле активаций эффект виден, по деньгам не различим вообще. Это не противоречие, а разная чувствительность — денежная метрика с хвостом требует на порядок больше наблюдений, чем конверсия.

Разницу между z и t стоит увидеть в цифрах. При 500 наблюдениях в группе t-критическое равно 1,965 против z = 1,960 — третий знак. При 12 наблюдениях это уже 2,201, и интервал выходит на 12% шире. «t для маленьких выборок» — поправка не на метрику, а на то, что дисперсию ты оценил по тем же данным.

• Что метод говорит: насколько наблюдаемая разница совместима с гипотезой «разницы нет» при твоём дизайне.
• Чего не говорит: окупается ли изменение, кому именно стало лучше и не сломался ли трекинг.
• Типичная ошибка: t-тест по строкам событий, когда в тест распределяли пользователей, — стандартная ошибка занижается, а уверенность растёт на ровном месте.
• Вторая по частоте: вывод «эффекта нет» из широкого интервала вроде −150…+180 ₽, который спокойно допускает и заметный рост, и заметное падение.

Хи-квадрат на четырёх платформах: 74 единицы статистики при силе связи 0,06

Следующий вопрос не про эксперимент, а про наблюдение: связана ли платформа с активацией. Берём 20 000 новых пользователей за квартал: iOS 1 260 активаций из 6 000 (21,0%), Android 1 440 из 8 000 (18,0%), Web 800 из 5 000 (16,0%), остальные 120 из 1 000 (12,0%). Итого 3 620 активаций, общая доля 18,1%.

Хи-квадрат сравнивает то, что есть, с тем, что было бы при независимости признаков. Ожидаемые активации для iOS — 6 000 × 0,181 = 1 086, наблюдается 1 260, вклад ячейки (1 260 − 1 086)² / 1 086 ≈ 27,9. По всем восьми ячейкам выходит χ² ≈ 74 при трёх степенях свободы, против критических 7,81: связь «значима» с огромным запасом.

А теперь её размер. Cramér’s V для таблицы 4×2 равен √(χ² / n) = √(74 / 20 000) ≈ 0,06 — очень слабая связь, и объясняется она объёмом: на двадцати тысячах пользователей разница в 3 пункта между iOS и Android обязана стать значимой. Большая статистика говорит «расхождение устойчиво», а не «расхождение важно», и в отчёт оба числа идут рядом.

Вклады ячеек подсказывают, где искать, но ответа не дают: Android лежит на ожидании, iOS выше, Web и «остальные» ниже. Дальше идёт разведка по версии приложения, языку и доле платного трафика — и каждое уточнение это отдельная проверка, поэтому набор разрезов назначают до расчёта.

select
  u.platform,
  count(*)                                            as users,
  count(*) filter (where a.user_id is not null)        as activated,
  round(100.0 * count(*) filter (where a.user_id is not null) / count(*), 1) as activation_pct
from users as u
left join activations as a on a.user_id = u.id
where u.signed_up_at >= date '2026-04-01'
  and u.signed_up_at <  date '2026-07-01'
group by u.platform
order by users desc;

• Что метод говорит: наблюдаемые частоты плохо согласуются с независимостью признаков.
• Чего не говорит: что платформа влияет на активацию и насколько разница велика по сути — для этого нужны V и пункты.
• Типичная ошибка: строки событий вместо пользователей. Человек с тремя заходами попадает в таблицу трижды, и χ² растёт пропорционально повторам.
• Вторая: выброшенная категория «не определено» — она часто связана с самим сбором данных.
• Третья: ожидаемое число в клетке меньше пяти — нормальное приближение ломается, нужен точный тест Фишера.

У медианы нет удобной стандартной ошибки — поэтому бутстреп пересобирает пользователей

Третий вопрос к «Маяку»: быстрее ли новые пользователи доходят до первой ценности. Медиана времени до первого сохранённого отчёта — 3,4 дня в контроле и 2,7 дня в тесте, то есть минус 0,7 дня. Для этой величины нет формулы стандартной ошибки, которую можно было бы подставить так же просто, как p(1−p) для доли: медиана зависит от формы распределения в своей середине, а распределение времени скошено и обрезано справа окном наблюдения.

Бутстреп обходит формулу численно. Из списка пользователей контроля берётся выборка того же размера с возвращением, то же делается для теста, для каждой пары считается разница медиан — и так 10 000 раз. Полученное распределение разниц само показывает, насколько оценка устойчива: в нашем случае 2,5-й и 97,5-й перцентили дают интервал от −1,1 до −0,2 дня. Знак один и тот же почти во всех пересборках, но величина эффекта внутри интервала различается в пять раз.

Главный выбор здесь — не число повторов, а единица пересэмплирования. Пересобери строки событий вместо пользователей, и интервал схлопнется до −0,9…−0,5 дня: десять событий одного человека не равны десяти независимым наблюдениям. Число повторов влияет мягче — на 1 000 итераций границы гуляют в сотых долях дня, на 10 000 стабилизируется третий знак. Seed уезжает в отчёт вместе с результатом.

Тот же метод закрывает ratio-метрики со случайным знаменателем: доход на сессию, доля успешных платежей, p90 времени ответа. Здесь заранее оговаривают, что именно оценивается. Отношение сумм (вся выручка на все сессии) и среднее отношений (посчитать на каждом пользователе, потом усреднить) — две разные величины, на скошенных данных расходящиеся на десятки процентов.

import numpy as np

rng = np.random.default_rng(20260726)
control = control_users['days_to_value'].to_numpy()   # одна строка = один пользователь
test = test_users['days_to_value'].to_numpy()

diffs = np.empty(10_000)
for i in range(diffs.size):
    c = rng.choice(control, control.size, replace=True)
    t = rng.choice(test, test.size, replace=True)
    diffs[i] = np.median(t) - np.median(c)

print(np.median(diffs), np.quantile(diffs, [0.025, 0.975]))

• Что метод говорит: насколько оценка дрожит, если бы выборка сложилась иначе при том же дизайне.
• Чего не говорит: ничего про систематический перекос. Если в тест попало больше мобильных пользователей, бутстреп честно воспроизведёт этот перекос 10 000 раз.
• Типичная ошибка: пересэмплировать события вместо пользователей и получить интервал вдвое уже настоящего.
• Вторая: подобрать метод после того, как посмотрел результат. Бутстреп гибкий, и этим легко злоупотребить — величина и способ расчёта выбираются до данных.

Вероятность, что B лучше A, существует только вместе с prior

Продуктовый вопрос редко звучит как «отвергается ли нулевая гипотеза». Он звучит так: какова вероятность, что чеклист лучше, и стоит ли раскатывать его сейчас. Частотный подход на это не отвечает по построению — вероятность там приписывается данным, а не гипотезе. Байесовский отвечает, но требует платы: назвать, что ты знал до эксперимента.

У «Маяка» активация исторически держалась около 21%. Это знание записывается как Beta(21, 79) — по весу оно равно сотне ранее увиденных пользователей. Апдейт механический: к первому параметру прибавляются успехи, ко второму неуспехи. Тестовая группа даёт Beta(156, 444) со средним 26,0%, контрольная — Beta(126, 474) со средним 21,0%. Разница ужалась с наблюдаемых 6,0 до 5,0 пунктов: prior подтянул тест к историческому уровню.

Из двух распределений считается то, чего не даёт p-value: вероятность, что параметр теста выше контрольного, — около 98%. И вторая, более полезная для решения: вероятность превысить порог окупаемости +2 п.п. равна 89%. Вместо «значимо» обсуждается «в девяти случаях из десяти изменение окупится».

Цена подхода видна на трёх prior вместо одного. Плоский Beta(1, 1) почти не вмешивается: разница 5,9 пункта, вероятность превысить порог 93%. Исторический Beta(21, 79) даёт 5,0 пункта и 89%. Уверенный Beta(210, 790) весом в тысячу наблюдений прижимает разницу до 2,0 пункта, и окупаемость падает до 50% — решение переворачивается. Поэтому prior называют до данных и показывают в отчёте вместе с тем, как от него меняется вывод.

• Что метод говорит: вероятностное утверждение о самом параметре — при выбранной модели и выбранном prior.
• Чего не говорит: что сравнение стало причинным. Байесовский апдейт наблюдательных данных остаётся наблюдательным выводом.
• Типичная ошибка: выбрать prior после того, как увидел результат. Это то же подглядывание, только переехавшее в предположения.
• Вторая: пересказывать credible interval словами про confidence interval. Это утверждения разной природы, и смешивать их в отчёте не стоит.

Линейная регрессия гасит коэффициент сессий с 64 до 18 рублей

Четвёртый вопрос смотрит шире эксперимента: из чего складывается доход на пользователя за первые 30 дней. Группировкой тут не обойтись — канал, устройство, возраст аккаунта и активность переплетены. Линейная регрессия раскладывает число на вклады: предсказание равно базовому уровню плюс коэффициент каждого признака, умноженный на его значение.

Начинаем с одного признака. Модель «доход ~ сессии за первую неделю» даёт 64 ₽ на сессию: звучит как готовый рычаг — добавь людям по две сессии. Добавляем канал привлечения, и коэффициент падает до 31 ₽; возраст аккаунта — 18 ₽; устройство — 17 ₽, дальше почти не двигается. Три четверти исходного эффекта принадлежали не сессиям, а тому, что органика и старые аккаунты одновременно и заходят чаще, и платят больше.

R² при этом вырос с 0,11 до 0,19, но честнее выглядит средняя абсолютная ошибка: 870 ₽ у тривиального прогноза «всем средний доход» против 820 ₽ у модели. Пять процентов точности — реальная цена всех четырёх признаков, и это стоит знать до того, как коэффициенты попадут в продуктовое планирование.

Отдельная ловушка — признаки об одном и том же. Сессии за неделю и возраст аккаунта коррелируют на 0,62, VIF около 1,6, жить можно. Добавь к недельным сессиям ещё и месячные с корреляцией 0,94 — VIF уходит выше восьми, и коэффициенты начинают плавать: один в минус, второй компенсирует плюсом. Предсказания почти не портятся, интерпретация разваливается.

• Что метод говорит: как связан каждый признак с target при прочих признаках, включённых в эту же модель.
• Чего не говорит: что изменение признака вызовет такой сдвиг результата, и что связь сохранится за пределами наблюдённого диапазона.
• Типичная ошибка: утечка будущего. Признак «всего сессий за 30 дней» для target «доход за 30 дней» поднимает R² до 0,74 и рассыпается в проде, потому что в момент прогноза такого значения ещё не существует.
• Вторая: случайное разбиение на train и test вместо разбиения по времени, когда модель должна работать на будущих пользователях.
• Третья: читать коэффициент как рекомендацию. Если нужен именно рычаг, вклад проверяют экспериментом — регрессия лишь сужает список гипотез.

Логистическая регрессия отвечает вероятностью, а решение принимает порог

Последний вопрос операционный: у «Маяка» 10 000 новых пользователей в неделю, активируются 1 800 из них, а команда поддержки может сделать 300 звонков. Нужна не средняя конверсия, а вероятность для каждого конкретного пользователя. Логистическая регрессия устроена как линейная, но её выход прогоняется через сигмоиду и попадает в диапазон от нуля до единицы.

Коэффициенты здесь живут в log-odds, и это единственное, что мешает читать их привычным способом. Признак «прошёл первый шаг чеклиста» даёт 0,41, то есть шансы умножаются на e⁰·⁴¹ ≈ 1,51. Сколько это пунктов вероятности, зависит от старта: при базовых 18% шансы 0,22 превращаются в 0,33, а вероятность в 24,9% — плюс 6,9 пункта. При базовых 60% тот же коэффициент даёт 69,4%, плюс 9,4 пункта. Поэтому в отчёт идут вероятности, а не odds ratio.

Дальше начинается то, что модель за тебя не решит. При пороге 0,50 в список попадают 1 120 пользователей, из них активируются 780: точность 70%, полнота 43%. При пороге 0,30 список растёт до 2 600 с 1 250 будущими активациями: точность 48%, полнота 69%. ROC-AUC в обеих картинах один — 0,78, он измеряет ранжирование и порога не знает. Порог задаёт ёмкость команды и цена ошибки: 300 звонков в неделю означают короткий список и высокий порог при любом AUC.

Про accuracy, которую приносят в таких задачах чаще всего: модель «никто не активируется» даёт 82% правильных ответов, не делая ничего. Полезнее калибровка — в верхнем дециле обещано 0,62, наблюдается 0,57, завышение на 5 пунктов смещает любой расчёт порога по деньгам. И оговорка про саму задачу: модель ранжирует вероятность активации, а не отзывчивость на звонок. Кому звонить выгоднее, показывает эксперимент с контрольной группой.

import numpy as np
from sklearn.linear_model import LogisticRegression

model = LogisticRegression(max_iter=1000).fit(X_train, y_train)
p = model.predict_proba(X_valid)[:, 1]

# калибровка по децилям: что обещали против того, что случилось
bins = np.quantile(p, np.linspace(0, 1, 11))
for lo, hi in zip(bins[:-1], bins[1:]):
    mask = (p >= lo) & (p < hi)
    print(round(p[mask].mean(), 3), round(y_valid[mask].mean(), 3), mask.sum())

# порог не оптимизируется по AUC: его задаёт ёмкость в 300 звонков
threshold = np.quantile(p, 1 - 300 / len(p))

• Что метод говорит: вероятность события для каждого наблюдения и порядок наблюдений по риску.
• Чего не говорит: какой порог правильный, и кто откликнется на вмешательство.
• Типичная ошибка: сводить выход к классу 0/1 и терять различие между вероятностями 0,51 и 0,99.
• Вторая: оценивать редкое событие через accuracy, где «ничего не делать» уже даёт 82%.
• Третья: подбирать порог на тех же данных, на которых меряешь качество, — дальше в проде повторить результат не получится.

Пять методов ломаются об одну ошибку: не та единица наблюдения

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

Арифметика простая. 500 пользователей тестовой группы дали 3 120 событий. Если анализировать события как независимые наблюдения, число наблюдений растёт в 6,24 раза, стандартная ошибка уменьшается в √6,24 ≈ 2,5 раза, а z-статистика вырастает с 2,22 до 5,5. Тот же эффект, та же выборка — но теперь он «подтверждён» с запасом, которого в данных нет.

Рабочее правило: уровень анализа совпадает с уровнем, на котором объекты попадали в группы. Распределяли пользователей — сначала агрегируй метрику до пользователя, потом сравнивай. Распределяли компании или города, как бывает в B2B и в географических раскатках, — единицей становится компания, и выборка у тебя не десять тысяч наблюдений, а двадцать кластеров, о чём лучше узнать до запуска.

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

Чего не сделает ни один из шести методов

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

Причинность от метода тоже не появляется: регрессия с десятью контролями и хи-квадрат на миллионе строк остаются описанием связи. Причинный вывод даёт дизайн — рандомизация или квазиэкспериментальная схема, — а метод считает неопределённость внутри него.

И третье: ни один из них не назовёт порог, с которого изменение стоит денег. Этот порог приходит из экономики продукта, фиксируется до расчёта и именно он превращает интервал или posterior в решение. Без него даже корректно посчитанный результат заканчивается фразой «разница значима» — и обсуждение начинается заново.

Практика: шесть вопросов к одному эксперименту

Возьми любой свой завершённый тест и задай ему все шесть вопросов подряд — это полчаса работы и лучший способ закрепить карту. Посчитай разницу долей z-тестом, разницу средних тестом Уэлча, сдвиг медианы бутстрепом по пользователям. Три интервала лягут рядом, и по их ширине сразу станет видно, какая метрика в твоём продукте вообще способна что-то показать на доступном трафике.

Дальше возьми наблюдательную часть. Построй таблицу частот по платформе или каналу, посчитай χ², Cramér’s V и разницу долей в пунктах. Затем собери простую регрессию на числовую метрику и проследи, как меняется коэффициент главного признака по мере добавления контролей — падение вдвое-втрое обычное дело и само по себе результат.

Последним шагом напиши два вывода на одних данных: частотный — с оценкой, интервалом и порогом окупаемости, и байесовский — с названным prior и вероятностью превысить порог. Отметь, какие решения меняются при другом prior. Если ни одно не меняется, prior не спорный; если меняются, дискуссия нужна там, а не в выборе нового метода.

Итог: карта на один экран

Метод не бывает правильным сам по себе — он бывает подходящим для величины, единицы и вопроса. Доли и категории закрывают z-тест и хи-квадрат, средние — t-тест Уэлча, кривые метрики и отношения — бутстреп, вероятность превысить порог — байесовский апдейт, вклады факторов — линейная регрессия, вероятность события у пользователя — логистическая.

Оставшаяся часть работы от метода не зависит: назвать единицу наблюдения, зафиксировать порог полезности до расчёта, проверить, не смещена ли выборка, и написать вывод так, чтобы в нём были и размер эффекта, и его неопределённость. Эти четыре шага исправляют больше отчётов, чем замена одного теста на другой.

• Вопрос → величина → единица наблюдения → метод. Порядок не меняется.
• Рядом со статистикой всегда стоит размер эффекта в единицах продукта.
• Большая выборка делает значимым почти любое расхождение: смотри на V, на пункты, на деньги.
• Prior, seed, число повторов, порог и определение величины уезжают в отчёт вместе с результатом.