Роман с Data Science. Как монетизировать большие данные

Я уже расписал основные плюсы и минусы алгоритмов тестирования. Более подробные советы можно найти в книге «Семь главных правил экспериментов на веб-сайтах» [84]. Хочу предупредить читателя: к сожалению, в интернете много советчиков-теоретиков (и даже целые школы), которые все очень усложняют. Но даже научные статьи порой изобилуют ошибками, особенно если не были опубликованы в научных журналах и не озвучивались на авторитетных научных конференциях. Что уж говорить про посты уважаемых блогеров. Я сторонник простоты и считаю, что в методиках тестирования и анализа можно разобраться самостоятельно. Просто начинать нужно с самого простого – с фишеровской статистики с p-значениями. Открою секрет – если ваш тест действительно значим и данных в выборках достаточно, то все три метода покажут статистическую значимость. А вот ошибки, с которыми я сталкивался:

• неверная конфигурация теста;

• плохой генератор частот;

• неверный статистический критерий;

• проблема подглядывания;

• отсутствие пост-анализа;

• принятие решения, когда нельзя отвергнуть нулевую гипотезу.

Неверная конфигурация теста – самая частая проблема. Допустим, вы придумали гипотезу, у вас есть метрика, вы написали техническое задание на проведение теста. Если это ML-модель, то вы заранее провели офлайн-тесты – все было хорошо. После реализации теста и выкладки его в рабочую систему его нужно обязательно проверить. Если это сайт, то прощелкать нужные ссылки, проверить, что обеим группам показываются нужные версии страниц. А теперь представим, что тест запущен и в нем есть ошибка. Прошел месяц, пора считать результаты. Наше сознание заставляет нас искать ошибки, если результаты получились плохими, и просто радоваться, если результаты положительные. Но если в тесте была ошибка, то много времени было потрачено впустую и тест придется перезапускать. У меня на практике такое было сплошь и рядом. В результате мы в Retail Rocket разработали целый бизнес-процесс по запуску тестов с инструкциями по проверке. Такие ошибки очень дорого обходятся.

Плохой генератор случайных чисел для разделения всех пользователей на тестовую и контрольную группы тоже может быть проблемой. Надежный способ обнаружения такой проблемы – A/A-тесты. Второй вариант – симуляция. Тогда вам нужно точно повторить код разработчиков, который назначает сегменты, и проверить его работу на старых логах пользователей, то есть произвести имитацию A/B-теста. С такими генераторами часто возникают проблемы, поэтому команда инженеров написала свой вариант и выложила его исходный код в сеть [85].

Неверный критерий тоже может дать свою погрешность. Я бы рекомендовал в целях проверки делать симуляционные тесты выбранного статистического критерия. Это можно делать как с помощью генераторов распределений, так и с помощью уже имеющихся логов действий пользователя (если есть). Например, сделав два случайных генератора с одинаковыми исходными данными, нужно убедиться, что статистический критерий не показывает значимость. Затем сделать небольшую разницу между генераторами и убедиться, что статистическая значимость появилась. Также рекомендую сделать анализ мощности – сколько данных нужно, чтобы этот критерий показал статистическую значимость на какой-то минимальной для вас важности. Например, вы готовы внедрить новое улучшение только в том случае, если оно улучшает метрику на 1 %. Тогда вы делаете два генератора с этой разностью и моделируете работу критерия, чтобы понять, сколько точек данных вам нужно, чтобы заметить эту разницу. Это и будет вашим минимальным объемом выборки данных.