P-hacking простыми словами

Короткое объяснение

P-hacking — это подгонка результатов статистического теста под «значимость» (p < 0.05), вместо того чтобы честно проверить заявленную гипотезу.

Человек выглядит так, будто нашёл эффект. Но если повторить эксперимент честно — эффекта нет. Это один из главных способов обмана в науке и аналитике.

Типичные примеры p-hacking

1. Peeking (подглядывание)

Проверяем p-value каждый день. Останавливаем тест, как только p < 0.05.

Проблема: при 20 проверках вероятность случайно увидеть p<0.05 — примерно 64%, а не 5%.

Подробнее: peeking в A/B-тесте.

2. Выбор «удачных» сегментов

Запустили A/B, общий результат не значим. Разделили пользователей по полу, возрасту, устройству, гео... и в каком-то из 10 сегментов получили p < 0.05.

Проблема: при 10 сегментах с порогом 5% случайный «успех» хотя бы в одном — около 40%.

3. Тестирование разных метрик

Запустили A/B с 15 метриками (конверсия, AOV, время на сайте, retention, NPS...). Одна «выстрелила».

Проблема: multiple testing без поправки → любая метрика может случайно показать p<0.05.

4. Смена гипотезы после данных

Планировали проверить: «новый дизайн ↑ конверсию». Смотрим данные: конверсия не выросла, но время на сайте — выросло. Пишем отчёт: «новый дизайн улучшил engagement».

Проблема: HARKing (Hypothesizing After Results are Known) — подгонка гипотезы под данные.

5. Удаление «выбросов», чтобы получить p<0.05

«Эти 20 пользователей — странные, уберём». Случайно после этого p-value становится <0.05.

Проблема: данные подгоняем под нужный результат.

6. Выбор выгодного окна данных

Считаем конверсию за неделю → не значимо. За 2 недели → не значимо. За 11 дней → значимо!

Проблема: перебор окон — то же самое, что многократное тестирование.

7. Добавление ковариат до получения p<0.05

В модели регрессии добавляем одну за другой переменные, пока p-value целевой не станет <0.05.

Почему это плохо

Ложные выводы

Решения на основе p-hacked данных → обычно ничего не улучшают. Тратите ресурсы на «фичу, которая не работает».

Невоспроизводимость

Честные тесты воспроизводимы на новых данных. P-hacked — нет: при повторе эффект исчезает.

Долгосрочный вред

Компания накапливает «победы», которые не дают реального роста → через год MRR не вырос, а все хвалят себя за прошлые «успешные A/B».

Как избежать p-hacking

1. Pre-registration (предварительная регистрация гипотезы)

Зафиксируйте гипотезу, метрику и окно ДО запуска теста:

Всё, что выходит за рамки — разведочный анализ (exploratory), а не подтверждающий (confirmatory).

2. Жёстко соблюдать окно

Тест запускается на 14 дней. Смотрим результат только на 14-й день.

Если очень хочется «подглядывать» — используйте sequential testing (SPRT, Always Valid Inference). Но тогда выборка больше.

3. Выбирать одну главную метрику

Primary-метрику фиксируют заранее. Вторичные (secondary, guardrail) — только для подтверждения, не для принятия решения.

4. Поправка на multiple testing

При анализе подсегментов или нескольких метрик:

• Bonferroni: α / k, где k — число тестов
• Benjamini-Hochberg: FDR control

Строже α → меньше ложных срабатываний.

5. Честно признавать провал

Если primary-метрика не значима — это провал теста. Не переписывайте историю под вторичную метрику.

6. Перепроверить на свежей когорте

Если получили «интересный» результат на подсегменте — запустите новый тест, где этот сегмент будет primary analysis.

На собесе

Популярный вопрос: «Вот данные A/B-теста, расскажите, как вы интерпретируете».

Хороший ответ включает:

• Запросить заранее зафиксированную гипотезу
• Проверить SRM (sample ratio mismatch)
• Учесть guardrail-метрики
• Не зацикливаться только на primary-метрике
• При многомерном анализе применить поправки
• Честно признавать «не значимо», если так

Плохой ответ: «Найдём сегмент, где эффект есть».

Ещё один классический кейс

Garden of Forking Paths (сад разветвляющихся тропок) — даже без злого умысла, у аналитика есть десятки решений:

• Какой период брать?
• Включать ли outliers?
• По какой метрике считать?
• Как группировать пользователей?

Каждое решение — «ветка». Если выбирать такие ветки, которые дают p<0.05 — это p-hacking, даже без осознанной манипуляции.

Решение: зафиксировать все решения ДО просмотра данных.

Связанные концепции

FDR (доля ложных открытий)

False Discovery Rate — доля ложных открытий среди «значимых» результатов. Процедура Бенджамини-Хохберга контролирует FDR.

Кризис воспроизводимости

В психологии и медицине выяснили: половина «значимых» результатов не воспроизводится на новых данных. P-hacking — одна из причин.

Движение к pre-registration

В академии научные работы всё чаще регистрируют до сбора данных. В продуктовой аналитике — похожий тренд.

Частые ошибки

Ошибка 1. «Тест не удался → перепроверю»

Перепроверка + продление → скрытый peeking.

Ошибка 2. «Это не p-hacking, у меня есть объяснение сегмента»

Пост-фактум объяснение часто подгоняется. Правильно — зафиксировать гипотезу и проверить на свежих данных.

Ошибка 3. Смешивать разведку и подтверждение

Разведочный анализ полезен — генерировать гипотезы. Но принимать решения на его основе — p-hacking.

Ошибка 4. «Гипотеза была такой с самого начала»

Без заранее зафиксированной регистрации это слова против слов.

Связанные темы

• P-value простыми словами
• Поправка на множественное сравнение
• A/A-тест — зачем нужен
• SRM — sample ratio mismatch

FAQ

P-hacking — это обман?

Иногда намеренный, иногда — непреднамеренный «garden of forking paths». В любом случае приводит к ложным выводам.

Можно ли смотреть на сегменты?

Можно — для разведочного анализа. Для принятия решений — только с поправкой на множественное тестирование или повторным тестом.

Как отличить честный анализ от p-hacking?

Спросите: была ли гипотеза зафиксирована ДО сбора данных? Если нет — повышен риск p-hacking.

Peeking — это всегда плохо?

В классическом A/B — да. В sequential testing — можно, но с корректной методикой.