Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 21

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

Очень хайповый термин, который сейчас звучит из каждого утюга. Мне посчастливилось поработать в этой теме последние 8 лет и накопить достаточно большую экспертизу. Попробую дать собственное определение: большие данные (Big Data) – это такой объем данных, который невозможно обработать в требуемое время на одной машине (сервере).

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

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

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

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

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

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

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

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

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

Этот процесс не так прост, как кажется. Часто приходится в итеративном формате договариваться обо всех нюансах и ограничениях, в том числе с разработчиками. Происходит своеобразный торг, но он стоит того. Заранее хорошо продуманный результат не будет идеальным на 100 %, но если менеджмент получит ответы на 80 % своих вопросов в течение нескольких дней с момента запуска «фичи» – это успех. Ничто не играет против нас так, как время! И лучше его потратить до запуска, а не после, теряя деньги на неэффективном продукте.

Теперь коснемся доступа к данным внутри компании. Кто может получить его?

Отвлечемся на компанию Netflix, один из крупнейших поставщиков сериалов (мой любимый – «Карточный домик»). У компании очень интересная корпоративная культура [32]. Один из ее принципов звучит так: «Share information openly, broadly, and deliberately» (обмениваемся информацией открыто, широко и сознательно).

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