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

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

Большой объем данных на самом деле получить очень несложно. Дам простой пример. Если каждую миллисекунду сохранять вашу геопозицию, например GPS координаты, то за сутки мы получим: 1000 миллисекунд в секунде × 60 секунд × 60 минут × 24 часа = 86 400 000 событий. Цифра очень впечатляет, особенно если масштабировать ее на всех людей на Земле. Более подробно о больших данных я расскажу в главе про хранилища данных.

Связность данных

Одна из важнейших характеристик данных – возможность связать разные источники данных. Например, если удается связать затраты на интернет-рекламу и продажи через нее, то вы получаете инструмент эффективности. Далее добавляем данные по реально доставленным заказам, так как в некоторых e-commerce-бизнесах процент отказов очень высок. И на выходе мы получаем эффективность с поправкой на отказы. Фантазируем дальше, добавляем к данным категории товаров – получаем возможность видеть эффективность рекламы в разрезе категорий товаров. Продолжать можно до бесконечности. Кстати, именно этот пример иллюстрирует то, что называется «сквозной аналитикой».

Вышеприведенный пример показывает, что, добавляя новый источник данных, мы можем улучшить точность и увеличить число «степеней свободы», что можно делать с самими данными. Лично для меня это увеличивает ценность данных на порядок. Вот только есть одна заминка с тем, как эти данные связать. Для этого нужен «ключ», который должен быть в обоих источниках, и этот ключ не всегда бывает настолько точным, насколько требуется нам. Поясню на примере. Чтобы идеально связать затраты на интернет-рекламу и покупки, нужен ключ – id пользователя. Но проблема в том, что, скорее всего, от рекламных систем вы не получите информации о том, сколько вы потратили денег на конкретного пользователя. Из-за этого приходится использовать набор ключей из ссылок, которые однозначно характеризуют рекламное объявление. Точность из-за этого страдает, но это реальная жизнь данных – лучше получить что-то, чем ничего.

Много данных не бывает

Эту фразу я повторял, когда работал в Ostrovok.ru. Я точно не помню, с чем она была связана, возможно, требовалось расширить парк серверов. Считаю, что в эпоху облачных вычислений, дешевого хранения данных и хороших алгоритмов их сжатия нужно сохранять максимально много и подробно. Поверьте, когда понадобится найти ответ на какой-то вопрос и вы будете понимать, что данных нет, а могли бы быть, будет очень обидно. Рано или поздно собирать их все равно придется, почему бы не начать прямо сейчас?

ВАЖНО! Здесь хочу поднять одну проблему: в какой бы компании я ни работал – везде разработчики игнорируют аналитиков. При разработке какого-либо функционала или продукта анализ его функциональности через данные ставится на последнее место. В лучшем случае будет сделан сбор простейших метрик по усмотрению разработчика. Дальнейший сценарий такой – менеджеры проекта или продукта, владельцы бизнеса начинают активно интересоваться его судьбой. Что там с цифрами? Бегут к аналитикам, просят нарыть хоть что-нибудь. А что может сделать аналитик, если данных для статистических тестов не хватает и точность страдает? Только высосать информацию из пальца. С таким положением вещей я лично сталкивался десятки раз, а случаи, когда все было сделано как надо, могу по пальцам пересчитать.

Я предлагаю активно бороться с этим. Разработку можно понять – им нужно как можно быстрее выкатить новую «фичу» с очень хорошим качеством. Анализ метрик их не волнует, это лишние строчки кода, это работа аналитиков. Что делать? Это сфера ответственности менеджера проекта/продукта, лица, от имени которого ставится задача разработке. Необходимо в процессе постановки подобных задач предусмотреть «визу» от аналитиков. Что в нее входит:

1. Отправка технического задания и примерного списка вопросов к эффективности новой разработки аналитикам.

2. Аналитики со своей стороны отдают вам список метрик, а также встречное техническое задание для логирования (сбора метрик) данных проекта: что собирать и в каком формате.