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% probability.

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 данных → обычно ничего не улучшают. Тратите ресурсы на «фичу, которая не работает».

Repeatability

Честные тесты воспроизводимы. P-hacked — нет.

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

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

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

1. Pre-registration

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

Всё, что выходит за рамки — exploratory, а не confirmatory.

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

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

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

3. Не смотреть на метрики по одной

Выбрать primary metric заранее. Secondary metrics — только для подтверждения / guardrails, не для принятия решения.

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

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

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

Строже α → меньше false positives.

5. Честно репортить fail

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

6. Re-run на свежей когорте

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

На собесе

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

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

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

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

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

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

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

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

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

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

False Discovery Rate (FDR)

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

Replication crisis

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

Pre-registration movement

В академии внедрили pre-registration на научные работы. В продуктовой аналитике идёт похожий тренд.

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

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

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

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

Post-hoc объяснение часто подгоняется. Правильно — pre-register гипотезу и проверить на свежих данных.

Ошибка 3. Смешивать exploratory и confirmatory

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

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

Без pre-registration это слова против слов.

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

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

FAQ

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

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

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

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

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

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

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

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

---

Тренируйте статистику — откройте тренажёр с 1500+ вопросами для собесов.