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

• Не происходило ли что-нибудь подобное раньше? Если да, то какие тому были причины? Тогда у нас будет самая первая и самая вероятная гипотеза.

• Обращаемся к бизнес-контексту: не происходило ли каких-либо неординарных событий? Часто как раз параллельные события влияют на возникновение проблемы. Еще плюс пара гипотез.

• Описательный анализ данных (exploratory data analysis): смотрим данные в аналитической системе (например, кубах OLAP), не видно ли каких-либо аномалий на глаз? Например, какие-либо распределения изменились во времени (типы клиентов, структура продаж и т. д.). Если что-то показалось подозрительным – дополняем список гипотез.

• Использование более сложных методов поиска аномалий или изменений, например, как описано здесь [11].

Наша цель – накидать как можно больше гипотез, не ограничивая фантазию, затем отсортировать их по списку в порядке убывания вероятности, чтобы найти верную гипотезу как можно быстрее. Или даже воспользоваться бритвой Оккама, выстроив гипотезы по возрастанию сложности проверки. Иначе можно столкнуться с аналитическим параличом: превратить задачу в научную работу, когда проверяются все гипотезы без исключения. Такого в реальной жизни не бывает, у нас всегда есть ограничения в ресурсах – как минимум во времени. Как только гипотезы готовы, приходит очередь статистики, с помощью методов которой они проверяются. Как это сделать – расскажу в главе про эксперименты в ML.

Когда я был директором по аналитике Retail Rocket (сервис рекомендаций для интернет-магазинов), мне и аналитикам часто приходилось заниматься расследованиями, ведь бизнес довольно большой – больше 1000 клиентов, и странности, с которыми приходится разбираться, случаются часто. Много приходится работать с так называемыми А/Б-тестами: это тесты, где аудитория сайта делится на две части случайным образом – первой части пользователей показывается одна версия сайта, второй – другая. Такие тесты обычно используют, чтобы оценить влияние изменений на бизнес-метрики сайта, когда первая версия – это старая версия или контрольная группа, а вторая – новая версия. Если это интернет-магазин – это, скорее всего, будут продажи. Далее к результатам теста применяются статистические критерии, которые подскажут достоверность изменений.

Такие тесты хорошо выявляют проблемы: например, версия сайта с обновленными рекомендациями Retail Rocket проиграла старой версии рекомендаций. Как только это становится известным, начинается расследование. Проверка начинается с интеграции, и это первая гипотеза: правильно ли передаются нам данные от интернет-магазина. Обычно на этом этапе решается 60–70 % проблем. Далее мы пытаемся найти отличие этого магазина от остальных в такой же тематике, например магазины одежды. Это вторая гипотеза. Третья гипотеза – возможно, мы изменили дизайн сайта таким образом, что полезная информация опустилась ниже на странице сайта. Четвертая гипотеза – тест мог отрицательно повлиять на определенные категории товаров. Собрав набор таких гипотез, мы начинаем их проверять примерно в такой последовательности, как я описал. Довольно часто мы находим причину проблем, но иногда это не удается, его величество случай играет с нами в кошки-мышки, и эту мышку очень сложно найти.

Однажды клиент – магазин «Дочки-Cыночки» – тестировал наш сервис и сервис одного из наших российских конкурентов, чтобы выбрать лучший, и это превратилось в настоящий детектив [12]. Чтобы точно не проиграть в тесте, конкурент перемещал некоторое число пользователей, которые были близки к покупке, (например, добавили товар в корзину) из конкурентных (наших) сегментов в свой – причем делалось это не на постоянной основе, а в отдельные дни и часы. Основной метрикой сравнения была конверсия: процент пользователей, совершивших покупку. Ясно, что в той «мошеннической схеме» такой процент будет выше там, куда перетянули пользователей. Здесь компания Retail Rocket пошла на принцип! Мы стали копать. Через два месяца были обнаружены и опубликованы [12] факты подтасовки результатов. В итоге прошел ряд судебных процессов, и справедливость восторжествовала.

Отчеты, дашборды и метрики

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

• Просто таблица с «сырыми» данными или так называемые «выгрузки», например, таблица с заказами клиентов.

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

• Дашборды (dashboards) содержат ключевые показатели и метрики.

Первые два относительно просты и делаются через специальные системы, которые могут генерировать отчеты по запросу. Я стараюсь максимально оставить эту задачу на откуп пользователям. Почему? Потому, что тратить на это время высококвалифицированных сотрудников – значит стрелять из пушки по воробьям. Кстати, этим могут заняться стажеры-аналитики – отличный способ наработать опыт и понять бизнес-контекст. Как мотивировать пользователей стараться самостоятельно? Во-первых, они сэкономят время, которое обычно тратят на постановку задачи и ожидание результата. Во-вторых, получат возможность самим вносить правки и изменения – а значит творить. По моему опыту, обычно этим занимаются очень перспективные сотрудники, которые не бояться освоить новый инструмент, чтобы делать свою работу лучше. Остальным придется пройти через стандартный цикл планирования задач: а это время (дни, а иногда недели) и очень четкая формулировка технического задания. И кстати, все генеральные директора (Ozon.ru, Wikimart.ru, Ostrovok), с которыми я работал, пользовались OLAP-кубами со своих компьютеров. С их помощью они всегда могли ответить на простые вопросы, а если не получалось – обращались к аналитикам.