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

Коротко

Как понять, какой статистический тест подходит для конкретной метрики и дизайна?

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

• Назови единицу наблюдения, период и правило включения до расчёта.
• Показывай оценку рядом с размером выборки, разбросом или интервалом.
• Отделяй наблюдение, гипотезу и решение: это три разных уровня уверенности.

Какой рабочий вопрос здесь решает статистика

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

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

Определение и расчёт

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

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

Мини-кейс

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

После первого расчёта не переходи сразу к выводу. Проверь, не меняется ли знак или размер результата при разумной альтернативе: другой горизонт, зрелая когорта, user-level агрегация, фиксированный mix или отдельный технический слой. Именно эта проверка отделяет устойчивый сигнал от удачного среза.

Пошаговый алгоритм

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

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

Если расчёт станет регулярным, вынеси его из ручной ячейки в понятный pipeline: входные данные, преобразования, проверки и результат должны быть видны отдельно. Тогда новый период можно пересчитать без копирования старого вывода и без риска незаметно поменять знаменатель.

• Зафиксируй baseline и правило сравнения до просмотра итоговой цифры.
• Проверь grain, пропуски, дубли, даты и зрелость результата.
• Разложи изменение по сегментам только после общей контрольной сверки.
• Запиши, какой факт изменит решение и кто отвечает за следующий шаг.

Где результат ломается

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

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

Как интерпретировать без лишней уверенности

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

Сильный вывод начинается с факта, продолжает его диапазоном и заканчивается действием. Формулировки «связано», «совместимо с», «не удалось отличить» и «следующий шаг» точнее, чем автоматические «улучшилось» или «эффекта нет».

Практика для аналитика

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

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

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)

Как связать материал с соседними задачами

Статистический метод не живёт отдельно от предметной области. Один и тот же приём может понадобиться в продуктовой метрике, SQL-запросе, pandas-пайплайне, эксперименте или бизнес-отчёте. Поэтому после базового расчёта переходи к соседнему материалу, где тот же вопрос разобран на другом уровне.

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

Чеклист перед публикацией результата

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

Если на один пункт нет ответа, не прячь пробел в подписи графика. Запиши его как ограничение и реши, блокирует ли он действие. Иногда правильный результат — не новая формула, а исправление события или уточнение бизнес-вопроса.

• Что является единицей наблюдения и почему?
• Какой знаменатель, период и timezone используются?
• Есть ли пропуски, дубли, неполный день или незрелая когорта?
• Какие сегменты и альтернативные baseline меняют интерпретацию?
• Каков размер эффекта, диапазон неопределённости и бизнес-порог?
• Какое действие следует из результата и когда его пересмотреть?

Вывод

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

Статистика становится полезной не тогда, когда в отчёте появляется сложный термин. Она полезна, когда помогает уменьшить ошибку решения: заметить неправильный grain, не спутать календарный шум с ростом, не выдать корреляцию за причину и увидеть, что данных пока недостаточно. Держи этот порядок рядом с SQL, Python и дашбордом — и цифры будут работать как часть процесса.