A/B-тестирование: что такое p-hacking?

Когда-то давно, когда я только начинал разбираться со статистикой, я столкнулся с термином "p-hacking". Так как понимания базовых принципов у меня тогда еще не было, то и сама проблема "подглядывания" мне казалась весьма надуманной.

Сегодня я поделюсь своим опытом того, что профессиональные статистики вкладывают в "p-hacking", почему он реален и как я вижу себе выход из этой ситуации.

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

Откуда берется p-hacking?

Итак, в работе с A/B-тестами у нас возможны 4 исхода:

Source: www.dummies.com/education/science/biology/type-i-and-type-ii-errors-in-hypothesis-testing/

Как мы видим, в двух исходах мы принимаем верные решения, а в двух других  - нет.

Т.к. при A/B-тестировании мы очень хотим не ошибиться с принимаемым решением по результатам A/B-теста, то нам важно понять, что же может пойти не так:

• мы можем "увидеть" разницу (просто случайность), когда на самом деле ее нет
  (это Type I Error)
  
  
• мы можем "не увидеть" разницу, когда на самом деле она есть
  (это Type II Error)
  

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

• Type I Error, это False Positive ошибка.
  В классической статистике эта ошибка должна быть < 0.05, где значение 0.05 собственно это и есть пороговое значение p.value.
  
  
• Type II Error, это False Negative ошибка.
  В классической статистике эта ошибка должна быть < 0.2, и обычно в A/B-тестах смотрят на значение 1 - Type II Error, а значит ждут пока реальный эффект (power) будет пойман тестом и он будет > 0.8.
  

Так вот авторы презентации (которую я упомянул вначале поста) выделяют целых 6 сценариев, когда случается p-hacking:

Source: https://bitssblog.files.wordpress.com/2014/02/nelson-presentation.pdf

Сегодня я хочу остановиться на первой и, на мой взгляд, основной причине p-hacking - остановка теста как только p.value достиг значение < 0.05.

Большинство людей запускающих A/B-тесты, сильно обеспокоены только одним - они хотят как можно быстрее закрыть тест - задекларировать свой успех. Поэтому они регулярно подсчитывают p.value и жадно смотрят на то, когда это значение станет < 0.05. 

Но, штука в том, что чем больше мы делаем подсчетов p.value, тем больше шансов, что мы случайно этот ложный эффект поймаем. В статье Evans Miller пишет, что в худшем сценарии шансы поймать ложное срабатывание возрастают до 26.1%, а это уже намного больше изначальных 5%. И это серьезная проблема так как при таком уровне ошибке, уже не каждый 20-й, а каждый 4-й тест может быть ошибочно закрыт как успешный.

Поэтому статистики придумали power analysis. 

До начала эксперимента, вы формируете ожидание об улучшении (так называемый lift), и для такого lift считаете размер минимально необходимой выборки, при достижении которого результат можно считать статистически значимым.

Чтобы не происходило с p.value до достижения этой минимально необходимой выборки (например, он стал меньше 0.05) - тест останавливать нельзя. 

Но проблема в таком подходе в том, что обычно 

1. A/B-тест калькулятор для оценки lift и 
2. калькулятор для расчета минимально необходимой выборки 

это два разных инструмента!

Даже у Evans Miller в калькуляторе для сравнения конверсий в двух группах нет отсылки к калькулятору размера минимально необходимой выборки.

Поэтому про второй инструмент часто забывают или просто не используют по неграмотности.

Но это только часть истории. 

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

На самом деле и это тоже не верно: никто не может запретить вам рассчитывать p.value. 

Более того, статистики часто строят график наподобие такого: 

p.value calculated in dynamics.

Как мы видим p.value рассчитывается ежедневно.

Давайте коснемся этого примера немного подробнее. 

Итак, тест запустился 7-го Августа. Через каждые сутки мы будем делать расчеты p.value. И вот уже на следующий день (8-го Августа) p.value стал < 0.05. 

Можем ли принять решение, что тест успешный и один из вариантов выиграл? 

Ответ: нет.

Но, если мы будем продолжать рассчитывать p.value ежедневно, мы ведь будем повышать шансы поймать ложный эффект?

Ответ: да.

Как же нам быть?

Просто не забывать, что статистическая успешность теста определяется 2 параметрами: 

• significance level < 0.05
• power > 0.8

Значит, помимо динамики p.value нам параллельно нужно также считать power теста.

power in dynamics.

Что мы видим на втором графике:

1. Хотя под конец второго дня теста p.value < 0.05, power = 0.5 и решение принимать слишком рано.
   
   
2. Важно посмотреть хотя бы один бизнес-цикл (обычно - неделя) за динамикой p.value. Обычно в начале теста p.value очень волатилен, а потому смотреть за динамикой не только любопытно, но и важно. Например, мы могли бы увидеть, что на выходных lift уменьшился, а потому и power провалился < 0.8. Это полезный инсайт о том, как работает предложенное нами изменение с другой аудиторией (аудиторией выходного дня).
   
   
3. Существует так называемые Novelty effect и Change aversion, из-за которых вы можете попасть в ситуацию, когда вначале теста вы быстро достигаете сильный lift и power, но как только клиенты привыкают к "улучшению", эффект размывается. Поэтому, если ваше изменение высокорисковое и стоимость ошибки высокая, понаблюдайте за тестом дополнительные 2-3 бизнес-цикла, даже несмотря на достигнутую стат. значимость. В этом случае, при стабильном lift вы просто усилите power вашего теста (например до power >= 0.9) и т.о. уменьшите свои риски.

Из моего опыта, учитывая эффекты описанные в пп. 3 выходит, что выждав еще некоторое время, тест заканчивается примерно на таких уровнях ошибок:

• p.value = 0.005 (а не классический порог = 0.05)
• power = 0.9 (а не классический порог = 0.8)

И ктстати, ряд статистиков уже давно поднимают вопрос о том, что надежные тесты должны опираться на p.value = 0.005.