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

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

Глава 3 Строим аналитику с нуля

В этой главе я изложу свой подход к построению аналитики в компании с нуля. За всю мою карьеру в найме я делал это дважды – в Ozon.ru, Wikimart.ru и один раз как сооснователь – в компании Retail Rocket. И еще помог сделать это нескольким компаниям в режиме консультирования, заодно поучаствовав в найме сотрудников.

Первый шаг

Когда передо мной стоит задача сделать аналитическую систему или существенно расширить ее возможности, я всегда использую двусторонний подход: определяю, какие задачи и вопросы перед нами стоят, и выясняю, какие данные есть в источниках.

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

• Какие метрики понадобится считать?

• Какие дашборды собрать?

• Какую информацию отправить в интерактивные системы?

• Будут ли тут задачи ML (машинное обучение)?

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

Затем я иду к разработчикам и начинаю узнавать, а что же, собственно, у них есть – какие данные они собирают и где эти данные находятся. Во-первых, меня интересуют данные, которые помогут решать задачи клиента (мне важно увидеть не только схемы, но и живые примеры таких данных – строки таблиц и файлов). Во-вторых, для меня важны те данные, которые есть, а применения им пока нет – какие задачи они могли бы решить? К финалу этого этапа у меня уже есть:

• Список вопросов, которые покрываются текущими данными.

• Список вопросов без данных и понимание того, сколько усилий потребуется, чтобы их получить.

• Данные, которые пока не решают никаких актуальных задач.

• Источники данных и их примерные объемы.

И это только первая итерация. С этим списком я иду к заказчикам, общаюсь с теми же людьми, объясняю им, можно ли ответить на их вопросы, нужны ли дополнительные данные – а потом снова иду к разработчикам. Выглядит как челночная дипломатия, но именно так я и строю план проекта.

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

Выбираем технологии

Это будет моим вторым шагом. Правильный технологический стек избавит вас от головной боли на несколько лет вперед. Детально технологии я буду обсуждать в следующих главах. Сейчас обрисую общую картину. Примерный список вопросов к технологиям звучит так:

• Собственное хранилище или облачное?

• Использовать ли open-source-технологии?

• Какой язык программирования использовать для артефактов инженерии?

• Можем ли отдать разработку аналитики стороннему подрядчику?

• Какую отчетную систему выбрать?

• Требуется ли где-нибудь скорость анализа, близкая к real-time?

Это самые базовые вопросы, но от них зависит многое. В том числе каких сотрудников нанимать, сколько придется инвестировать, как быстро запустится проект.

Насчет хранилища данных у меня обычно следующее правило: если компания собирается зарабатывать на данных существенную часть своей выручки, то лучше собственное хранилище. Если для компании аналитика – вспомогательный проект, то лучше использовать облачное хранилище.