T-test и z-test: какой тест выбрать для сравнения средних и долей

Вопрос до формулы

В аналитических командах тесты часто выбирают по названию метрики: «для конверсии z-test, для выручки t-test». Это слишком грубое правило. Важны единица наблюдения, независимость, форма распределения, размер выборки, дисперсии и estimand. Неподходящий тест создаёт уверенность, которая не выдержит ревью.

Команде важно стандартизировать не названия тестов, а процесс выбора. В шаблоне эксперимента храните estimand, рандомизацию, primary method, альтернативную проверку и decision rule. Это уменьшает споры между аналитиками и помогает объяснить продуктовой команде, почему одинаковый uplift иногда требует разных расчётов.

Что именно измеряем

t-test сравнивает средние с оценённой по данным дисперсией и особенно полезен для небольших выборок. z-подход часто используют для долей и больших выборок, где нормальная аппроксимация работает приемлемо. Для конверсий, ratio-метрик, повторных наблюдений и кластеров нужны более аккуратные методы, чем механическое переключение кнопки в библиотеке.

Опиши, что сравнивается: среднее на пользователя, доля пользователей с событием или что-то ещё. Проверь независимость и уровень рандомизации. Для двух средних сравни разницу и интервал, при неодинаковых дисперсиях используй Welch t-test. Для долей используй корректный interval/test, а не z-test без проверки малых ожидаемых частот.

Расчёт на примере

В тесте checkout средний доход на пользователя выше на 2,4%, но покупки редкие и распределение сильно скошено. t-test может быть полезной частью анализа при большом n, однако рядом нужны bootstrap-интервал, payer conversion, ARPPU и возвраты. Один тест не решает вопрос о монетизации целиком.

Сделай карту «метрика → единица → метод → допущение». Для среднего времени — Welch или bootstrap, для бинарной конверсии — сравнение долей, для повторных действий — агрегация на пользователя или cluster-robust подход. До запуска зафиксируй primary test и не выбирай метод после просмотра p-value.

Проверка устойчивости

До интерпретации проверь единицу наблюдения, период и правило включения. Затем пересчитай результат на небольшой выборке, где ответ известен заранее, и сравни с разумной альтернативой: другим горизонтом, зрелой когортой или user-level агрегацией.

Если показатель станет регулярным, сохрани рядом входные параметры, контрольные сверки и версию определения. Это важнее дополнительного знака после запятой.

• Зафиксируй baseline до просмотра результата.
• Проверь пропуски, дубли и зрелость периода.
• Покажи размер выборки и диапазон неопределённости.

Ошибки интерпретации

Не применяй t-test к строкам событий, если рандомизация была по пользователю: зависимость нарушит стандартную ошибку. Не проверяй нормальность каждой большой выборки как ритуал: важнее estimand и устойчивость. Не сравнивай средние двух групп, если один пользователь может попасть в обе. И не называй «не значимо» доказательством отсутствия эффекта.

В выводе назови метод и допущение: «сравнили средний net revenue на user, использовали Welch test и bootstrap для проверки; интервал uplift пересекает ноль, возвраты не изменились». Это лучше, чем строка «p=0,18». Ревьюеру ясно, что именно было протестировано.

Практика

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

from scipy.stats import ttest_ind

result = ttest_ind(
    control['revenue_per_user'],
    test['revenue_per_user'],
    equal_var=False,
)
print(result.statistic, result.pvalue)

• Сохрани период и параметры расчёта.
• Назови хотя бы один крайний случай.
• Сформулируй вывод отдельно от гипотезы о причине.

Решение для команды

В выводе назови метод и допущение: «сравнили средний net revenue на user, использовали Welch test и bootstrap для проверки; интервал uplift пересекает ноль, возвраты не изменились». Это лучше, чем строка «p=0,18». Ревьюеру ясно, что именно было протестировано.

Команде важно стандартизировать не названия тестов, а процесс выбора. В шаблоне эксперимента храните estimand, рандомизацию, primary method, альтернативную проверку и decision rule. Это уменьшает споры между аналитиками и помогает объяснить продуктовой команде, почему одинаковый uplift иногда требует разных расчётов.