Николай Валиотти

Аналитика для руководителей. Стратегия и развитие бизнеса на базе данных, а не на интуиции

4

Школа интернет-маркетинга

© Николай Валиотти, текст, 2025

© Бортник В., иллюстрация на обложку, 2025

© Садовская М., иллюстрации в блоке, 2025

© Оформление. ООО «Издательство «Эксмо», 2025

Введение

Можно ли развивать бизнес, полагаясь на интуицию и Excel-таблички?

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

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

Эта книга помогает сформировать системный подход к аналитике и научит видеть в ней ценный инструмент для развития бизнеса. Вам не придется изучать ее «с нуля», исследуя тонну статей и других книг. «Аналитика для руководителей» – полноценное пособие для тех, кто принимает стратегические решения. После ее прочтения вы точно будете знать кто даст вам данные и в каком виде они нужны, чтобы продвинуть бизнес.

Я занимаюсь аналитикой больше 15 лет. За это время я защитил кандидатскую по прогнозированию с помощью нейронных сетей и отучился в американском вузе Georgia Tech, с помощью данных поднял продажи в «Ленте» и Yota, с нуля создал аналитическую практику в «Юлмарте» и сделал ее основной для принятия маркетинговых решений. В 2019 году открыл собственный успешный дата-консалтинг LEFT JOIN, куда приходят стартапы, большие зрелые компании, онлайн-школы, интернет-магазины, телекомы, разработчики игр и приложений на основе ИИ. У них единый запрос – начать принимать решения с опорой на данные, чтобы бизнес рос.

Мы выстраиваем для них системы, которые помогают им в разы поднять прибыль, сократить расходы и избежать финансовых рисков. А также – оптимизировать структуру компании, доработать продукт и найти новые возможности для бизнеса.

Благодаря этому опыту, я знаю, с какими трудностями сталкиваются директора компаний и руководители отделов, когда начинают работу с данными:

• Не понимают зачем им аналитика вообще и какую пользу она может принести бизнесу, а уж тем более – как за счет нее увеличить прибыль.

• Не знают что спрашивать с аналитиков и как понимать язык, на котором они отвечают, чтобы превратить графики и таблицы в готовые бизнес-решения.

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

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

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

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

• зачем работать с данными;

• что для этого нужно – как аналитика может помочь росту прибыли и масштабированию бизнеса;

• кто есть кто в аналитике: для решения каких задач вам понадобится дата-саентист, а для чего – дата-инженер, а также – что каждый из них должен уметь, чтобы считаться хорошим специалистом;

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

Зная все это, вы поймете, какой специалист вам нужен, какие задачи вы можете ему ставить и каких результатов ожидать. Это поможет при взаимодействии со штатными сотрудниками и подрядчиками.

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

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

Третья часть расскажет о том, как быстро и эффективно обрабатывать данные, какие инструменты вам для этого понадобятся и как управлять несколькими потоками информации одновременно.

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

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

Ну что, готовы погрузиться в мир данных? Тогда поехали!

Часть 1

Приносят ли данные пользу бизнесу

Глава 1

Зачем вообще бизнесу данные

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

Но могут ли эти данные помочь бизнесу? Безусловно.

Грамотная работа с предпочтениями, увлечениями и запросами клиентов позволяет специалистам – маркетологам, менеджерам, управленцам – принимать правильные решения, строить бизнес-стратегии и увеличивать прибыль.

Вот несколько примеров грамотного использования данных для решения задач бизнеса в разных сферах:

• Телеком-компании. У каждой вышки мобильной связи есть определенная пропускная способность. Компании собирают данные о количестве пользователей и об объеме генерируемого ими трафика. На карте отмечают места расположения станций, выявляют перегруженные и станции со слабой отдачей. Это позволяет перемещать вышки, чтобы оптимизировать затраты на обслуживание мобильной сети. Таким образом создается максимально широкое покрытие, и оборудование справляется с трафиком.

• Ретейл. Гипермаркеты практикуют анализ данных в своих приложениях. Если клиент всегда покупал продукты в определенные дни недели, тратя конкретную сумму, но внезапно его активность снизилась по одному из показателей, то у магазина есть шанс потерять покупателя. Тогда ему рассылаются специальные предложения, индивидуальные скидки или единоразовые бонусы. Это помогает сохранить около 30 % клиентов.

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

• Операторы сотовой связи. В МТС внедрили продукты на основе «больших данных» во все сферы деятельности компании и теперь легко предсказывают вероятность увольнения конкретного сотрудника в ближайшие два месяца, затем принимают меры. Операторы также управляют рабочим временем продавцов: по часам прогнозируют загрузку магазинов розничной сети, состоящей из 5 тысяч салонов. Чистый эффект от этих мер в цифрах составил 3,5 млрд рублей за отчетный год.

Стоит отметить, что компания недавно объявила о запуске цифровой экосистемы для повышения безопасности. Алгоритмы системы маркируют для банков номера абонентов, подвергающихся телефонному мошенничеству. Далее система проверяет профиль клиента на основе его действий, а также отслеживает потоки событий, звонков, смс-сообщений и других действий абонента. С одной стороны проверяется профиль клиента на основе его действий, а с другой – отслеживаются потоки событий, звонков, смс-сообщений и других действий абонента. Так выявляются различные виды шаблонов, которые используются в мошеннических схемах. А это позволяет предотвратить до 45 % незаконных действий.

• Оператор почтовой связи. «Почта России» составила аналитический профиль каждого зарегистрированного пользователя своего приложения. Учитывается все: наличие автомобиля, доход, интересы и даже возраст детей. Это стало возможным за счет привязки аккаунта к порталу «Госуслуг». После всестороннего анализа данных в приложении вам приходят индивидуальные предложения по подписке на газеты и журналы, что помогает компании дополнительно зарабатывать около 1,2 млрд рублей в год.

• Медиа- и веб-сервисы. Они создают системы рекомендаций, сегментируют пользователей и привлекают новых за счет таргетированной рекламы. Чуть позже рассмотрим этот метод поподробнее на примере компании Netflix.

Из предложенных вариантов мы видим, что все больше компаний понимают важность data-driven – стратегии принятия управленческих решений на основе правильного использования данных.

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

Как же действовать и с чего начать?

Глава 2

Как верно соотнести данные с целями бизнеса

Рис. 1. Анализируем цифры – принимаем решение!

С управленческой точки зрения можно выделить две основные цели бизнеса: увеличение прибыли и масштабирование, то есть развитие компании. Дальше крупные цели можно разбивать на мелкие и ставить задачи для их достижения. И для всех потребуется собирать и анализировать данные. Судите сами:

• Чтобы увеличить прибыль, вы должны хорошо знать рынок и ваше место в нем, а также понимать клиента: кому и зачем нужен ваш продукт? Учитывая основные метрики, вам придется разобраться: какие сегменты клиентов уже охвачены вами? какие из них наиболее прибыльные?

• Принимать обоснованные бизнес-решения о создании новых продуктов можно, только исследовав новую область: сколько в ней конкурентов? а платежеспособных клиентов? как часто у них появляется запрос на ваш предполагаемый продукт?

• Оптимизировать рабочий процесс и использовать оборудование без простоев нельзя, не разобравшись в текущих показателях: сколько сейчас тратится времени на каждый этап производства? как быстро доставляется готовая продукция? насколько доволен клиент?

• Грамотно управлять маркетинговым бюджетом и эффективно тратить средства на рекламу невозможно без изучения результатов работы: сколько всего вы потратили денег? сколько клиентов пришли к вам с каждого канала сбыта? какое маркетинговое решение сработало лучше всего?

Для этого нужно твердо понимать, какой цели служат данные, о чем они говорят и как могут повлиять на развитие бизнеса.

Именно поэтому стратегия управления ими должна быть максимально согласована с целями и даже с миссией компании.

Вот как выстраивается эта связь:

1. Понимание миссии компании. Миссия прописывается в виде тезисов: чем занимается компания, для кого и зачем она это делает.

2. Определение приоритетных целей. Миссия помогает определить актуальные на данный момент цели бизнеса: увеличить прибыль или выйти на новый рынок? расширить производство или оптимизировать логистику? увеличить базу клиентов или повысить узнаваемость бренда? В зависимости от целей результаты анализа будут отличаться.

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

4. Выбор источников данных. Данные поступают из разных источников – нужно отобрать те, которые содержат полезную для принятия решения нагрузку. То есть те, которые напрямую влияют на нашу систему метрик.

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

6. Анализ данных. Когда информация собрана и очищена, ее можно анализировать: находить закономерности, строить гипотезы и составлять отчеты.

7. Выводы на основе анализа. Здесь определяют слабые места или точки роста. К примеру, организация провела маркетинговую акцию. Результат успешный или нет? Как акция повлияла на бизнес? Стоит ли изменить что-то в рекламе, ценообразовании? Именно анализ подсказывает ответы на эти и другие вопросы.

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

Здесь можно привести пример из практики моей компании. Один из наших заказчиков, образовательный стартап, выбрал миссию – помочь студентам из Юго-Восточной Азии обучиться востребованным профессиям в ИТ. А для этого надо было, чтобы студенты узнали о проекте, познакомились с его услугами и смогли записаться на курс.

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

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

Наша команда настроила сбор и обработку данных, а также сверстала дашборд. На нем отображалась шкала со скоростью ответа, можно было настроить фильтры по источникам лидов или по отдельным продажникам.

Дашборд (рис. 2) помог заказчику проанализировать работу отдела и выяснить, что конверсия в покупку выше всего, когда менеджер отвечает на заявку клиента в течение 15 минут – не дольше. С этими данными на руках заказчик разработал новые KPI для отдела продаж, чтобы повысить эффективность работы. Теперь он также мог контролировать нагрузку на сотрудников: если скорость разбора заявок по всему отделу начинала падать, это говорило о том, что продажники не справляются с объемами. А если у всех получается и только отдельные менеджеры затягивают с ответами, то это повод присмотреться конкретно к ним.

Есть и другой пример, уже из международной практики, – Netflix. История этой компании показывает, как качественный анализ данных верно соотносится с миссией компании и помогает реализовать обе цели в бизнесе.

Это самый популярный стриминговый сервис в мире – в 2024 году число подписчиков перевалило за 280 млн. Руководство Netflix принимало много спорных решений вроде изменения тарифов или запрета на использование одного аккаунта несколькими пользователями. Но, несмотря на возмущения общественности и угрозы уйти к конкурентам, число подписчиков продолжало расти.

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

И сейчас, даже после резких отмен новинок или отказа продлевать лицензии на популярные сериалы и фильмы чужого производства, у Netflix остается огромный каталог, ориентироваться в котором помогает алгоритм рекомендаций – один из лучших во всей стриминговой индустрии.

Netflix собирает огромные массивы данных о пользователях и их предпочтениях. Его алгоритмы анализируют историю просмотров – названия фильмов, жанры, продолжительность сеансов; время суток, когда человек зашел на сайт, и даже девайс, с которого он это сделал. Затем они сравнивают людей, которые смотрят одни и те же фильмы и одинаково их оценивают. Рекомендации формируются по принципу: «У двух человек похожие вкусы, так что предложим первому то, что он еще не смотрел, но что хорошо оценил второй».

Это тоже может показаться странным: получается, Netflix строит рекомендации для пользователя на основе чужих интересов. Но когда речь идет о действительно больших данных и базе из миллионов пользователей, алгоритм учится предсказывать их предпочтения довольно точно. Без работы с данными такой результат был бы просто невозможен.

Рис. 2. Дашборд образовательного стартапа

Конечно, никакая компания не получает идеально работающую аналитику в один момент – это долгий путь, поэтапное развитие. Причем неравномерное.

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

Поэтому в начале пути важно научиться грамотно и удобно работать со всеми доступными данными. Они уже у вас как-то накапливаются, например в CRM-системе, – можно начать собирать их в хранилище для построения отчетности, делать первые выводы, смотреть, чего не хватает. Постепенно бизнес будет развиваться, и вместе с этим появится понимание, какие данные и метрики вам нужны.

Кристофер Пенн, автор блога «Пробуди в себе супергероя»[1], описал 5 этапов, которые проходит компания на пути к полноценному управлению на основе данных.

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

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

3 этап. Data-aware (осведомленность о данных). В компании появляются энтузиасты и отдельные руководители, понимающие потенциальную ценность данных (возможно, это как раз вы). Они запускают пилотные проекты, строят отчеты и дашборды и начинают разбираться, какие метрики существуют и как их правильно оценивать. Все больше подразделений осознают ценность данных и включаются в работу.

4 этап. Data-savvy (понимание данных). Организация использует данные в большинстве производственных процессов. Например, начинает сегментировать рассылки, пробует выделить группы наиболее ценных клиентов по самым значимым параметрам.

В далеком 2009 году, когда я работал аналитиком в компании «Лента»[2], мы решили провести кластеризацию данных на основе предпочтений клиентов и дать постоянную 5 % скидку всем держателям карт магазина. А еще организовали «клуб любителей алкоголя» и персонально, по электронной почте, отправляли актуальные скидки. Это простое действие принесло впечатляющий результат – более чем 20 % членов клуба купили предложенные товары!

И, наконец, 5 этап. Data-driven (управление на основе данных). Организация непрерывно развивается на основе данных и аналитики. Результаты анализа влияют на ключевые бизнес-процессы.

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

Глава 3

Основополагающие направления работы с данными

Чтобы эффективно работать с данными, компании следует уделять внимание трем направлениям: стратегии, управлению и аналитике (рис. 3).

Рис. 3. Основные направления работы с данными

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

Стратегия отвечает на вопрос «Зачем использовать данные?». И здесь могут быть конкретные ответы: чтобы увеличить доходы, сэкономить на расходах, управлять рисками, повысить качество обслуживания клиентов и т. д. Мы сейчас не будем подробно говорить о том, как составить и оформить эту стратегию. Для каждой компании она своя. Но каждая часть книги позволит вам найти ответы на вопросы и выбрать необходимые инструменты в соответствии с задачами вашей компании.

Грамотно составленная стратегия помогает не просто «держать руку на пульсе» и следить за показателями бизнеса, но и делать прогнозы и принимать решения, основанные на данных.

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

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

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

Управление данными означает создание правил и распределение ролей:

• Какие данные нам нужны?

• Как мы их собираем и где храним?

• Какие инструменты для этого используем?

• Кто этим занимается?

• У каких людей есть доступ к разным данным в компании?

Это помогает всем сотрудникам компании говорить на одном языке и придерживаться одинаковых стандартов. Управление информацией позволяет избежать ситуаций, когда разные отделы одни и те же метрики собирают и считают по-своему.

Управление данными не стоит путать с созданием отдела аналитики (об этом поговорим позднее). Это более высокоуровневый процесс, чем найм специалистов, поскольку он обеспечивает безопасный, удобный и прозрачный доступ к данным для всех сотрудников – не только для дата-команды.

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

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

3. Аналитика – это, собственно, процесс анализа данных компании. То есть то, как мы трактуем и используем их.

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

Польза – это то, ради чего все и затевается.

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

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

Глава 4

Жизненный цикл данных

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

Можно условно выделить пять последовательных этапов:

1. Создание. Это физическое возникновение информации. На этом этапе определяют, какие данные в принципе будут собираться и для каких целей.

2. Прием или загрузка в хранилище.

3. Преобразование. Сюда включается любая подготовка данных к использованию: сортировка, очистка, объединение и так далее.

4. Практическое применение – в нашем случае анализ и прогнозирование.

5. Архивирование или удаление. После завершения работы данные архивируются, сопровождаются подробным описанием (метаданными) и хранятся до следующего использования.

Довольно сложно предсказать, какие именно записи понадобятся даже в среднесрочной перспективе. Поэтому хранить приходится если не всю информацию, то значительную ее часть. Какую именно и как долго?

Здесь есть две крайности: либо избавляться от накопленных данных сразу после их использования, либо хранить вообще все, ничего не удаляя. Первый вариант не подходит для большинства компаний, потому что им важно знать историю бизнес-активности для анализа повторяющихся кризисов. Поэтому аналитики держат в своем арсенале и «старые запасы» данных. Второй вариант использует, например, «ВКонтакте», где годами хранятся даже черновики пользовательских постов и сообщений в переписке. Это требует огромных ресурсов и дополнительных вложений в безопасность. Эта крайность вам тоже вряд ли будет интересна.

Поэтому рациональный ответ на вопрос, каков срок годности данных, будет таким:

информацию имеет смысл использовать, пока она соответствует действительности.

Конкретные сроки будут зависеть от частоты обновления записей и в целом от задач и сферы деятельности. Например, для ретейла маркетинговые данные 10-летней давности уже не так актуальны, как данные о продажах за последний квартал. В целом для прогнозирования не рекомендуется использовать данные старше 5–7 лет, иначе прогнозная модель начнет учитывать неактуальные сведения о бизнесе. В то же время банки и производственные компании, наоборот, по закону обязаны анализировать и хранить данные за десятки лет.

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

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

Глава 5

Ключевые специалисты аналитического отдела

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

Рис. 4. Задачи аналитического отдела

На этапе создания аналитический отдел может состоять из двух специалистов: аналитика и инженера.

Если мы вернемся к жизненному циклу данных, то инженер будет отвечать за все этапы, связанные со сбором, обработкой и хранением информации, а аналитик – за ее практическое применение, то есть анализ и прогнозирование. Первый готовит, второй использует.

Дальше, по мере роста потребностей, можно открывать другие позиции, увеличивая штат. Задачи второго уровня на схеме (рис. 4) распределяются между инженерами данных (Data engineer) и архитекторами данных (Data architect), а те, что обозначены голубым и розовым цветом, – между аналитиками (Data analyst) и специалистами по данным (Data Scientist).

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

Со второй парой чуть сложнее, так как их сферы ответственности пересекаются, а еще Data Scientist часто тоже называют аналитиком, как и Data analyst. Тем не менее они отличаются.

Аналитик (Data analyst) чаще всего не строит прогнозы: он ищет закономерности и тенденции в данных, делает выводы и передает полученные результаты другим сотрудникам. Для этого он визуализирует информацию, то есть использует графики и диаграммы.

Выводы аналитика помогают находить закономерности, на основе которых другие отделы – продажи, финансы, маркетинг и так далее – принимают правильные решения.

Специалист по данным (Data Scientist), в свою очередь, подробнее изучает и расписывает результаты аналитиков. Он не просто ищет взаимосвязи, а пытается понять причины тех или иных явлений, определить факторы, влияющие на изменение данных. Кроме того, он может моделировать задачи и затем создавать прогнозы. Его суперсила – умение вычленять из информации сокрытое, находить неизвестные ранее закономерности.

Организации часто нанимают сначала аналитика, а после уже – специалиста по данным, чтобы он сконцентрировался на самых трудоемких задачах.

Теперь у нас в аналитическом отделе четыре специальности, четыре сферы ответственности: их легко запомнить, если провести аналогию с процессом строительства.

Архитекторы данных – это те же самые архитекторы, что проектируют здание и все его системы.

Инженеры данных – строители. Они претворяют в жизнь план архитектора.

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

А специалисты по данным – это те люди, которые понимают, как все работает на детальном уровне. Это дает им возможность контролировать работу объекта: они делают замеры, снимают показания счетчиков и следят за порядком.

Разумеется, это не финальная версия аналитического отдела. По мере того как усложняются задачи и разрастаются отдельные этапы жизненного цикла информации, создаются новые рабочие места и появляются новые специальности: собственные разработчики, администраторы баз данных, проджект-менеджеры и другие. Мы вернемся к ним в пятой части книги, когда вы уже хорошо разберетесь с основными инструментами и задачами, которые в целом должен решать аналитический отдел. И тогда уже поговорим подробнее о необходимых компетенциях каждого специалиста, а также более предметно разберем их должностные обязанности.

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

Часть 2

Как хранить и организовывать данные

Глава 6

Методы организации данных

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

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

Итак, можно выделить три главных метода организации любых данных: базы, хранилища и озера данных.

База данных (БД, или DB – database) – это большой объем информации, структурированной по определенным правилам и хранящейся в едином виде в одном месте. Благодаря этому с информацией можно работать: собирать, сравнивать, выводить на графики, делать запросы. Это похоже на склад, где не просто полки с разными предметами, а целая система хранения. Вы знаете, в каком блоке стоят холодильники, а в каком – микроволновки. Все структурировано и понятно. И когда вам необходимо найти стиральную машину, то вы сразу идете в отсек, где они хранятся, а не бессистемно ищете по всему ангару. Так же устроены и базы данных. Чтобы получить информацию по сотруднику или нужному товару, нет необходимости перелопачивать кучу документов. Все хранится, учтено и упорядочено в соответствующих базах данных.

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

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

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

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

Любая задача в аналитике должна работать в первую очередь на цели бизнеса.

Поэтому при разработке архитектуры четко проясняем задачи:

1. Какие данные будут храниться? С какой целью?

2. Как часто к ним будут обращаться?

3. Какой объем информации предстоит обрабатывать?

4. Как данные будут использоваться?

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

1. Откуда сейчас стекаются данные и как с ними работают сотрудники?

2. В каком виде хранятся данные?

3. Какие программы, системы, инструменты уже используются в работе? Или, может быть, оплачены, но пока не используются?

Если вы уже используете какие-то сервисы, лучше всего искать решение, совместимое с ними. Например, в 2016 году я присоединился к компании, которая занималась мобильной рекламой. Программисты организации настроили сбор информации. Фиксировались все возможные события в системе: какие действия совершали пользователи, в какой момент и какие возникали ошибки и так далее. Эти данные представляли собой сырые массивы данных и никак не обрабатывались. Сотрудники пытались разобраться, насколько успешны рекламные кампании, однако работа шла медленно и неэффективно: записей много, но использовать их тяжело.

Рис. 5. Скриншот из Kibana – ПО, которое компания использовала для визуализации своих данных

Передо мной стояла задача повысить эффективность и скорость работы с данными. Оказалось, что у компании уже была лицензия на систему управления базами данных HP Vertica. Я предложил руководству создать реляционное хранилище (рассмотрим, что это такое, чуть позже) на ее основе.

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

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

Глава 7

Базы данных (БД)

База данных – это совокупность информации, организованной по определенным правилам.

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

База данных – фундаментальный инструмент для хранения и управления большим объемом информации; она обеспечивает надежность, эффективность и безопасность в работе с ней.

К примеру, базы данных хороши для учета и анализа информации об успехах бизнеса, для хранения записей о предприятии и сотрудниках.

Базы данных бывают разных видов.

Традиционных моделей данных три: иерархическая, сетевая и реляционная.

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

В основе иерархических баз данных, как следует из названия, лежит иерархия, то есть одни объекты подчиняются другим. Вам знакома эта модель: при хранении документов на компьютере под управлением Windows в общей папке «Диск С» есть папка «Фото», в ней – папка «2024», в ней – папка «Море», и там уже отдельные файлы, соответствующие теме.

При таком способе организации найти и извлечь нужную информацию довольно легко – сразу понятно, где какие данные находятся, к чему относятся и как до них добраться. Но для большинства задач такая модель быстро становится чересчур громоздкой. Что, если вы захотите собрать в папку «Море» фото за все годы, но при этом также иметь возможность посмотреть снимки из отпуска только за 2024? Один и тот же документ не может лежать сразу в двух местах. Значит, придется дублировать: исходную папку оставить на месте, а в «Фото» добавить новую папку «Море-2024» и скопировать туда отпускные фото с 2024-го года. Несколько таких операций – и вы совершенно запутаетесь, где и что у вас хранится.

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

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

Эта модель хороша своей оперативностью и эффективностью затрат памяти, так как не нужно создавать дубликаты информации, как в случае с папками «Море» и «Море-2024». Недостатки – сложность и жесткость структуры. Вносить изменения в такую базу будет очень непросто. Кроме того, структура сетевых баз данных удобна для понимания машинами, но пользователям сложнее их считывать, поскольку не так явно видны связи между элементами, а потому нужно отдельно задумываться о понятной визуализации.

Рис. 6. Сетевая база данных

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

Реляционные базы данных

В реляционной базе данные структурированы в виде таблиц, содержащих строки и столбцы с заданными взаимосвязями.

Эта модель опирается на реляционную алгебру, замкнутую систему обращений к данным и действий с ними, и использует SQL – структурированный язык запросов, который применяется для получения, создания и изменения информации в базах данных табличного типа.

Рис. 7. Microsoft Exсel устроен по принципу реляционной базы данных

Вообще, стоит отметить, что большая часть работы аналитиков напрямую связана с языком SQL. В последние годы, в связи с широким распространением облачных баз данных, SQL стал снова популярен. Сейчас он повсеместно используется аналитиками и инженерами данных в современных решениях типа dbt (data build tool) – инструмента для трансформации данных на основе SQL-запросов.

Термин «реляционный» происходит от английского relations – «отношения», так называют связи данных в таблицах. Структура отдельных таблиц может отличаться, но внутри каждой должны быть уникальные столбцы и колонки. Скорее всего, вы уже сталкивались с реляционной базой данный, поскольку Microsoft Exсel устроен по ее принципу. Одна из наиболее распространенных систем управления такими базами – MySQL — часто используется для большинства веб-приложений и сайтов. Вторая по популярности – PostgreSQL. К этому типу также относятся Microsoft SQL Server (MS SQL).

Преимущества реляционной модели данных:

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

• Простая организация хранения данных: программы быстрее обрабатывают информацию, упрощая работу аналитиков.

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

Приведу пример. Я помогал крупной сети супермаркетов создать базу данных для работы отдела маркетинга. Изначально они использовали для хранения данных MS Excel и тратили несколько суток на поиск нужной информации и создание отчетов. Ведь сами по себе таблицы Excel не предназначены для хранения большого объема информации, вы должны заполнять их вручную, при этом невозможно эффективно связать несколько таблиц между собой. А потому первым делом я предложил руководителю создать базу данных с записями о заказах (чеках).

Мы использовали Microsoft SQL Server: транзакционнные данные из системы SAP (система планирования ресурсов корпораций, аналог 1С) загружались в SQL-сервер и затем использовались для анализа. База данных объемом несколько гигабайт находилась на выделенном компьютере. Хотя сегодня такой объем может показаться ничтожно малым для непрерывной записи, но в то время этого было достаточно. В базе содержались таблицы «Заказы» с ключами «Дата», «ID чека», «Товар», «Категория», «Идентификатор магазина» и другие.

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

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

• Информация о покупках. Название товара, категория, цена.

• Идентификатор покупки. Можно ограничиться номером чека, а можно присвоить уникальные идентификаторы постоянным клиентам, например через номер бонусной карты, как в примере выше.

• Время покупки. Это поле важно как для маркетинга (чтобы определить, когда товары должны быть размещены на полках), так и для администратора магазина. Когда пик спроса на товары наибольший, нужно обеспечить работу максимального количества касс.

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

Если вы хотите, чтобы реляционная база работала корректно, она должна быть целостной, а данные в ней – нормализованными и структурированными. И последнее условие – информация должна обрабатываться с помощью вычислительных систем.

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

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

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

Начинающие аналитики, а порой даже профессионалы, тратят едва ли не половину рабочего времени на приведение данных к стандартному виду. Рассмотрим на примере.

Представьте гипермаркет. В нем продается 40 тысяч товаров. И ежедневно клиенты совершают миллион покупок.

Какая проблема может возникнуть с информацией? Например, сегодня один менеджер ввел адресные данные клиента для доставки. А завтра второй продублировал тот же адрес, но изменил в нем один символ. Допустим, зафиксировал название улицы с маленькой буквы. Теперь в базе хранятся разные названия одного и того же адреса доставки.

Если вы захотите построить отчет по продажам с разбивкой по адресам доставки, то неизбежно столкнетесь с головной болью: как всю эту информацию свести воедино? Аналитику придется тратить кучу времени на очистку и нормализацию данных, убирать лишние пробелы, запятые, править регистр некоторых букв, удалять лишние слова, пытаясь привести все к единому виду. И только после этого приступать к анализу. То есть заниматься не столько самой отчетностью, сколько подготовкой записей к ней.

Конечно, так быть не должно. Ведь это отнимает лишнее время. Именно поэтому должны быть четкие и единые правила заполнения баз данных.

Та же проблема может возникать со стороны пользователей. Например, у нас была задача по нормализации клиентской базы в компании «Юлмарт». Они не сразу настроили ограничения для полей на странице регистрации, и 10 миллионов клиентов ввели свой адрес как попало. Кто-то указал страну. Некоторые – только город. Другие – улицу. А были и те, кто вообще ничего не написал. Только на очистку данных мы потратили не один месяц.

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

Базы данных NoSQL

NoSQL базы данных были придуманы больше двадцати лет назад, но активно и охотно пользоваться ими стали не так давно. NoSQL расшифровывается как Not only SQL, то есть «не только SQL». Это понятие включает в себя разные продукты, которые могут поддерживать или не поддерживать SQL-запросы. Главное, что их объединяет, – попытка уйти от ограничений реляционных баз данных, в первую очередь от их статической, плохо масштабируемой структуры.

Дело в том, что структура реляционной базы данных – одновременно ее сила и слабость. Заранее определенные поля и связи позволяют сохранять информацию целостной и согласованной. Вы не можете ввести что попало куда попало, а значит, «мусора» в системе будет меньше. Она способна выполнять даже сложные запросы, потому что в ней все разложено по полочкам: информацию легко фильтровать, сортировать, объединять и так далее.

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

Здесь-то и приходят на помощь NoSQL базы данных: в них записи хранятся в отдельных документах, парах «ключ – значение», графовых базах данных или базах с широкими столбцами.

• Пара «ключ – значение». Самый простой вид баз данных. Его используют для хранения изображений и видео, а также как кеш, то есть буфер для временного хранения объектов в рекламных и игровых приложениях. Пример работы таких баз данных – сайты популярных компаний, когда при загрузке вы видите начало статьи, а затем кнопку «Еще» или «Подробнее». Именно технология «ключ – значение» позволяет молниеносно подгружать большой текст, когда вы нажимаете на эти кнопки. Этот вид баз данных также подходит для организации пользовательских аккаунтов, каталогов, систем управления контентом, в которых файлы могут меняться с течением времени. Примеры таких баз: Oracle, Berkeley, Redis, Amazon DynamoDB, CouchDB, eXist, MongoDB.

• Колоночная база. Уже знакомая нам таблица, только данные в ней сгруппированы не в строки, а в колонки. Возьмем мобильную рекламную сеть. Обрабатывать большое количество данных ей помогают именно колоночные базы данных. Примеры самых популярных: Vertica, Clickhouse, BigQuery, Cassandra, Apache HBase, Hypertable.

• Графовое хранилище. Их используют для организации дорожных карт, маршрутов транспорта, социальных сетей. Когда вы смотрите рекомендации в онлайн-кинотеатрах, способы добраться из точки А в точку Б, используя несколько видов транспорта, в «Яндекс Картах», или переходите со своей страницы во «Вконтакте» на страницу друга – все это организовано с помощью графовых хранилищ. Примеры: Amazon Neptune, InfoGrid, Orient, Blazegraph, Titan.

Рис. 8. Архитектура SQL и NoSQL

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

Многие NoSQL базы данных также предоставляют встроенную поддержку распределенности данных и отказоустойчивости. Распределенность данных означает, что они хранятся не на одном сервере, а на нескольких, позволяя подключить к работе дополнительные мощности, быстрее и эффективнее обрабатывать большие объемы информации. А отказоустойчивость – не что иное, как защита от сбоя и поломок. Если выйдет из строя один сервер, то в распределенной системе есть еще несколько, которые возьмут нагрузку на себя. Значит, данные не будут утеряны, а работа не встанет намертво.

Но у NoSQL баз данных есть ряд серьезных ограничений:

• Так как мы отказались от строгой структуры, появился риск того, что данные в какой-то момент потеряют целостность и станут несогласованными, то есть начнут противоречить друг другу.

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

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

• Если вам понадобится обновить схему данных, это может занять много времени.

В таблице (рис. 9) вы видите сравнительные характеристики реляционных баз данных и NoSQL:

Рис. 9. Сравнительные характеристики реляционных баз данных и NoSQL

Колоночные базы данных

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

На рисунке (рис. 10) пример колоночной базы данных. Значения одного поля в колоночной базе данных хранятся на диске последовательно: A1-A2-A3-А4, затем B1-B2-B3-В4, потом C1-C2-C3-С4.

Рис. 10. Пример колоночной БД

Благодаря такому строению при аналитических операциях с колоночной базой данных скорость обработки информации повышается. Реляционные базы с увеличением нагрузки замедляются или требуют больше вычислительных мощностей, потому что во время создания отчетов им приходится анализировать лишнюю информацию. И чем больше записей (строк), тем заметнее проблема.

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

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

А теперь представим, что эта же база данных хранится в колоночном формате. Это значит, что мы можем сразу выделить только нужные нам колонки и посчитать информацию из них. Проделайте то же упражнение: найдите глазами выручку, количество пользователей и товаров и пробегитесь по этим трем столбцам сверху вниз. Получилось быстрее, чем в прошлом варианте, правда? А теперь представьте, что таких строк у вас тысячи, сотни тысяч, миллионы. Как вы понимаете, производительность у двух этих методов будет сильно отличаться.

Кроме того, у колоночных баз есть возможность сжатия данных, которые необходимо считывать с диска. Например, если часть записей связана с датой, то записи в файле можно организовать в виде [количество повторов, дата]. Такая запись уменьшает размер базы на несколько порядков. Таким образом, колоночные базы данных требуют в 7 раз меньше памяти.

Пример колоночной базы данных – ClickHouse, которая изначально создавалась для решения задач «Яндекс. Метрики». Ее исходный код доступен для просмотра, изучения, изменения и доработки. Эта база данных позволяет строить произвольные отчеты и выполнять аналитические запросы в режиме реального времени, обрабатывать быстро и точно огромные объемы информации, считать метрики и своевременно формировать аналитические отчеты. Именно поэтому одним из главных преимуществ колоночных баз данных считается скорость. Она превышает самые смелые ожидания – работает в 10–100 раз быстрее реляционных БД.

Еще одно преимущество – расширяемость. Колоночная БД может использовать множество внешних подключений, например интегрироваться с S3 bucket, Apache Kafka или другими.

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

И для закрепления приведу пример из практики.

Однажды ко мне обратились разработчики приложения по организации правильного питания и интервального голодания. Компания хотела стабильно получать маркетинговую информацию и быстро ее анализировать. До этого системно решить задачу не получалось.

Начали разбираться. Оказалось, что для решения вопроса заказчика нужно получать, хранить и обрабатывать несколько типов данных:

• информацию о действиях пользователя в приложении: например, об установке, нажатии кнопок и так далее;

• данные из рекламных кабинетов о продвижении в соцсетях;

• информацию из сторонней системы (данные из виртуальных магазинов, где покупается приложение).

Что у компании уже было?База данных, которая пополнялась в режиме реального времени. Аналитика в фирме не велась, но разработчики понимали, как должно выглядеть хранилище данных, а это уже залог успеха.

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

• события, которые происходят в приложении (клики, переходы по разделам, покупки и переписки пользователей);

• события, которые отвечают за выручку (фиксируется каждая покупка);

• данные о рекламных расходах.

Преобразование данных из неструктурированного вида в четкую колоночную базу позволило компании легко и быстро писать запросы, получать информацию об эффективности рекламных кампаний, выручке и активности пользователей. Цель была успешно достигнута!

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

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

Гибридные базы данных

Часто лучшим решением становится именно сочетание реляционной и NoSQL баз данных. Такой вариант называется гибридной базой данных (рис. 11).

Гибридные базы данных активно развивались в течение последних десятилетий. В 2013 году компания Gartner ввела термин «гибридная транзакционная/аналитическая обработка» или HTAP. Основное преимущество архитектуры HTAP – одновременное выполнение транзакционных и аналитических процессов, что дает больше возможностей для сбора и обработки данных.

Рис. 11. Гибридная БД

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

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

Высокий уровень доступности. За счет того, что NoSQL вместо таблиц использует гибкие модели хранения данных – документы, графы, пары «ключ – значение», – мы получаем более легкий доступ к данным. К примеру, вводя комментарий к записи в социальных сетях, вы моментально видите, как он подгружается и отображается на странице.

Масштабируемость. За счет использования реляционных таблиц нет нужды хранить в оперативной памяти всю базу данных.

Гибкость. Гибридные базы могут работать с большим объемом совершенно разных данных: файлов, баз с информацией, транзакций. Могут практически моментально анализировать данные и на основе этого помогать принимать решения. Этот процесс называется гибридной транзакционной и аналитической обработкой (Hybrid Transaction-analytical Processind – HTAP). Благодаря этому базы подходят для сервисов и приложений, работающих в режиме реального времени.

Стабильность работы. Гибридные базы данных могут обеспечить бесперебойную онлайн-работу с клиентами. Для этого как раз используется HTAP. Сейчас это самая экономически выгодная стратегия, позволяющая достичь максимальной производительности и скорости работы.

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

На практике гибридные базы данных обычно используют в двух вариантах.

База данных документов

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

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

База данных In-Memory и графовая база данных

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

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

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

Более выгодный вариант – создание графовых баз, в которых будут отслеживаться все ваши предпочтения, ваши друзья и их интересы. Графовые базы данных ищут и по сущностям, и по связям между ними. За счет этого они оптимизированы для быстрого поиска и выполнения запросов. Примеры таких баз in-memory – Memcached и Redis.

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

Глава 8

Хранилища данных (DWH)

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

Но алгоритмы программ и принципы их работы с информацией сильно отличались. Получить единую картину из разрозненных элементов было фактически нереально. Да и понятия о консолидированных данных на тот момент еще не существовало. Хотя бизнесу они были очень нужны. Кроме того, эту информацию надо было также где-то хранить и обрабатывать.

Для решения этих вопросов было разработано хранилище данных (Data Warehouse – DWH). DWH устроено по такому же принципу, как и базы данных, описанные выше. Единственное отличие – это возможность хранить в нем не одну базу данных, а множество. Хранилище можно назвать домом всех баз данных.

Правильно выстроенное хранилище позволяет учитывать разные бизнес-процессы компании и держать все данные в одном месте.

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

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

Рис. 12. Схема ELT-процесса

Почему аналитические хранилища настолько привлекательны для бизнеса? И нужны ли они вам? Давайте разбираться.

Аналитики на практике используют три основных типа DWH:

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

Хранилище оперативных данных (Operational Data Store) – это хранилище, дающее доступ к обновленной информации в режиме реального времени. Оно оптимально для осуществления повседневных операций, то есть в нем находятся данные, которые регулярно обновляются и влияют на работу компании.

Аналитическое хранилище данных — главный инструмент аналитика. Поскольку его работа требует регулярного обращения к базам данных для построения отчетов, иногда нагрузка на сервер бывает крайне высокой. Поэтому создают отдельное хранилище исключительно для задач аналитики.

Рис. 13. Типы аналитических хранилищ

Перед разработкой хранилища следует ответить на ряд вопросов:

• Что вы планируете в нем хранить?

• Для какой цели оно строится: регулярная отчетность, бизнес-анализ действий покупателей или внутренних процессов организации?

• На какой объем данных оно рассчитано?

• Как часто данные будут обновляться?

• Кто будет иметь доступ к хранилищу?

На основании ответов создается внутренний документ с описанием требований к хранилищу, его логической и физической структуре.

В моей практике был такой пример: иностранная фирма Vembla разрабатывала приложение – аналог «Самоката» (сервис доставки продуктов на дом). Основное преимущество фирмы Vembla – доставка заказа за 15 минут. Прежде компания использовала информацию со старой версии сайта, загруженной в медленное хранилище для резервных копий. Но этого было явно мало, и они хотели построить аналитическое хранилище. Самое главное – руководители четко понимали, что хотели бы там видеть.

Что мы сделали?

На тот момент у компании уже были свои облачные хранилища для разработчиков, поэтому мы выбрали простой и действенный путь:

• расширили существующее хранилище, потому что развертывание нового и перемещение в него данных в данном случае нерационально;

• дополнили его инструментами для создания полноценного аналитического хранилища;

• создали возможность для сбора в одном месте информации о скорости доставки, о возражениях клиентов, данных из рекламных кампаний, из Apple Store, Facebook*, отзывов и так далее.

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

Рассмотрим работу с аналитическим хранилищем на примере гипермаркета «Лента» (рис. 14). Возьмем два отдела: аналитический и отдел закупок. Руководитель второго планирует определенное количество поставок товара, и ему необходимо спрогнозировать, как изменится объем сбыта, если снизить цену в магазине на эту позицию на 10, 15 и 20 % соответственно. Маркетинговому аналитику необходимо прикинуть и рассчитать такие модели. У него есть аналитическое хранилище, которое помогает ответить на вопросы руководителя отдела закупок. Аналитик обращается к опыту проведения похожих акций, смотрит прежние результаты и создает запрос на отслеживание изменения спроса с начала распродажи. Далее аналитик строит модель-прогноз и передает его результаты в отдел закупок. И уже на основании цифр руководитель принимает решение.

Рис. 14. Алгоритм работы с аналитическим хранилищем

Что происходит, если аналитического хранилища нет? Тогда этот же пример выглядит совсем иначе.

Информацию о работе магазина взять негде. Руководитель собирает менеджеров на совещание. Там высказывают несколько гипотез. Наиболее вероятные (и не всегда правильные) теории проверяют на практике путем перебора вариантов. И в итоге зачастую виновными в падении доходов оказываются линейные сотрудники.

Единство хранения информации обеспечивает:

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

При использовании DWH все хранится в одном месте и данные можно получить незамедлительно, написав запрос к хранилищу.

Сохранность данных. В корпоративном хранилище «забыть» что-то невозможно. Информация изначально записывается в удобном виде. Для DWH норма – хранить данные за 10 и более лет.

Надежность работы других систем. Аналитик работает напрямую с аналитическим хранилищем, других баз данных он не касается.

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

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

Вернемся к предыдущему примеру с падением продаж в магазине.

Зачем здесь нужно аналитическое хранилище данных? Ведь всю информацию можно взять из обычных баз. Но так поступать опасно. Во-первых, согласование доступов потребует времени. Во-вторых, затормозит работу отделов. И в-третьих, информацию понадобится привести в единый вид, а уже потом изучать.

Ключевой момент: нельзя использовать данные, которые находятся в продакшене (в «боевых» базах данных, вовлеченных в текущие рабочие процессы), для целей аналитики. Поскольку аналитический запрос может перегрузить их, основные операции для пользователей будут заблокированы, и это может обернуться потерей клиентов, а следовательно, и выручки.

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

Приведу еще один пример использования аналитического хранилища. Ко мне обратилась компания – разработчик мобильного приложения, игры по типу Match-3 или «Три в ряд». Это игра, в которой нужно соединить несколько линий в одну, пройти определенные уровни. По ходу можно покупать доспехи, апгрейды для персонажа.

Компания хотела получить продуктовую аналитику и понять:

• насколько хорошо игроки проходят уровни,

• какой уровень для них сложный,

• когда клиенты уходят.

А также разобраться с эффективностью рекламы:

• какая доля пользователей открывает приложение,

• сколько игроков доходит до покупки.

Как можно решить эти задачи? Например, с помощью сервисов мобильной аналитики.

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

И как только возникает сложная задача, сервис может с ней не справиться.

Что мы сделали?

Во-первых, подобрали решение для сбора информации – Firebase. С его помощью разметили все движения пользователя, затем включили экспорт данных в хранилище Google BigQuery.

Во-вторых, создали аналитическое хранилище и добавили в него экспорт информации из рекламных кабинетов (разработчики покупали рекламу в соцсетях). Мы собрали в одном месте данные о действиях пользователя и маркетинговых затратах.

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

Все это помогло проанализировать информацию и понять, насколько эффективна реклама и не зря ли потрачены деньги.

Глава 9

Озера данных (Data Lake)

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

Почему компании выгодно хранить информацию в Data Lake? Вот лишь несколько преимуществ озер данных:

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

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

• Централизация и прозрачность данных. В озерах информация собирается в одном месте, ее можно детализировать и находить что-то ценное как для каждого отдела компании, так и для бизнеса в целом. При этом стираются барьеры между отдельными подразделениями.

• Доступность. Об этом мы уже говорили ранее: обслуживание озер данных обходится дешевле, чем баз данных, из-за того, что информация не нуждается в предварительной обработке. Кроме того, стартовать можно с «мини-озер» и постепенно наращивать мощность. Это удобно даже для среднего и малого бизнеса.

В чем преимущества озер по сравнению с хранилищами данных?

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

Плюсы такого подхода:

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

• Автономность. Несколько отделов могут одновременно использовать одни и те же данные.

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

Во-вторых, в «озерах» хранятся так называемые «сырые» (необработанные) данные, тогда как в хранилищах информация, попадая из первичных источников, преобразуется и загружается в таблицы. И именно структурированные данные зачастую нужны бизнес-пользователям.

Чем же удобно хранение информации в «озерах»? Тем, что в любой момент нужные сведения можно получить из исходных данных. К тому же можно изменить метод обработки, добавить необходимые показатели, которые не вошли в первоначальную выборку. В случае с хранилищами вся несохраненная, «сырая» информация будет утрачена, потому что данные хранят по определенной схеме, которая жестко фиксирует состав полей.

В-третьих, информация в «озерах» может храниться в любом объеме, и для пользователей доступ к ней можно открыть одновременно из любых точек мира.

Озера данных в первую очередь необходимы компаниям, в которых много отдельных команд. Например, Amazon ранее собирал информацию из нескольких тысяч разных источников. Она хранилась в десятках БД, что создавало массу неудобств и порождало путаницу.

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

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

Еще один пример уже из моей практики.

Крупная европейская телекоммуникационная компания пригласила меня с коллегами помочь им с инжинирингом данных. Они занимаются продвижением приложения «виртуальный оператор», что-то вроде Skype. Функционал похожий: онлайн-звонки на разные номера через созданный виртуальный мобильный номер.

Вся информация у них хранилась в классическом озере данных. То есть провайдер услуг предоставлял информацию по совершенным звонкам и складывал их в S3 bucket на платформе AWS. При этом данные не были структурированы – просто лежали большим пластом отдельных файлов.

Какую задачу поставили перед нами? Используя имеющееся озеро данных, построить аналитическое хранилище, которое позволит подсчитать:

• ежедневное количество входящих звонков;

• ежедневное количество исходящих звонков;

• ежедневное количество пропущенных звонков.

Для этого мы использовали технологии AWS Glue: создали скрипты, которые позволили взять информацию из S3 bucket и сложить в колоночную базу от Amazon. И данные начали «работать», предоставляя пользователям удобные отчеты в Looker (система класса BI для самообслуживания по задачам аналитики).

Как работает озеро данных?

Архитектура озера данных состоит из пяти ключевых компонентов (рис. 15):

Рис. 15. Архитектура озера данных

• Прием данных (Data ingestion): получение данных из различных источников на носитель, где они могут быть доступны для использования и анализа.

• Хранение (Data storage): магнитный, оптический или механический носитель, на котором хранятся цифровые данные.

• Безопасность (Data security): защита информации на протяжении всего срока ее службы от нежелательного доступа, манипуляций или кражи.

• Происхождение данных (Data lineage): в озере хранится информация о поступлении, изменении или перемещении данных, включая ту, которая была преобразована.

• Управление данными (Data governance): процесс управления доступностью, качеством и безопасностью информации в бизнес-системах на основе внутренних стандартов и правил. Эффективное управление данными гарантирует, что они не противоречивы, надежны и не будут обработаны неправильно.

Все эти компоненты есть у нескольких облачных сервисов, с которыми компании могут продуктивно работать:

1. Google Data Lake;

2. Веб-сервисы Amazon – озеро данных AWS;

3. Microsoft Azure Data Lake;

4. Snowflake.

Подводные камни в работе с озерами данных

Помимо очевидных преимуществ, в работе с озерами данных есть и свои сложности.

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

Если компания не умеет качественно работать с информацией, есть шанс, что озеро превратится в «болото».

Это может произойти, если в озере:

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

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

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

Нет автоматизированных процессов для поддержания данных. Автоматизация позволяет обрабатывать все данные одинаковыми способами.

Дома у озер данных (Lakehouse)

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

Но несмотря на то, что озера подходят для хранения данных, им не хватает некоторых важных функций. Например, возможности одновременного чтения и записи информации несколькими пользователями.

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

поскольку специалистам по работе с информацией приходится постоянно перемещать файлы между разными системами или копировать их.

Рис. 16. Дом у озера – система, которая объединяет лучшее от озер и хранилищ

Чтобы справиться с этой проблемой, специалисты разработали новую систему хранения информации – дом у озера данных (Lakehouse). Это новая открытая архитектура, соединяющая в себе лучшее от озер и хранилищ: дешевизну первых и структурность вторых.

Рассмотрим основные характеристики домов у озер данных:

• Поддержка транзакций. В доме у озера пользователи могут одновременно читать и записывать данные.

• Поддержка BI[3]. Озерные дома позволяют использовать инструменты BI непосредственно на исходных данных. Это уменьшает затраты на использование двух копий данных как в озере, так и в хранилище.

• Хранение отдельно от вычислений. Для хранения используются отдельные кластеры, поэтому дома у озера способны масштабироваться для большего числа одновременных пользователей и разного объема данных.

• Открытость. Используемые форматы хранения открыты и стандартизированы. Например, используется Parquet, чтобы различные инструменты и движки, включая библиотеки машинного обучения и языки Python/R, могли эффективно обращаться к данным напрямую.

• Поддержка различных типов данных. Дома у озер можно использовать для хранения, уточнения, анализа информации и доступа к разным типам данных: изображениям, видео, аудио, полуструктурированным записям и документам.

• Поддержка различных рабочих нагрузок, в том числе машинного обучения, алгоритмов обработки данных и аналитики.

• Потоковая передача данных. Устраняет необходимость в отдельных системах, предназначенных для обслуживания приложений, работающих с информацией в реальном времени.

Это ключевые преимущества домов у озера: простота, скорость, экономичность и способность обслуживать различные приложения для работы с данными.

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

Часть 3

Как быстро и эффективно обрабатывать данные

Глава 10

Инжиниринг данных

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

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

• Программист пишет кучу скриптов.

• Они постоянно ломаются, в них возникают ошибки, а еще – появляются новые запросы, из-за чего нужно писать новые скрипты.

• Они тоже ломаются, поэтому их тоже надо чинить и обновлять.

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

Что же делать?

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

Инжиниринг данных, то есть организованный процесс обработки информации, позволяет оптимально использовать ресурсы.

Он включает:

• Выбор и настройку подходящих инструментов.

• Регулирование сбора, хранения и использования данных.

В идеале необходимо создать собственный пайплайн для обработки данных (мы подробно поговорим о нем чуть позже). А сейчас вспомним, какой специалист аналитического отдела поможет нам с разработкой инфраструктуры для сбора и обработки данных. Мы упоминали его в первой части, и это инженер данных.

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

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

Рассмотрим на примере инжиниринга данных приложения по организации здорового питания.

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

Рис. 17. Интерфейс рекламного кабинета

Пошагово весь процесс сбора и подготовки информации выглядит так:

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

Есть несколько способов получить эту информацию: собрать скриптами самостоятельно или воспользоваться специальными коробочными продуктами.

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

3. Кроме того, информацию нужно проверить на достоверность, исправить найденные ошибки. Все это можно делать как вручную, так и с использованием специальных инструментов для трансформации данных. Одним из популярных сегодня является dbt (data building tool).

4. Данные объединяются и преобразуются. Чтобы построить, допустим, анализ когорт или сделать выводы об успехах продукта, одних рекламных данных будет недостаточно. А потому на этапе преобразования создают так называемые staging-витрины – промежуточные таблицы для хранения и расчета информации. В них объединяются внутренние и внешние сведения, данные из разных рекламных кабинетов (информация будет в разрозненном виде), результаты биллинга.

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

Для чего нужны все эти шаги?

Компании, которая заботится о своих аналитических процессах, важно не только получать данные для анализа, но и преобразовывать их. Данные нужно делать максимально удобными для работы (вспомним о стандартизации и нормализации), лишь тогда можно будет составить корректные отчеты и дашборды. Этим тоже занимается инженер данных. Он создает специальную систему, обрабатывает информацию и помогает настроить хранение данных.

Глава 11

Пайплайн и стек данных

Именно пайплайн и стек данных приходят на помощь инженеру, перед которым стоит задача сделать данные всегда доступными для обработки и анализа. Давайте разберем подробнее, что это такое и зачем нужно.

Специалисты называют пайплайном данных (data pipeline) процесс обработки информации и ее перехода из состояния А в состояние Б. Если объяснять на простом примере, то это похоже на процесс приготовления пасты с креветками из отдельных ингредиентов с помощью пошагового рецепта: пайплайн данных разделен на этапы так, что один процесс преобразования информации плавно переходит в другой. А в итоге мы получаем готовый дашборд.

По существующим стандартам обработки данных пайплайн должен охватывать:

• сбор данных;

• их первичную трансформацию и хранение – очередность этих процессов может меняться;

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

Обратимся ненадолго к истории появления пайплайна. Это поможет вам лучше понять его суть.

К началу XXI века сформировались две тенденции, развивающиеся до сих пор:

1. Постоянный прирост данных.

2. Непрерывное усложнение их обработки.

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

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

Наша команда LEFT JOIN работала с французской компанией Aircall, занимающейся виртуальной телефонией. На тот момент я уже отошел от штатной работы и консультировал совершенно разные компании по любым вопросам в сфере аналитики. И однажды руководитель обратился ко мне с просьбой отладить инжиниринг данных в его фирме.

Что у компании было?

Логи – JSON-файлы, которые хранились в Amazon S3. В них была собрана вся возможная информация о звонках (время их начала, длительность, переводы с линии на линию и так далее).

Что мы сделали?

Использовали инструмент AWS Glue, который позволяет писать разные скрипты на языке Python для DAG’ов, преобразующих данные из JSON-файлов в реляционную форму, доступную для анализа современными BI-инструментами.

Из набора таких направленных графов выстроили пайплайн для преобразования и объединения данных.

Мы создали аналитические витрины, позволяющие видеть и анализировать ключевые показатели компании с помощью инструмента Looker. Он уже был внедрен в работу компании до нас.

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

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

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

Задача стека данных – не заменить специалиста, а создать для него комфортные условия работы. Рассмотрим подробнее, как появился стек и как он устроен.

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

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

При этом процессы трансформации данных строились с применением других решений, таких как Teradata. Эти программные компоненты должны были устанавливаться внутри компании: соответственно, необходимо было администрировать оборудование и установленный софт.

Рис. 18. Традиционный пайплайн обработки данных

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

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

• Медленная адаптация к новой информации. На выполнение рутинных операций тратится слишком много времени, оперативно принимать важные решения при этом невозможно.

• Неоправданно высокие затраты. Установка и поддержка традиционного стека данных требует привлечения огромного количества специалистов. На закупку оборудования нужны деньги, как и на попытки оптимизировать локальную инфраструктуру.

Рис. 19. Кластерная структура хранения данных, которая была призвана повысить эффективность вычислений

Все перечисленное вызывает ряд системных проблем, снижая эффективность работы как стека, так и команды специалистов.

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

И главное – это решение должно было быть недорогим и доступным к моментальному запуску. Им оказался современный стек данных.

Современный стек данных – это система инструментов, которая размещается в облачных сервисах и позволяет компаниям:

• максимально эффективно использовать данные,

• оптимизировать затраты на их обработку и использование,

• автоматически получать свежие отчеты и своевременно реагировать на изменения рынка.

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

Рис. 20. Вариант современного стека данных

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

Что же такое современный стек данных с практической точки зрения?

В минимальном варианте он включает следующие элементы:

• сбор данных (возможно использование инструментов Stitch, Fivetran);

• хранение информации (Redshift, BigQuery, Snowflake);

• трансформацию или преобразование (могут применяться dbt, другие инструменты);

• бизнес-анализ данных (применимы Periscope, Metabase, Looker).

Более сложный вариант современного стека данных с возможными инструментами представлен на схеме (рис. 20).

Безусловно, элементы стека данных могут меняться в зависимости от целей и задач каждой организации. Чем больше подключений и инструментов планируется использовать, тем сложнее становится настройка и установка стека данных. Почему так происходит? Чтобы ответить на этот вопрос, рассмотрим несколько примеров.

Нашу команду LEFT JOIN пригласили помочь выстроить комплексную архитектуру данных со множеством подключений и инструментов для компании, занимающейся беттингом – ставками на спорт. В фирме использовались 12 MySQL-серверов для разных стран, куда стекалась вся информация. И, соответственно, запускалось огромное количество процессов: записывались данные, пополнялись справочники и так далее.

Что мы сделали? Создали аналитические витрины. Для этого данные с серверов направляли в ClickHouse, где они обрабатывались с помощью встроенного в хранилище инструмента «Материализованные представления». Это потребовало огромного труда, но в итоге сейчас компания получает отчеты с актуальной маркетинговой и финансовой информацией.

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

Например, есть простые и свободно распространяемые инструменты:

• Airbyte позволяет подключаться к рекламным кабинетам и собирать данные.

• Для управления базами данных пригодятся PostgreSQL или ClickHouse.

• Трансформацию данных можно запустить на Python/Go, а оркестрацию настроить в Apache Airflow.

• Dbt используют для обработки и трансформации данных, развернув этот инструмент локально на собственном виртуальном компьютере[4].

• Для визуализации подойдет Redash с открытым исходным кодом.

У всех инструментов, кроме dbt, понятный графический интерфейс, множество удобных настроек и коннекторов. Такой стек можно развернуть самостоятельно на облачном виртуальном инстансе.

Например, для шведского даркстора Vembla мы с командой LEFT JOIN развернули довольно простой стек данных в облаке:

• Написали скрипты на Python для сбора маркетинговых данных через API рекламных аккаунтов (Facebook* и Google), которые управляются через Apache Airflow.

• Компания теперь использует озеро данных на Amazon S3 как хранилище, где собираются новые данные и информация с их старого сайта.

• Для аналитики используется версия BI с открытым кодом Metabase.

А бывает, подходят решения даже более простые, чем с даркстором. Так вышло с онлайн-игрой RightSoft Labs. Мы с командой развернули для них стек данных в облаке, решив тем самым запрос клиента:

• Сбор данных реализовали через исполнение Python-скриптов под управлением Airflow.

• Часть DAG’ов внутри Airflow настроили на отправку данных в облачное хранилище и первичную трансформацию.

И чтобы определиться, какой стек нужен именно вам, ответьте себе на несколько вопросов:

• Какие задачи мой бизнес будет решать с помощью данных? Это может быть улучшение управленческих процессов, повышение прибыли, сокращение издержек.

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

• Что хочется видеть в результате анализа данных? Другими словами, получили отчет или дашборд, а дальше что?

• И главное, что для вас значит быстро развернуть стек? За неделю или за сутки?

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

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

Теперь давайте рассмотрим, какие процессы реализуются в стеке данных.

Процессы в стеке

Подготовка данных к анализу основывается на трех китах:

• Извлечение данные из источника (Extract).

• Приведение их в вид, пригодный для использования (Transform).

• Загрузка в хранилище (Load).

А связываются эти три кита с помощью двух разных последовательностей исполнения: ETL (Extract-Transform-Load) и ELT (Extract-Load-Transform). Почему так важно с ними разобраться? Все дело в том, что дальнейшие способы работы с данными зависят от способа и скорости загрузки информации в базы, а также от выбора правильных инструментов.

ETL-процессы (Extract, Transform, Load)

В последние годы процедуры извлечения (extract) и загрузки (load) отделяют от трансформации (transform) – подготовки данных к анализу. Однако на практике до сих пор можно встретить и объединенные ETL-процессы, поскольку исторически такая последовательность была стандартным методом работы с данными.

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

Как же работают ETL-процессы?

Простым языком, это можно описать так:

1. Мы берем информацию из источника ее возникновения.

2. Тут же трансформируем для целей аналитики.

3. Загружаем данные в измененном (обычно агрегированном) виде.

Давайте разберем, какие данные куда и как загружать, на примере телеком-компании.

В начале, как правило, ситуация стандартная:

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

2. Аналитическое подразделение не получает желаемых ресурсов: в нужном объеме компания не может себе их позволить, а потому экономит на оборудовании для аналитиков.

3. Обычно в таком случае компания выделяет специальный кластер данных – отдельный набор машин исключительно для задач аналитики.

4. Выделить несколько машин – слишком дорого. Поэтому работать с исходными или «сырыми» данными нет возможности. В этой ситуации аналитики просят построить витрины данных: массивы, в которых будет храниться обработанная и отсортированная информация.

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

6. Построение витрин данных, начиная с их извлечения и трансформации и заканчивая заполненным хранилищем, происходит в технических командах. Потом команда специалистов работает с этими агрегатами в своем аналитическом хранилище.

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

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

Разработчики продуктов по управлению обработкой данных пытались решить проблему, даже достигли некоторых успехов, но окончательно устранить ее не смогли. Так длилось до 2000-х годов. Именно тогда возникло несколько новых решений, и ситуация резко изменилась.

Появились облачные технологии и сервисы. Обработка и хранение данных стали более доступны и переместились на облачные серверы. Необходимость растить собственный парк оборудования для обработки данных отпала. И на смену ETL пришли ELT-процессы. И сейчас самое время изучить их поподробнее.

ELT-процессы (Extract, Load, Transform)

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

• позволяют обрабатывать данные в режиме реального времени, то есть сразу после получения;

• максимально облегчают использование облачных технологий;

• часто оказываются дешевле, чем ETL.

Теперь пошагово разберем ELT-процедуры:

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

2. Загружаем исходные сырые данные в хранилище.

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

Из-за этих особенностей использование ELT выгодно:

• стартапам;

• малому бизнесу;

• компаниям, которым важно хранить информацию в необработанном виде или изменять ее значительно позже, чем произошла ее загрузка.

Рассмотрим ELT на практике. В качестве примера возьмем компанию-разработчика игр для смартфонов и планшетов.

На этапе создания в игру встраивается SDK (Software Development Kit) для аналитики (например, Firebase). В Firebase есть интересная опция: запись данных, действий пользователя и прочего во внешнее хранилище Google BigQuery (поскольку Firebase с некоторых пор – одна из компаний, принадлежащих Google). В этот момент мы проходим две составляющие ELT-процесса:

• На первом этапе все данные извлекаются из игры в хранилище.

• На втором происходит трансформация: данные переводятся в вид, пригодный для анализа.

Всю эту работу можно проделать в BigQuery, используя язык запросов SQL.

Для разработчика ELT это удобные инструменты, позволяющие легко и быстро справиться с задачами.

Главная разница между ELT и ETL заключается в подходах к обработке информации. Для наглядности сравним эти процессы в таблице (рис. 21).

Рис. 21. Сравнение параметров ETL и ELT

Как мы видим, понять разницу между ETL и ELT не составляет труда. Но чтобы видеть общую картину процессов организации и хранения данных, нужно знать, с помощью каких инструментов они работают.

Процессы ELT не ограничиваются сбором отдельных данных, зачастую включаются их непрерывные потоки (так называемый стриминг). И для этого требуются специальные программные инструменты.

Среди таких инструментов класса Extract/Load выделяют две большие группы: для стриминга данных и для порционной загрузки.

К актуальным инструментам для стриминга данных в 2024 году относят:

• Jitsu. Это программа с открытым исходным кодом для потоковой загрузки данных.

• Snowplow. Еще один представитель open-source software для сбора данных.

• PostHog. Одна из самых известных open-source платформ для стриминга данных из нескольких источников.

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

К инструментам для порционной (батчевой) загрузки данных в 2024 году относят:

• Fivetran. Это коммерческий софт для порционной загрузки данных из большого количества источников с удобным графическим интерфейсом. Инструмент нативно соединяется плагинами с dbt, который используется для трансформации данных.

• Stich. Платформа для загрузки данных из разных источников в облачные хранилища.

• Airbyte. Представитель программ с исходным открытым кодом для данных из сторонних источников.

Продукт может сохранять «сырые» данные, а также работать со сторонними инструментами через ряд коннекторов.

Рассмотрим пример, как эти инструменты используют на практике.

Для компании Buff мы в LEFT JOIN построили архитектуру и стек для работы с данными. Главный запрос: компании важно изучать данные о расходах из кабинетов рекламных платформ, чтобы понимать финансовую эффективность рекламных кампаний.

Что мы сделали:

• Для сбора данных из рекламных кабинетов Bing и Facebook* настроили инструмент Airbyte. В дальнейшем он использовался для подготовки данных к анализу.

• Развернули Airflow. Теперь данные своевременно обновлялись и полноценно трансформировались.

• Для визуализации и анализа данных развернули и настроили Redash.

Таким образом, компания Buff получила систему сбора и анализа информации о своих рекламных кампаниях в режиме реального времени. Руководство освободилось от груза дополнительных задач, перенаправив свое внимание на решение управленческих вопросов.

Подобные решения для бизнеса не «волшебство», а технология со множеством возможностей. А ключевое требование одно – оптимальный выбор инструментов для решения задач вашей компании. Часто желаемого результата можно достигнуть с минимальными, но вполне оправданными усилиями инженера данных.

Так, я с командой настраивал работу с данными для компании Simple. Руководитель хотел понимать, насколько эффективна реклама, оптимальна ли стоимость и какой источник привлечения клиентов дает лучший результат (реклама в поиске, таргетинг в соцсетях и так далее).

Что мы сделали:

• Для сбора информации написали скрипты, направляющие данные в Apache Kafka. Этот инструмент выполняет роль буфера для хранения потока данных.

• Оттуда данные направляются в хранилище ClickHouse. У него, в свою очередь, есть специальная возможность – материализованные представления, то есть механизм внутри базы данных, позволяющий настроить их трансформацию по написанному вручную SQL-коду.

Таким образом, компания получила основу для управленческих решений в режиме 24/7 без особых затрат.

Глава 12

Трансформация и оркестрация данных

Как мы уже говорили, подходы к обработке информации постоянно совершенствуются. В последнее время процедуры извлечения и загрузки отделяют от первичной трансформации. Одним из самых удобных способов, обеспечивающих этот процесс, выступает инструмент для трансформации данных dbt (data build tool). Это наш кухонный комбайн, сочетающий в себе одном многие процессы и позволяющий нам готовить пасту с креветками быстрее и проще. Остановимся на dbt подробнее.

Трансформация данных и dbt

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

На практике специалисты и команды DataOps, работающие с данными, часто сталкиваются с беспорядочными наборами информации. В таком способе хранения есть свои преимущества, однако такие данные сложно анализировать и визуализировать.

Кроме того, в бесструктурных наборах данных могут присутствовать:

• несколько элементов в одном и том же поле,

• неполные данные,

• записи в разных форматах,

• текстовые значения в столбцах с цифрами,

• другие ошибки.

Рис. 22. Данные без трансформации напоминают гору неразобранных бумаг – работать с ними так же сложно

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

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

Как правило, именно с такими агрегатами и работают аналитики. На основе витрин они пишут запросы, необходимые для составления отчетов.

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

Рис. 23. Стандартизация – это приведение данных из разных источников к единому согласованному формату

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

• «Умная очистка» или Smart CleanUp в «Google Таблицах». Она дает возможность увидеть ошибки в данных. Но исправлять нужно вручную.

• Tabula. Это кроссплатформенная утилита, она служит для извлечения данных из PDF-файлов и хранения их в формате CSV.

• OpenRefine. Помогает исправлять опечатки и ошибки форматирования и стандартизировать данные.

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

• основная – работает с интерфейсом командной строки (open source software),

• версия с графическим интерфейсом (GUI).

Что позволяет сделать dbt:

• структурировать запросы для трансформации данных и управлять ими,

• в версии с графическим интерфейсом создавать онлайн-документацию для фрагментов кода,

• преобразовывать код в определенном формате в правильный SQL-запрос к хранилищу данных и правильно его исполнять.

Это и есть главная задача dbt.

Рис. 24. Пример dbt-модели

Теперь немного поговорим о технологии работы инструмента. Dbt – еще своего рода надстройка над SQL-файлами. Он поддерживает синтаксисы SQL и YAML. В переводе с английского YAML означает «еще один язык разметки». То есть на практике это способ обращения к хранилищам данных, предназначенный для организации больших потоков информации и ее хранения в понятном человеку виде. Функционально YAML – конкурент XML и отличается от него минимализмом и удобством применения.

Рис. 25. Пример файла с шаблоном YAML-разметки

На рисунках 24–26 вы можете видеть, как прописываются запросы и порядок выполнения действий над данными. Dbt при первом запуске автоматически создает файл с шаблоном YAML-разметки.

Давайте внимательнее рассмотрим особенности dbt.

Разработала и запустила dbt в коммерческую эксплуатацию команда Fishtown Analytics. Их специалисты решали примерно такие же задачи, как и моя компания LEFT JOIN на аутсорсе:

• создавали хранилища и потоки данных,

• выстраивали их аналитику в организациях.

Fishtown Analytics довольно быстро столкнулась с необходимостью повторения однотипных действий, а потому решила создать инструмент для работы с данными, способный упростить жизнь инженерам и аналитикам.

Рис. 26. Пример работы с dbt через bash

Специалисты компании придумали новый подход трансформации данных внутри хранилища. Теперь основные его сущности и операции описываются в отдельных YAML-файлах, хотя сама концепция довольно непривычна для инженера данных, привыкшего работать с SQL-запросами. Для того чтобы как следует погрузиться в идею dbt, я советую любому специалисту по инжинирингу пройти бесплатный вводный курс (dbt-101) и изучить все настройки.

Одна из самых крутых опций dbt – макросы на языке Jinja (Python-библиотека), позволяющие легче писать однотипный код. В dbt также доступны расширения (packages), которые можно писать самостоятельно или пользоваться готовыми от сторонних производителей.

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

В свою очередь, расширения позволяют:

• корректно подключаться к хранилищам;

• разместить повторно (часто) используемые фрагменты кода один раз (принцип DRY);

• создавать максимально точные запросы.

Рассмотрим подробнее упомянутый выше принцип DRY. В переводе с английского аббревиатура DRY означает «не повторяйся» (don’t repeat yourself). Сам принцип пришел из программирования и сводится к исключению повторов кода. Если какой-то элемент используется чаще одного раза, он выносится в отдельный файл-библиотеку или расширение. DRY позволяет освободить ресурсы для разных вариантов обработки данных.

Одни из важных функций dbt – контроль версий и откат изменений. Эти понятия пришли в работу с данными также из программирования.

Под версией разработчики понимают блок кода, написанный в определенный момент времени.

Команда разработчиков программного обеспечения:

• создает прототип (или альфа-версию) продукта;

• изучает его работу;

• исправляет основные ошибки;

• создает черновик или бета-версию, очередной коммит (способ сохранения изменений в коде);

• тестирует его, исправляет ошибки и предоставляет готовый продукт.

Отличным инструментом внутри dbt выступает Git – распределенная система управления версиями при разработке программного обеспечения. В работе с данными она используется для схожих задач:

• каталогизирует агрегаты данных;

• ускоряет резервное копирование;

• облегчает обращение к разным наборам данных и легко восстанавливается в случае сбоя.

Dbt позволяет подключить Git и работать с данными примерно таким же образом.

Суть подхода в том, чтобы «отложить в сторону» код на SQL, создавая определенные витрины. Затем другой разработчик может подхватить наработанное и продолжить трудиться над задачей в другой «ветке», а после объединить код и присоединиться к «основной ветке», реализовав задуманное командой.

Безусловно, не только управление версиями кода – полезная возможность dbt. Инструмент также помогает в работе над определением структур данных. Например, можно запланировать регулярное удаление и создать материализованное представление, которое будет пополняться нужными данными за прошедший период.

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

• Dbt поддерживает инкрементные модели тестирования, а не пересоздает таблицы данных. Кроме того, он может тестировать и источники информации, и уже готовые витрины.

• Dbt также позволяет создавать пользовательские тесты или применять готовые, которые можно брать из репозитория на сайте hub.getdbt.com.

Немного запутанно, правда? Смотрите, как все это работает на практике.

Наша команда настраивала аналитическую отчетность для владельцев американского мобильного приложения по уходу за собой. Основатели компании пользовались платежными агрегаторами Stripe и Braintree. Маркетологи поставили перед нами следующую задачу: им было необходимо считать действия каждого пользователя в приложении.

Чтобы это сделать, потребовалось объединить данные из платежных агрегаторов. А информацию они отдают по-разному:

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

• один передает таблицу из 15 полей, другой – из 12,

• в таблицах отличаются идентификатор пользователя и другая информация.

Нам нужна была одна таблица с колонками в едином формате и объединенными данными. Именно так должна выглядеть отчетность. Что мы сделали?

Внедрили клиентам dbt, построив процессы обработки данных с использованием SQL.

Прописали алгоритм взаимосвязи и правила объединения данных.

Создали промежуточную витрину, содержащую агрегированную информацию.

В конце объединили внутренние и финансовые данные компании. Теперь появилась возможность писать запросы к этому агрегату и строить отчеты. Задача была решена.

Но давайте пойдем дальше. Это же приложение из приведенного выше примера накапливает данные непрерывно. С нашей помощью его владельцы получают актуальные отчеты.

А как быть, если данных поступает больше?

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

Оркестрация данных

Мы подошли к самому интересному. Оркестрация данных – это процесс координации и управления одновременно несколькими потоками информации.

Зачем она нужна? В современном мире структура данных со временем становится все сложнее. Постоянный рост количества систем хранения и управления информацией добавляет трудностей. И нужно уметь не только поверхностно разбираться в этих вопросах, но и настраивать различные программные инструменты, исходя из своих потребностей.

Давайте подумаем, какие требования можно предъявить в вашей компании к входящим данным?

• Данные не должны дублировать друг друга, чтобы не занимать лишнее место в хранилищах.

• Они должны быть исчерпывающими.

• Их должно быть легко найти, извлечь и использовать по назначению.

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

Теперь обратимся к теории. Когда вы планируете трансформацию данных и работу с ними, то часто вынуждены использовать графы, где отдельные операции и взаимосвязи представлены определенным образом. В чем их особенность?

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

Чаще всего используется прямой ациклический граф – DAG (Directed Acyclic Graph). Это модель, структурирующая информацию в некий порядок выполнения операций: извлечь А и В, объединить в С, убрать ошибки.

DAG – это практически готовая инструкция по исполнению скриптов (может планироваться по расписанию) под управлением того же Airflow.

Как это выглядит на практике?

Обычно в компании множество Python-скриптов, каждый управляет отдельной процедурой. Для того чтобы наладить исполнение одного и того же скрипта, они планируются через cron – внутреннюю библиотеку операционной системы. В базовой версии это рабочий вариант, позволяющий тестировать подходы по сбору данных.

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

Но эту же задачу можно решить проще: подключить специально предназначенные для оркестрации инструменты: например, Airflow или Dagster. В них есть возможность спланировать Python-скрипты, находящиеся внутри DAG’ов. Это позволяет контролировать успешность выполнения операций и распределять их во времени.

Таким образом, мы упрощаем управление запусков скриптов и видим его подробные результаты.

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

Или же выявим причины, почему создать витрину не удалось.

Например, у компании из Эстонии, занимающейся беттингом (ставками на спорт) данные преобразуются и складываются в ClickHouse. А все основные процедуры автоматизированы и переданы под управление Airflow.

Рис. 27. Пример DAG из Airflow

Да, зачастую объем необходимых к выполнению скриптов может быть настолько громоздким.

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

Часть 4

Как аналитики работают с данными и создают отчеты

Глава 13

Чем занимается аналитик данных?

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

Что же именно он делает?

Строит графики и составляет отчеты, благодаря которым вы легко можете делать выводы об эффективности вашего бизнеса.

• Представьте аналитический отчет в виде таблицы с метриками. Его часто показывают руководителю в виде Excel-таблицы. Однако в таком виде он без помощи аналитика сложен в изучении. Из набора строк с данными практически невозможно сделать полезные выводы.

• Чтобы сделать отчет понятнее, аналитик добавляет визуализацию данных: строит графики, иллюстрирующие, допустим, динамику продаж по месяцам. Такая диаграмма наглядно показывает, что в декабре покупатели создают аномальный спрос: все закупаются едой и подарками к Новому году. С помощью визуализации также легче проследить изменения спроса на другие товары в разные месяцы: традиционно в ретейле выделяют гендерные праздники (23 февраля и 8 марта) и «шашлычный» сезон в мае. Вы не сможете отследить такие закономерности по обычным таблицам – сезонность видна только на графике. Рассмотрим пример ниже (рис. 28).

Рис. 28. Диаграмма на примере гипермаркета «Лента»

• Проводит А/Б-тесты экспериментов по изменению продукта и анализирует их успешность. К примеру, разным сегментам целевой аудитории во время рекламы предлагается разная информация о товаре, услуге или акции. Затем данные собирают и изучают, делая вывод о том, какой рекламный продукт работает максимально эффективно.

• Автоматизирует подготовку описательной статистики. Предположим, у сетевого ретейлера в разных частях страны находятся супермаркеты и гипермаркеты и их показатели необходимо регулярно сравнивать между собой. Как это сделать? Результативность разных магазинов можно показать через подсчет агрегированных метрик, – той же суммы продаж за конкретный период. И после этого строить рейтинг «успешности» магазинов сети.

А можно построить специальный вид визуализации «ящик с усами» (в оригинале – Box & Whiskers Plot) и продемонстрировать распределение продаж, таким образом выяснив, есть ли у какого-то из магазинов исключительные показатели и особенности (рис. 29).

Рис. 29. «Ящик с усами»

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

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

✓ Насколько изменилась выручка за сегодняшний день по сравнению со вчерашним?

✓ В каких регионах прибыль за эту неделю больше, чем за прошлую?

✓ Сколько лидов сегодня получено, по каким каналам рекламы, сколько денег на привлечение потрачено?

✓ Какой срок окупаемости вложений на привлечение одного лида?

✓ Какое событие вызвало проблему или может привести к ней в перспективе?

• Строит отчеты по запросу (ad-hoc аналитика). Аналитик отслеживает любые изменения в работе предприятия. Ad-hoc анализ позволяет в моменте ответить на важные для бизнеса вопросы: что случилось вчера, из-за чего продажи просели на 30 %? Или что могло повлиять на конверсию на сайте и привести к резкому всплеску продаж?

• На основании данных помогает топ-менеджерам сформулировать рекомендации для развития бизнеса. Тут дополнительные комментарии излишни. Без аналитика данных вы просто не сможете развивать свое дело быстро и эффективно.

Глава 14

Типы аналитиков и задачи, стоящие перед ними

Аналитик в компании – не «одинокий рейнджер». Он может работать только в команде, поскольку должен понимать конкретные проблемы бизнеса и поставленные перед ним задачи.

В современной бизнес-модели его работа напрямую связана с циклом Деминга (Plan-Do-Check-Act, или PDCA). Это одна из методик, которая используется в управлении проектами (рис. 30). Она входит в группу способов планирования, базирующихся на так называемом бережливом мышлении (от англ. Lean thinking).

Рис. 30. Цикл Деминга

Чем может помочь аналитик на разных этапах цикла Деминга:

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

Исходя из этого, аналитик может сказать: «Мы планируем продать следующий объем товаров за 3 месяца. Для этого нам ориентировочно потребуется такой-то бюджет на привлечение клиентов».

Дальше в дело вступают маркетологи: они запускают рекламные кампании, получают результат, затем сравнивают его с планом и делают выводы.

• На этапе действий аналитик может оперативно делать сводки по результатам, сравнивая план и факт, процент достижения установленных показателей, перевыполнена норма или же, наоборот, оборудование или персонал не справляются с нагрузкой. Аналитик умеет подсказать «опережающие» метрики, заранее позволяющие прогнозировать текущую тенденцию.

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

• На этапе корректировки он помогает заново рассчитать планируемые показатели и подсказывает коэффициенты их изменения.

Кроме того, в разных направлениях бизнеса, в зависимости от целей и процессов, могут понадобиться разные аналитики. Так, например, в компаниях работают:

• продуктовые аналитики;

• маркетинговые аналитики;

• клиентские аналитики;

• финансовые аналитики;

• операционные аналитики;

• аналитики продаж;

• HR-аналитики;

• многие другие.

Рассмотрим задачи каждого из них и пользу, которую они приносят компаниям.

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

Продуктовый аналитик

Его основная задача – понять, что происходит с продуктом, какие его свойства удерживают клиентов, а какие отталкивают. Эти специалисты – «глаза и уши» бизнеса.

Продуктовый аналитик исследует метрики цифровых продуктов, таких как:

• онлайн-школа,

• мобильная игра,

• финансовое приложение.

Этот специалист ищет ответы на вопросы:

• Как клиенты используют продукт?

• Как можно его улучшить и получить больше продаж и довольных клиентов?

Работа продуктового аналитика помогает интерпретировать результаты А/Б-тестов, объяснить изменения метрик по когортам клиентов, оценить пожизненную ценность клиента (Lifetime Value или LTV), рассчитать стоимость привлечения клиентов и уровень удержания клиентов (retention).

В результате это направление аналитики ищет точки роста продукта и зоны для его развития.

Давайте разберем на примере из игр Match-3.

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

• Почему пользователи уходят на определенном уровне?

• Какие уровни игры сложнее, а какие проще?

• Какая конверсия из пробной версии игры в платную?

• На какие группы делятся пользователи, сколько денег приносят и как их удержать?

При этом постоянно выпускаются новые версии приложения на Android и IOS. Продуктовый аналитик работает в связке с левел-дизайнерами. В результате совместной работы команда:

• устраняет сложности в геймплее и ошибки в приложении;

• повышает визуальную привлекательность игры;

• обеспечивает прирост постоянных пользователей;

• увеличивает доход с одного игрока.

Итог: растут показатели игры, а вместе с ними и прибыль компании-разработчика.

Маркетинговый аналитик

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

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

Давайте рассмотрим таблицу (рис. 31), где сравним между собой функционал маркетолога и маркетингового аналитика.

Рис. 31. Сравнение функционала маркетолога и маркетингового аналитика

Важно: рассчитывая эффективность маркетинговой кампании, аналитик должен учитывать ее цели.

Допустим, при наборе базы клиентов можно поставить две задачи, реализующие ее цели:

1. Быстро создать базу потенциальных пользователей без конвертации их в покупателей.

2. Получить реальных клиентов, которые придут и купят продукт.

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

Если нужен быстрый рост пользовательской базы, то 90 копеек с вложенного рубля может быть приемлемой маркетинговой эффективностью. Далее компания будет работать с этими потенциальными клиентами и в перспективе получит от них прибыль, закладывая определенный уровень LTV-клиента. Если же нужно получить реальных потребителей, чтобы они платили здесь и сейчас, то рекламная кампания, результатом которой стали 90 копеек с вложенного рубля, неэффективна, а деньги потрачены впустую.

Подводя итог, ответим на вопрос, чем же так полезен маркетинговый аналитик для бизнеса:

• он анализирует рентабельность рекламы в целом и по отдельным маркетинговым акциям;

• рассчитывает эффективность разных каналов привлечения трафика;

• оценивает успешность отдельных маркетинговых акций;

• следит за метриками привлечения и удержания клиентов;

• следит за общими метриками продаж, числом клиентов, средним чеком.

Как именно это происходит? Перейдем к примеру из моей практики.

Руководство компании «Лента» принимает решение посчитать прибыльность маркетинговых кампаний. И ставит перед отделом маркетинга множество разных задач:

• посчитать эффективность отдельно взятой акции;

• определить, насколько реклама повлияла на продажи;

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

Что сделали маркетинговые аналитики?

Они проанализировали полученные данные, чтобы ответить на следующие вопросы:

• Насколько снижение цены на товар обеспечило приток клиентов и увеличение общей покупательской корзины?

• Повлияла ли акция на продажи сопутствующих товаров или других товаров той же категории?

• Что повлияло на динамику продаж разных групп товаров?

• Сколько всего клиентов компании? Становятся ли новые клиенты постоянными?

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

Что еще важно знать о работе маркетингового аналитика? К примеру, в онлайн-сегменте практически все маркетинговые активности можно оцифровать. В digital-рекламе есть конкретные метрики, которые помогают оценить эффективность платной рекламной кампании, такие как:

• объем охвата рекламной кампании;

• количество показов – сколько раз конкретный баннер показали на странице;

• количество кликов – сколько людей заинтересовалось и перешло по ссылке на баннере;

• CTR – показатель кликабельности (отношение числа кликов к числу показов, выраженное в процентах);

• конверсия – сколько из заинтересовавшихся людей стали клиентами;

• стоимость привлечения и доля рекламных расходов в доходах (ДРР) – сколько на вложенный рубль получаем прибыли.

Digital-маркетологи следят за ключевыми показателями эффективности (КПЭ или KPI, кому как привычнее) с помощью подробного отчета, который получают на регулярной основе. Так они могут оптимизировать маркетинговый микс – «солянку» разнообразных digital-инструментов для продвижения.

Безусловно, в digital-маркетинге много тонкостей. Например, однозначно определить, к какому из каналов относится тот или иной доход, поможет только маркетинговая атрибуция. А по этой теме можно написать отдельную книгу. Поэтому, если вас заинтересовал digital-маркетинг, рекомендую погрузиться в эту тему отдельно.

Клиентский аналитик

Важное уточнение: в небольших компаниях задачи этого специалиста выполняет маркетинговый аналитик.

Какие задачи выполняют клиентские аналитики:

проводят сегментацию покупателей и на ее основе разрабатывают индивидуальные стратегии для работы с каждым сегментом;

• изучают частоту и давность покупок клиентов – это называется RFM-сегментация, она популярна в ретейле. Такой подход позволяет найти самых «доходных» клиентов – тех, кто покупает вашу продукцию часто и много, – и локализовать давно не покупающих;

• разрабатывают систему метрик, отслеживая успешность взаимодействия с клиентами, а также проводят мониторинг состояния клиента («новый», «вернувшийся», «заснувший», «проснувшийся»);

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

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

Как это выглядит на практике?

В «Юлмарте» я руководил департаментом клиентского маркетинга, одним из подразделений которого был отдел клиентской аналитики. Специалисты регулярно мониторили состояние клиентов. Для этого они составляли и изучали матрицу миграций, показывающую, как «спящий» клиент становится активным.

Рассмотрим пример подобной матрицы, составленной аналитиком отдела, на схеме (рис. 32).

Рис. 32. Матрица типов клиентов

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

В итоге удалось повысить лояльность клиентов, и процент их удержания вырос на 15 %.

Еще один пример:

Рис. 33. Инфографика типов клиентов

В той же компании «Юлмарт» отдел клиентской аналитики обратил внимание руководства на один момент: доходы за отчетный год выросли в основном за счет постоянных и «проснувшихся» клиентов. Это значит, что:

• предложение компании интересно пользователям;

• усилия маркетологов сосредоточены на существующих клиентах;

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

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

Кроме того, аналитики выявили регионы с самым высоким оттоком клиентов (рис. 34).

Рис. 34. Инфографика оттока по регионам

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

Финансовый аналитик

Задачи финансового аналитика:

• строить управленческую отчетность: следить, сколько денег у организации на текущий момент;

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

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

Логично, что эти специалисты заняты в основном вопросами оборота денежных средств в компании. Они на «ты» с формированием управленческой отчетности, балансом компании, отчетами о прибыли и убытках и так далее.

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

Привычная уже нам компания «Юлмарт». Организация готовится к IPO – размещению на публичной бирже. А перед этим руководству необходимо понять:

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

• Как распределить бюджет между подразделениями, чтобы обеспечить стремительный рост компании?

• Из чего состоят бизнес-юниты предприятия – ее «боевые подразделения»?

Для поиска ответов на эти вопросы руководство «Юлмарт» пригласило на работу финансового директора, а он, в свою очередь, сформировал команду финансовых аналитиков. Я как раз выступал консультантом в ней. Что было сделано в итоге:

• команда описала финансовую структуру организации;

• оценила необходимый для IPO план доходов и расходов;

• спланировала необходимую общую сумму займа;

• обосновала сумму кредита и порядок его возврата;

• подготовила управленческую отчетность организации; изучила, куда уходят деньги, насколько эффективно они используются и какой приносят доход;

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

Это лишь малая часть того, над чем трудилась команда финансовых аналитиков под руководством финдиректора. Таким образом, мы создали базу для подготовки огромного количества документации, необходимой для участия в IPO.

Операционный аналитик

Этот специалист изучает факты операций и сведения о бизнес-процессах компании. Перечислим основные задачи операционного аналитика:

• строит план продаж на ближайший месяц или квартал;

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

• держит руку на пульсе важных метрик бизнеса: например, товарных остатков или товарооборота отдельных позиций, чтобы не допустить «вымывания» остатков.

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

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

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

Аналитик продаж

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

Аналитик продаж ищет ответы на следующие вопросы:

• Как меняется объем продаж в динамике?

• Сколько продаж осуществляет конкретный продавец?

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

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

Рис. 35. Типы аналитиков

Независимо от направления деятельности, все аналитики в работе опираются на данные и метрики. А для повышения точности используют так называемые фреймворки.

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

Глава 15

Строим систему метрик

Рис. 36. Агрегированные и «сырые» данные

Как мы говорили выше, аналитик данных работает только с накопленной информацией о существующих продуктах. Для решения задач он обращается к агрегированным или «сырым» данным (рис. 36). У этих подходов свои особенности. Рассмотрим их подробнее.

Прежде чем погружаться в детали работы, давайте определимся с основными терминами – «метрики» и «фреймворки». Без их понимания разобраться с процессом не получится.

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

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

Пример от Романа Бунина, автора Telegram-канала «Reveal the data» про визуализацию данных (рис. 37):

Рис. 37. Пример фреймворка

В итоге работа по этому фреймворку приведет к подобному результату (рис. 38):

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

Зачем метрики и фреймворки нужны аналитику?

Начнем с первых. Работу с ними следует строить с определения ключевых показателей бизнеса и связей между ними. Замечу: создать систему правильных метрик, планировать их, замерять и реагировать на изменения показателей важно, поскольку это позволяет держать руку на пульсе.

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

А также, помимо прочего, система метрик помогает строить аналитическую работу компании. То есть:

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

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

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

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

Но как же выстроить собственную систему метрик и решить с помощью нее все эти задачи? И как использовать ее грамотно?

Все начинается с ответа на вопрос: «Зачем нужна аналитика?» Не в общих чертах, а конкретно в вашем бизнесе, в вашем отделе.

Мой ответ – аналитика нужна для понимания процессов, происходящих в бизнесе, в том числе отслеживания:

Работает ли команда на результат и исследует ли причины неудач?

Справляются ли сотрудники с поставленными задачами?

Рассмотрим пример.

Возьмем любое мобильное приложение гипотетического банка и метрику «количество пользователей»:

• 20 000 клиентов мобильного приложения банка – это хорошо или плохо? В масштабах страны за год это, мягко говоря, провал. А в регионе с населением 100 000 человек за полугодие?

• Что означает цифра дохода с пользователя? Как она изменилась за последние недели, пару месяцев? Как при этом изменились затраты на одного клиента (напомню: они состоят из стоимости привлечения, удержания, обслуживания)?

• О чем говорит динамика оборота? Что при этом происходит с затратами на привлечение пользователей?

• Как и почему пользователи становятся клиентами? Почему часть пользователей не конвертируется в клиентов и как на это повлиять?

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

• Компетентность

Собрать и проанализировать полученные данные, а затем построить комплекс метрик – задача для профессионала. Для интерпретации информации иногда требуются специальные знания, к примеру математическая статистика. Аналитик разбирается в предметной области, понимает и умеет объяснять результаты, а потому сделанные им выводы можно применить во многих отраслях бизнеса.

• Объективность

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

• Актуальность

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

• Интерпретируемость

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

Метод AARRR[5]

Систему метрик можно выстроить на основе множества критериев и теорий. И она индивидуальна: оптимальное решение для одного бизнеса совершенно бесполезно для другого. Кроме того, эта система – математическое отражение декомпозиции бизнес-процессов компании. Причем система метрик будет иметь внутри себя несколько уровней. На одном уровне иерархии метрик может быть видна прибыль, на другом – действия пользователей и клиентов, на третьем – активность компании.

Документ с подробным описанием такой системы помогает структурировать всю работу организации. Рассмотрим один из основных подходов к построению структуры метрик – жизненный цикл клиента, или ЖЦК (Customer Lifecycle – CLC). А после разберем второй подход – через понимание юнит-экономики.

Обычно жизненный цикл клиента включает:

1. Охват аудитории. С него начинается работа маркетолога. Потенциальную аудиторию еще предстоит преобразовать в пользователей, а затем – в клиентов. Именно этим занимаются маркетологи.

2. Вовлечение. На этом этапе новых пользователей конвертируют в зарегистрированных. У них формируют доверие к организации и ее продуктам. В компании над этим работает несколько команд.

3. Монетизация. Это процесс конвертации зарегистрированных пользователей в клиентов, которые принесут компании доход, покупая ее продукцию. Этим занимается отдел маркетинга.

4. Удержание/Отток. К этому моменту клиент уже решил как минимум часть своих вопросов и может уйти. Компании нужно его удержать, а потому запускаются различные маркетинговые акции. Это командная работа: отдел маркетинга, коммерческий директор и маркетинговый аналитик должны сработать вместе на результат.

Дейв МакКлюр в 2007 году предложил метод отстройки системы метрик, основанный как раз на движении клиента в компании и его жизненном цикле – AARRR. Это система показателей, изначальная цель которой заключалась в помощи стартапам. Этот метод также можно встретить и под другим названием – «пиратские метрики» – из-за звука АА-Р-Р-Р.

AARRR включает 5 основных этапов (рис. 39). Это совокупная работа маркетологов и аналитиков. Графически все этапы можно представить в форме воронки, изображенной на рисунке:

• Аcquisition – привлечение: на начальном этапе идет поиск целевой аудитории.

• Аctivation – активация: здесь нужно добиться регистрации потенциального покупателя и трансформировать его в клиента.

• Retention – удержание: после покупки клиент должен вернуться еще несколько раз.

• Revenue – доход/монетизация: клиент покупает столько продукции, сколько вы запланировали продать.

• Referral – рекомендации: если продукт удовлетворяет нужды клиента, он рекомендует его знакомым и друзьям.

Рис. 39. Метод AARRR

На разных уровнях этой воронки нужно выбирать отдельные метрики. Их задача не только отражать происходящее, но и описывать движение от одного этапа к другому.

Причем нужно выразить все это в цифрах и детально изучить.

Теперь разберем каждый этап и его метрики отдельно на примерах из успешно работающих организаций.

A – Привлечение клиентов

Нагляднее всего будет продемонстрировать поиск целевой аудитории на примере мобильного приложения доставки готовой еды и каналов привлечения трафика для него. Пользователи приходят по нескольким каналам:

1. Органический поисковый трафик: через «Яндекс», Google и так далее.

2. Мобильный органический трафик: поиск в Google Play / Apple Store.

3. Коммерческий трафик: реклама во «ВКонтакте», контекстная реклама («Яндекс Директ»), рекламные сети для мобильного трафика.

Рис. 40. Привлечение клиентов

Рассмотрим продвижение во «ВКонтакте». Объявления настроены на потенциальную целевую аудиторию, в терминах социальной сети она называется «Охват». Есть возможность уточнить показы объявления по конверсии, кликам и другим параметрам.

Основная задача тонкой настройки рекламы – собрать максимально заинтересованную аудиторию при минимальном бюджете. Значит, предстоит выбрать метрики, отражающие адекватность выбора. Вот они:

• Impressions – число показов объявления ЦА. Сама по себе метрика мало о чем скажет. Понимание ее значения тесно связано с объемом потенциальной аудитории. Она также потребуется нам для понимания остальных метрик.

• Clicks – число кликов по объявлению.

• Installs – число установок мобильного приложения.

• CTR (Click Through Rate) – кликабельность объявления. Она равна отношению кликов (Clicks) к числу показов (Impressions). Метрика показывает, насколько рекламное объявление интересно аудитории.

• CR (Conversion Rate) – это отношение количества установленных приложений (Installs) к кликам по объявлению (Clicks). Показывает уровень конверсии или долю пользователей, установивших софт, относительно кликнувших по рекламному объявлению.

• Spend – сумма денег, потраченная компанией на отдельное объявление.

• CPC (Cost Per Click) – цена клика. Рассчитывается как отношение затрат (Spend) к числу кликов (Clicks) и показывает стоимость одного клика. Использовать метрику стоит, сравнивая показатель одного объявления с другим.

• CPM (Cost Per Mille) – цена тысячи показов. Метрика считается по формуле Spend / Impressions × 1000. Она тоже используется в сравнении объявлений. Оба показателя помогают определить наиболее эффективный для компании и привлекательный для целевой аудитории способ обращения.

• CPI (Cost Per Install) – удельная цена одной установки приложения клиентом. Рассчитывается как отношение затрат (Spend) к количеству установок (Installs).

• Revenue – конечный доход для компании от объявления или акции.

• ROAS (Return of Advertising Spend) – возврат вложенных в рекламу денег. Считается как доход с инвестированного доллара в рекламу или отношение конечного дохода (Revenue) к затратам на объявление (Spend). Показатель помогает раскрыть финансовую эффективность рекламной кампании. Например, ROAS = 300 % указывает на доход 3 руб., а ROAS равный 30 % говорит о том, что на вложенный доллар заработано 30 копеек.

• CAC (Customer Acquisition Cost) – стоимость привлечения клиента. Рассчитывается как отношение суммы общих расходов на маркетинг и расходов на продажи к количеству новых привлеченных клиентов.

Итак, перед нами набор метрик, которые предстоит обрабатывать: сравнить между собой для разных объявлений, изучить динамику показателей и разные источники трафика. И уже простая таблица с этими показателями приблизит нас к пониманию эффективности рекламы (рис. 41).

Рис. 41. Таблица с наборами метрик

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

Что еще аналитик может сделать на основе этой таблицы?

• Сравнить CTR нескольких баннеров и понять, какое предложение сейчас для целевой аудитории привлекательнее. Показатель можно применять в A/B-тестах баннеров для выбора лучшего.

• При расчете эффективности, кроме CTR, стоит учитывать еще и CPC. Показатель поможет выбрать баннер, оптимальный по цене за клик.

• С точки зрения финансовой эффективности стоит выбрать две метрики: CPI и ROAS. Первая указывает на стоимость закупки пользователей и подсказывает, есть ли необходимость ее оптимизировать. Вторая метрика говорит о том, насколько хорошо купленный трафик монетизируется.

A – Активация клиентов

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

На этом этапе основными можно назвать две метрики:

• конверсия пользователя из гостя в зарегистрированного пользователя – считается как отношение регистраций (Registrations) к установкам игры (Installs);

• конверсия в прошедших вводный этап игры (= Tutorial Users / Installs).

Рис. 42. Активация клиентов

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

R – Удержание клиентов

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

• Retention rate (или Rolling retention) – показывает активность обращения к продукту;

Рис. 43. График Retention rate

• Sticky Factor – мера вовлеченности в пользование продуктом. Чтобы получить данные за конкретный период (день, неделю, месяц), считаем отношение числа уникальных посетителей за сутки (DAU) к числу уникальных посетителей за изучаемый период (WAU: за день, неделю, месяц) и выражаем в процентах.

Рис. 44. Удержание клиентов

Вместе с главными метриками следует изучить показатели, связанные с инструментами удержания клиентской базы. Это могут быть каналы директ-маркетинга: e-mail, sms, push-уведомления. У них есть описательные показатели: количество отправленных и доставленных сообщений, число вернувшихся пользователей. Они помогут понять результативность каждого из инструментов.

Retention – этот этап отражает способность компании выстраивать крепкие отношения с покупателями. Он показывает, насколько хорошо бизнес может удерживать постоянных клиентов. И на этот показатель можно влиять.

Допустим, компания продает услуги через мобильное приложение. Как это происходит:

1. Человек получает уведомление.

2. Заходит в приложение.

3. Выполняет там целевое действие (к которому мы его подталкиваем через push-нотификацию).

После этого график Retention покажет рост. Необходимо учитывать: в первый месяц после установки приложения метрика нестабильна. Это совершенно нормально.

Чем может быть полезен retention в бизнесе?

Некоторые компании ориентированы на удержание клиента и повторные продажи. Их основное конкурентное преимущество – снижение затрат на рекламу при одновременном увеличении выручки. При таком подходе основной запрос покупателя успешно решается. И тогда целевым действием может выступать переход по ссылке, чтение статьи или письма с описанием нового продукта или услуги.

Для таких бизнесов график Retention может выглядеть следующим образом (рис. 45):

Рис. 45. График Retention

А есть бизнесы, которые ориентированы на постоянный поиск новых клиентов. Тот же «Яндекс. Такси». Человек может вызвать машину для поездки на работу или домой, но ездить на такси в режиме 24/7 могут далеко не все. Поэтому компания вынуждена постоянно привлекать новых клиентов. В этом случае динамика Retention может быть не настолько показательной.

А еще Retention меняется в зависимости от того, в какой момент пользователь зарегистрировался в приложении, так как разработчики постоянно вносят коррективы. Что делать в таком случае? Один из вариантов – смотреть Retention по когортам, как это показано на графике (рис. 46).

Теперь остановимся на понятии когортного анализа.

Рис. 46. График Retention по когортам

Когортный анализ в работе аналитика

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

Графически результат когортного анализа обычно представляют в виде таблицы (рис. 47):

Рис. 47. Результат когортного анализа

Суть такого анализа – разделить пользователей на группы (когорты) по определенным признакам и отслеживать их поведение в разрезе времени.

Когорта — это группа пользователей приложения, объединенных по одному или нескольким признакам. Например, время установки приложения или появления клиента в приложении. Их также можно выделять и по другим критериям:

• география пользователя,

• источник трафика,

• платформа устройства и другие важные для бизнеса параметры.

Как работает с когортами аналитик?

• Определяет размер и состав когорт.

• Следит за изменениями их ключевых показателей в течение определенного времени.

• Делает выводы, какие когорты имеют большую или меньшую успешность, дает соответствующие рекомендации.

Когортный анализ полезен бизнесу для решения нескольких задач сразу, поскольку он:

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

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

• Дает возможность определить проблемы и улучшить процессы обслуживания. Допустим, выяснить, что клиенты из предыдущего примера часто уходят из-за проблем с доставкой, и решить эту проблему, сохранив их лояльность.

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

Теперь перейдем к основному показателю жизненного цикла клиентов – деньгам. Доход, выручка, прибыль, как ни назови, все это – деньги, полученные от клиентов. Предпоследняя буква аббревиатуры AARRR – R, монетизация.

R – Монетизация

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

Рис. 48. Монетизация

Обычно действия пользователей раскладывают на несколько относительных показателей:

Средняя выручка на клиента. Считается по формуле: ARPU = Revenue / Users.

• Накопленная средняя выручка в пересчете на одного покупателя. Расчет по формуле: СARPU = cumulative Revenue / Users.

• Средний доход на одного человека. Метод расчета: ARPPU = Revenue / Payers.

• Средний чек. Рассчитывается: Avg Receipt = Revenue / Purchases.

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

Теперь разберемся в значениях этих метрики и поймем, как их можно применять.

Средняя выручка показывает доход с одного клиента за определенный период. Как правило, это неделя или день. Это полезные данные, но для каких-либо выводов их недостаточно. Нам необходимо найти аудиторию, способную платить больше, чем стоит ее привлечение. Таким образом, если мы модифицируем показатель ARPU и рассмотрим накопленный ARPU, например, за 30, 60, 90, 180 дней, то получим неплохое приближение к LTV пользователя. Еще лучше, если мы построим кривую накопленного ARPU по дням (рис. 49).

Рис. 49. Кривая накопленного ARPU по дням

Дополнительную информацию даст добавление горизонтальной линии CPI, и точка ее пересечения с ARPU покажет точку безубыточности. С этого момента доход от пользователя превышает стоимость его привлечения. На графике мы можем видеть 56-й день жизненного цикла клиента.

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

R – Рекомендации

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

Рис. 50. Рекомендации

В этом случае наиболее информативными метриками будут:

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

• NPS (Net Promoter Score) – эта метрика демонстрирует степень лояльности пользователя, который пользуется продуктами или услугами компании длительное время.

Для расчета NPS клиентов просят оценить по шкале от 0 до 10, с какой вероятностью они порекомендуют продукт компании друзьям.

Затем клиентов делят на три группы:

• В первую входят клиенты, оценившие желание пригласить друзей в 9 баллов и выше, – это сторонники бренда.

• Во вторую – люди, поставившие 7–8 баллов (нейтральные пользователи).

• В третью – клиенты, поставившие 6 баллов и ниже. Это критики.

В расчетах используют данные по 1 и 3 группам: NPS определяют как разность процентной доли сторонников и критиков бренда. Если задать дополнительный вопрос «По какой причине вы поставили именно эту оценку?», то объективность анализа повысится.

Я рекомендую регулярно измерять NPS через каналы директ-маркетинга. Динамика этой метрики показывает, насколько продукт нравится потребителям.

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

Например, организация привлекает пользователей за 1000 руб. и стремится удержать эту цену. В отделе маркетинга создали механизм реферальных ссылок. После внедрения каждый клиент в среднем привел еще двух новых. Благодаря этому цена привлечения пользователя уменьшилась: 1000 / 3 = 333 руб. Теперь компании по средствам привлекать неохваченных пользователей за 3000 руб. Ведь формально приемлемое значение CAC сохраняется.

Итак, мы разобрались с тем, как построить систему метрик на основе маркетинговой воронки. А теперь переходим ко второму популярному подходу, который поможет сделать то же самое, но другим способом – через понимание юнит-экономики. Именно она показывает прибыльность бизнеса в разрезе каждого отдельно взятого продукта, пользователя или клиента.

Связь метрик и юнит-экономики

Что такое юнит-экономика? В широком смысле это движение денег внутри организации в пересчете на одну условную единицу, приносящую выручку. Ее и называют юнитом. Как она выглядит и что дает? Для начала познакомимся с терминами.

Юнит-экономика – это анализ финансовых показателей одного «базового» элемента бизнеса: одной продажи, одного клиента, одной транзакции или любого другого ключевого показателя, важного для конкретной компании. Построив и проанализировав юнит-экономику, вы получите ряд преимуществ для своего бизнеса:

• Понимание прибыльности: вы увидите, насколько доходна каждая единица продукта или услуги.

• Объективную и точную оценку рентабельности инвестиций в маркетинг, продажи, разработку продукта и другие сферы деятельности.

• Прогнозирование: вы сможете верно предсказать рост и развитие своего бизнеса, а также оценить влияние различных стратегий и решений на прибыль в долгосрочной перспективе.

• Оптимизацию процессов: разберетесь, какие аспекты бизнеса наиболее эффективны, а какие требуют улучшения; это поможет усовершенствовать процессы и снизить издержки.

• Сравнение с конкурентами: определите свои сильные и слабые стороны на рынке.

• Привлечение инвесторов: положительная юнит-экономика увеличивает шансы на привлечение инвестиций и улучшает условия сделки.

Важное уточнение: если юнитом является клиент, доход и расход считаются не единоразово, а за все время потребления продукта/услуги. Для расчета также используются LTV клиента.

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

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

С юнит-экономикой важно быть предельно внимательным, потому что цена ошибки высока. Расскажу историю о том, как я не совсем корректно рассчитал юнит-экономику и чем это обернулось.

У нас с партнером был интернет-магазин свежеобжаренного кофе. Планируя работу, мы считали затраты по разным вариантам привлечения клиентов, в том числе на закупку рекламы. И допустили ряд ошибок:

• В расчеты закладывали среднюю прибыль от одной продажи.

• За затраты мы взяли стоимость привлечения клиента, но забыли учесть комиссию оператора интернет-платежей, на тот момент она составляла 6 %.

• Не включили в затраты налоги и другие издержки.

Мы не до конца разобрались, как работает юнит-экономика. И спустя время осознали, что продажи идут, а прибыль не растет. В планах были одни цифры, а по факту они оказались значительно меньше.

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

1. Разделили кофе на упаковки разного веса по 100, 250, 500 граммов и 1 килограмм.

2. Сделали скидку в зависимости от веса кофе. Но даже при максимальной скидке покупка приносила прибыль, к чему мы и стремились.

В результате проделанного анализа совокупная прибыль компании возросла с 7 % до 30 %.

Из этого примера невооруженным глазом видно, как важно учитывать прямые и косвенные затраты:

• прямые – это расходы на закупку товара, привлечение пользователя и так далее;

• косвенные – это все, что остается «за кадром»: зарплата бухгалтера и других сотрудников, издержки на оплату аудиторов, фрилансеров и тому подобное.

Еще один пример из моей личной практики.

У меня был бизнес по производству крафтового пива, мы работали в формате В2В. Юнитом считали отдельный заказ одного клиента – бара, ресторана.

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

Разобраться помог отчет о прибылях и убытках. Причиной оказалась дебиторская задолженность: мы поставляли пиво под обещание заплатить и не всегда вовремя учитывали расходы на доставку, а также жизненную ценность (LTV) и цикл клиента (CLC).

Что в итоге?

• Мы увидели: клиенты часто платят с задержкой.

• Затем учли время производства пива – примерно 30–45 дней.

• Вновь пересчитали юнит-экономику.

В итоге наш проект получил второй шанс на жизнь, но пришлось серьезно пересмотреть ценовую политику и целевую аудиторию.

А как все это выразить языком цифр и разложить на метрики? Давайте разбираться.

Юнит в сделке

Здесь важно понять, насколько прибыльно продается юнит. Для этого рассчитываем маржу, то есть маржинальную прибыль (рис. 51).

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

Рис. 51. Пример расчета маржи

Юнит – клиент

В этом случае юнит-экономикой называют отношение полученной с клиента прибыли за весь срок его жизни в компании к цене его привлечения.

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

Рис. 52. Стоимость привлечения клиента и прибыль, которую он принес

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

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

Глава 16

BI-инструменты

BI-инструменты – это программное обеспечение, предназначенное для аналитической обработки данных. С помощью них создают отчеты и строят дашборды.

В прошлой главе мы говорили о ETL-процессах, которые до сих пор используются в некоторых крупных организациях. Раньше BI-инструменты в том числе включали в себя ETL-операции. Их использовали на этапе инжиниринга данных и подготовки сырой информации к виду, пригодному для построения отчетов. Со временем, когда обработка сырых данных стала дешевле, BI и ETL/ELT-инструменты стали считаться отдельными классами инструментов.

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

Такая система помогает компаниям улучшить стратегическое планирование, оптимизировать бизнес-процессы и увеличить эффективность работы, а также приносит конкурентное преимущество на рынке.

Почему результаты важно подавать именно в графическом виде? На это есть две основные причины:

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

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

Рис. 53. Пример дашборда

Вот еще один пример из реального кейса моей компании:

Рис. 54. Дашборд онлайн-школы

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

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

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

Таким образом, в работе аналитика BI-инструменты:

• позволяют использовать несколько источников данных одновременно;

• упрощают подготовку аналитических отчетов;

• сокращают время принятия решений.

Виды BI-инструментов

Широкую группу BI-инструментов можно разделить на:

• решения с открытым исходным кодом;

• коммерческие платформы;

• бесплатные инструменты.

Теперь разберем каждую из них.

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

Коммерческие платформы с полноценным интерфейсом также платные. Однако часто у них есть пробные версии. Они предназначены для обучения персонала базовым наборам операций и работе с интерфейсом.

Бесплатные инструменты, как правило, привязаны к крупным компаниям и работают на их серверах. К примеру, Yandex DataLens – инструмент, который легко интегрируется в инфраструктуру, построенную на «Яндекс. Облаке» (Yandex Cloud).

Нельзя однозначно сказать, какие из этих решений лучше, а какие – хуже. У каждой их группы есть свои плюсы и минусы. Помимо цены, выбор оптимального для организации BI-инструмента зависит от:

• особенностей ее инфраструктуры,

• наличия уже развернутых платформ и внедренных инструментов.

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

С другой стороны, ориентированному на e-commerce стартапу удобнее использовать Yandex DataLens. Сочетая между собой инструменты «Яндекс. Облака», можно выстроить своеобразную экосистему обработки данных. Причем сделать это можно в облаке и недорого, что важно для компаний с небольшим бюджетом.

Приведу пример из своего опыта.

Мы с командой моего дата-агентства LEFT JOIN помогали шведскому стартапу Vembla (даркстор продуктов питания) построить аналитическую инфраструктуру. У них уже была мобильная витрина с подключенной к ней системой платежей. Но в Vembla применялись устаревшие подходы к использованию данных:

• часть их хранилась в файлах холодного хранилища типа S3,

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

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

Для построения графиков (рис. 55 и 56) мы использовали инструмент Metabase. Такая визуализация позволяет топ-менеджерам понять эффективность маркетинга, оценить уровень удержания клиентов и настроить автоматическое и регулярное получение этой информации.

Как мы видим, в этом примере BI-инструмент стал завершающим звеном уже упомянутого процесса инжиниринга данных.

Рис. 55. Столбчатая диаграмма с метрикой CAC (Customer Acquisition Cost)

Рис. 56. Линейный график с динамикой показателя LTV (Lifetime value)

BI-платформы привлекательны своими особенностями. Это:

• простота работы с данными;

• быстрый доступ к данным;

• распределенный доступ к информации.

В целом BI-инструменты созданы для облегчения работы с информацией, что очень важно для руководителей.

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

BI-инструменты или табличные редакторы?

Вы можете спросить: выгодно ли внедрять BI-инструменты или достаточно работать по старинке, обмениваясь Excel-файлами или ссылками на Google Spreadsheets с другими сотрудниками? Даже если вы хотите сэкономить и думаете, что BI-инструменты вам не пригодятся, то это не так. Они действительно помогут бизнесу:

• сократить количество ошибок в данных, из-за которых менеджеры принимают неверные решения и вы теряете деньги,

• найти точки роста,

• освободить ресурсы от подготовки ежедневной или еженедельной отчетности вручную.

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

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

Возьмем для примера онлайн-школу. На старте, пока продажи курсов небольшие, компания обходится Google-таблицами, так как в штате всего один продакт-менеджер, отвечающий за развитие бизнеса.

Но онлайн-школа активно развивается и привлекает инвестиции. Идет интенсивный найм персонала, подключаются новые системы привлечения лидов, CRM-системы, происходит автоматизация процессов обучения.

И каждая новая информационная система генерирует все новые и новые данные. Именно на этом этапе становится ясно, что ручной обработки недостаточно, нужно автоматизировать работу с данными. Иначе развитие вашего бизнеса остановится.

Посмотрите на дашборд (рис. 57). Обратите внимание, как выросло число студентов. Обрабатывать данные тысячи человек вручную в таблицах было бы невозможно.

Как выбрать BI-инструменты?

По способу хранения информации различают два вида BI-инструментов: облачные и требующие установки на сервера организаций (on-premise). Здесь выбор зависит от правил компании по работе с данными:

• Если у вас есть собственные Devops-специалисты и вычислительные мощности для развертывания решения с открытым исходным кодом, вы можете выбрать on-premise. Если нет, можно использовать облачную версию.

Рис. 57. Дашборд с данными о студентах онлайн-школы: он показывает количество студентов с разбивкой по курсам.

• Если инфраструктура данных в компании уже развернута в облаке, нет смысла плодить «зоопарк» решений.

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

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

Однако следует помнить, что BI-инструмент не решит все проблемы. Если в компании не настроены процессы обработки данных, нет смысла ожидать от BI-инструментов эффективности, ведь оптимального построения отчетов не получится. Важно также понимать, достоверны ли данные, на которых строятся отчеты и дашборды, можно ли им доверять, регулярно ли обновляются источники и вся ли информация учтена.

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

В следующей части разберем самое интересное: как аналитики проектируют отчеты и находят ответы на вопросы бизнеса.

Глава 17

Процесс формирования отчетов, визуализация и способы отображения результатов анализа

Чтобы получить корректный результат своей работы, специалисту-аналитику важно понимать:

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

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

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

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

От ответов на эти вопросы зависит то, в каком виде нужно представить результат: в виде аналитического отчета или дашборда.

Аналитические отчеты

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

Рассмотрим эффективность аналитического отчета на примере компании Refocus Digital Academy, которая занимается онлайн-обучением в Юго-Восточной Азии.

В своей работе руководитель Refocus столкнулся с рядом проблем:

• Избыток источников информации.

• Неясность целей и задач использования данных.

• Отсутствие стратегии работы с ними.

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

• Сложный способ подачи информации в отчетах, что мешало руководству видеть основные тенденции.

Команда LEFT JOIN устранила эти трудности. Помимо инженерной работы, мы с командой создали с нуля стратегию для работы с данными и изменили подходы к формированию аналитических отчетов. В результате руководитель Refocus получил инструмент для своевременного принятия решений.

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

Рис. 58. График, показывающий конверсию из лидов в покупателей по месяцам

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

Дашборды

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

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

Комплексная визуализация вашего бизнеса может выглядеть так (рис. 59):

Рис. 59. Дашборд – комплексная визуализация вашего бизнеса

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

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

• как читать диаграмму,

• на какие элементы стоит обратить внимание.

Дашборд содержит основные показатели эффективности, объясняет их появление и значение для отдельной задачи и организации в целом. По сути, это автоматически обновляемая система визуализации данных и показателей, которая:

• интерактивна;

• имеет много уровней;

• наглядна.

Что мы подразумеваем под интерактивностью дашборда? С ним можно активно взаимодействовать:

• переходить от общих показателей к частным;

• смотреть, из чего формируется система метрик, кто и какие данные предоставил для расчета отдельного показателя;

• возвращаться к общей картине.

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

Рис. 60. Таблица с данными

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

Взгляните на этот пример: на рис. 60 информация представлена в виде таблицы, на рис. 61 – в виде графика. Где легче найти аномальное значение в данных?

Рис. 61. Графическое изображение данных

Ответ очевиден.

Рассмотрим работу над аналитикой при помощи дашбордов на примере кейса телеком-компании Aircall. Мы с командой работали над их проектом по инжинирингу и визуализации данных.

На рисунке 62 изображены массивы данных компании. Пропущенные звонки собраны в строки. Дополнительно им присвоены метки: входящие от бизнес-партнеров, коммерческих агентов, других абонентов.

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

Рис. 62. Массивы даных компании

Давайте посмотрим, что получилось, когда на основе «сырой» информации мы построили интерактивные дашборды с помощью Looker (рис. 63).

Рис. 63. Интерактивный дашборд

Теперь информация представлена наглядно. Дашборд ее структурировал и позволил быстрее:

• отследить нагрузку на сеть провайдера,

• сделать выводы,

• принять решения.

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

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

Именно поэтому важно, чтобы внутри организации метрики были выстроены в систему.

Это облегчит создание дашборда. Ведь, повторюсь, аналитика – это комплексная работа. Одно зависит от другого.

Кстати, иногда дашборды бывают полезны не только в бизнесе, но и в обычной жизни. Я адаптировал их в повседневность, и вот как это помогло мне.

Первые месяцы после рождения ребенка – одни из самых сложных для родителей. Так было и у нас с женой. Мне кажется, после выписки из роддома мы перестали спать, иногда ложились после трех или четырех утра. Думаю, многие, у кого есть дети, сейчас неосознанно кивают. Это был наш первый ребенок, и, как тревожные родители, мы хотели знать, что с ним происходит каждую секунду.

Сложно удержать в голове разом большой объем новой информации. И так как наша семья ориентирована на технологии, мы обратились за помощью к девайсам. Решили использовать специальное приложение на Apple Watch – Baby Tracker. Оно помогало отслеживать некоторые процессы ухода за ребенком:

• время засыпания и пробуждения;

• время кормления;

• необходимость смены очередного подгузника.

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

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

Используйте рабочие инструменты, адаптируйте их, и это может помочь вам улучшить качество жизни не только в работе, но и в быту (рис. 64).

Вернемся к бизнесу и аналитике. Важно понимать: дашборд обычно готовят одни сотрудники, а пользуются им другие. Допустим, аналитики создали дашборд для маркетингового отдела.

На его основе маркетологи в свою очередь:

• построили стратегию для продвижения продукта компании,

• оценили эффективность маркетинговых акций и измерили стоимость привлечения лидов,

• скорректировали план рекламных кампаний.

Рис. 64. Дашборд в быту

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

• стратегические;

• оперативные;

• аналитические;

• тактические.

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

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

На дашборде (рис. 65) можно увидеть:

• общий объем трафика и конверсию;

• средний чек и LTV клиента;

• динамику продаж и среднего чека;

• распределение продаж по регионам.

Такой дашборд помогает понять пользовательские предпочтения.

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

Рис. 65. Оперативный дашборд, показывающий активность аудитории сайта интернет-магазина

Независимо от типа, главные его преимущества неизменны – интерактивность, наглядность и интуитивная понятность для пользователей. Какой же итог мы можем подвести?

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

Повторюсь, дашборд строят в зависимости от целей. Нужно учитывать:

• для кого он предназначен,

• какие основные задачи поставлены перед аналитиком (непосредственно аналитика или помощь руководству в административных вопросах),

• какие системы показателей используются в организации.

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

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

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

Основные типы графиков в визуализации данных

Дашборды, отчеты, презентации… Все это – форматы для удобного анализа данных. Но как спланировать и скомпоновать графики так, чтобы получить максимум пользы, используя минимум «чернил»?

Приведем цитату Эдварда Тафти, американского статистика и автора книг по визуализации:

«Большая доля чернил на графике должна представлять информацию о данных, меняясь по мере их изменения. Чернила – это нестираемая суть, основной блок, собранный для отображения изменений в представляемых числах»[6].

Иными словами, если убрать из графика «чернила», или, по-другому, линии, цифры и буквы, то он потеряет всякий смысл. С другой стороны, нельзя переборщить с данными в отчете, увлечься излишним текстовым описанием или обводкой и другими визуальными эффектами. Иначе пользователь не сможет сконцентрироваться на том, что важно.

И здесь перед аналитиком встают задачи уже совершенно другого порядка: какой вид визуализации подойдет к каждому конкретному случаю, как презентовать данные так, чтобы финальный дашборд был понятен не только ему, но и, скажем, коллеге из маркетингового или продуктового отдела?

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

Два главных типа визуализации данных, которые обычно помогают быстро разобраться в показателях любому, кто смотрит отчет:

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

Рис. 66. Пример столбчатой диаграммы – график прироста аудитории моего Telegram-канала LEFT JOIN за 2-й квартал 2024 г.

Рис. 67. Пример статистики Telegram-канала LEFT JOIN в виде линейных графиков

Рис. 68. Показатели метрики ARPU (средний доход в расчете на одного абонента телекоммуникационной сети)

• Линейный график. У вас тоже есть свой персональный – но вы об этом никогда не задумывались – кардиограмма! В аналитике линейные графики используются для визуализации изменений одного или нескольких переменных во времени: роста цен, популярности товара, количества пользователей и так далее (рис. 67).

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

Рис. 69. Пример частой ошибки, которую совершают при создании круговых диаграмм: сумма значений долей должна быть равна 100%

Или другой пример: даже если вы никогда не сталкивались с аналитикой данных, то наверняка видели круговые диаграммы на стендах, в статьях, даже в школьных учебниках (рис. 69). Круговая диаграмма – самый спорный вид визуализации, в нем чаще всего встречаются ошибки (допустим, сумма значений долей больше 100 %).

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

Рис. 70. Круговая диаграмма, которая наглядно показывает процентное соотношение оценок достижения поставленных целей

Это лишь несколько вариантов визуализации данных (рис. 71). Конечно, их в десятки раз больше. Некоторые виды графиков используются чаще других, а бывает, задачи или типы данных можно одинаково хорошо представить двумя разными способами, и тут уже выбирает аналитик на свой вкус.

Теперь вы имеете представление о задачах всех направлений работы с данными и отчетности, которая поможет вашему бизнесу развиваться. И пришло время собирать свой собственный аналитический отдел. Чем мы и займемся.

Рис. 71. Способы визуализации данных

Часть 5

Как организовать работу аналитического отдела

Глава 18

Интересы клиента на первом месте

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

Возможно, вам знаком термин customer obsession, дословно он переводится как «одержимость клиентом». И, безусловно, его интересы мы всегда должны ставить на первое место:

• на стадии разработки продукта,

• в процессе его улучшения,

• на этапе продаж и послепродажного сервиса.

Компания непрерывно исследует потребности, которые ее продукт закрывает, и заботится о том, чтобы покупателю было удобно и приятно им пользоваться.

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

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

Рис. 72. В чем смысл работы аналитика?

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

Глава 19

Роль специалистов по работе с данными в бизнесе

Успешным специалистам по анализу данных необходимо владеть различными навыками, которые можно разделить на 3 группы (рис. 73):

1. Программирование.

2. Математика и статистика.

3. Предметная область бизнеса.

Рис. 73. Необходимые навыки для команды по анализу данных

И в зависимости от задач вашего бизнеса выделяют отдельные специализации в работе с данными. Мы уже знаем, что архитекторы данных проектируют системы хранения и использования информации до момента ее сбора, а аналитики, специалисты по «расшифровке» данных, обрабатывают эту информацию после.

Вспомните аналогию аналитического отдела с функциями строителей из первой главы.

Архитекторы данных – это те же самые архитекторы, проектирующие здание и все его системы. Инженеры данных – строители. Они претворяют в жизнь план архитектора. А аналитики – это арендаторы: они используют построенное, тем самым закрывая потребности клиентов.

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

Архитектор данных (Data architect)

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

Типичные задачи архитектора данных:

• Разработка устройства озера или хранилища данных и предоставление необходимых инструментов для дата-инженеров.

• Обеспечение безопасности и сохранности данных в случае критичных изменений в компании и минимизации последствий таких перемен.

• Интеграция данных в пределах организации.

• Решение вопросов безопасности хранения данных и распределения ролей сотрудников компании, имеющих доступ к ним.

Рис. 74. Архитектор данных

Хороший архитектор данных умет работать с различными компонентами озер и хранилищ: базами данных SQL и NoSQL, инструментами для пакетной (MapReduce) и потоковой (брокеры сообщений) обработки данных, с различными фреймворками для распределенного хранения и обработки данных (Spark, Hive), а также с технологиями построения ETL и ELT-пайплайнов.

Инженер данных (Data engineer)

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

Рис. 75. Инженер данных

Типичные задачи инженера данных:

• Получение и обработка информации из разных источников. Инженеры часто работают с неупорядоченными или неполными данными, собирают и обрабатывают их в озере данных.

• Поддержка и обновление аналитического хранилища данных, пайплайн (отслеживание клиентов на пути к покупке). Инженер пишет так называемые DAG’и, которые позволяют загружать информацию из одного источника в другой и трансформировать ее внутри хранилища данных. Он также строит как промежуточные, так и финальные таблицы данных.

• Взаимодействие с API сторонних источников. Инженеры по обработке данных тесно сотрудничают с аналитиками, их взаимодействие можно сравнить с работой врача и медсестры в больнице.

Инженер данных должен владеть технологиями: Java, Scala, SQL, noSQL, Python/R; уметь применять инструменты для оркестрации данных и ETL/ELT: Airflow, Dagster, Luigi, dbt, Matilon, Pentaho; быть глубоко погруженным в современные базы данных и иметь продвинутые навыки программирования для работы с большими объемами информации.

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

При этом инженеру необязательно разбираться в статистике. Это уже задача специалиста по данным (о нем поговорим чуть позже).

Однако не все предприятия могут позволить себе две штатные единицы, а потому обязанности инженера и специалиста по данным нередко совмещает один человек.

И это возможно, если в арсенале компании есть пул современных инструментов для решения всех задач.

Рис. 76. Часто один человек совмещает роли аналитика и инженера данных

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

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

Что здесь делает инженер:

• настраивает сам процесс переноса данных: пишет скрипты и модифицирует их, если в базе-источнике происходят изменения;

• исправляет ошибки, возникающие в процессе загрузки;

• после загрузки проверяет, совпали ли данные в базе-источнике и в основной;

• поддерживает структуру хранилища: модифицирует таблицы, создает новые.

Рассмотрим работу инженеров на примере приложения для интервального голодания, на котором работа с данными выстраивалась с нуля.

Что было сделано:

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

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

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

Благодаря инжинирингу вся необходимая информация о работе приложения теперь сохраняется в одном месте в структурированном, пригодном для анализа виде.

Аналитик данных (Data analyst)

Рис. 77. Аналитик данных

Аналитик данных – это исследователь. Ему присуще любопытство и стремление изучать информацию с разных сторон, очищать ее, преобразовывать и находить тенденции и новые пути анализа деятельности компании.

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

Типичные задачи аналитика данных:

• Анализ данных и составление отчетов. В то время как инженеры взаимодействуют с необработанными данными, к аналитикам информация поступает из хранилища уже очищенной и преобразованной в более удобные форматы.

• Ответы на вопросы коллег. Аналитики проводят статистический анализ и переводят цифры на человеческий язык. Так, например, они могут оценить, насколько эффективно сработала маркетинговая кампания и как она повлияла на продажи.

Аналитик данных должен знать математику и математическую статистику, владеть методами предварительной обработки данных для анализа. Иметь также навыки программирования на Python/R, использовать MS Excel, писать SQL-запросы и тому подобное. Грамотный аналитик умеет работать в BI-инструментах, таких как Tableau, PowerBI, Metabase, Mode, Redash, Superset; быстро погружаться в контекст компании, чтобы эффективнее работать с данными и находить инсайты. И, что немаловажно, готов брать ответственность за самые сложные и, на первый взгляд, нерешаемые задачи.

Важно! Чаще всего аналитик данных не строит прогнозы. Этим занимается специалист по данным.

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

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

• находит «боль» – потребность компании – и предлагает решение с помощью ИТ-систем;

• изучает и выявляет приоритетные для бизнеса задачи;

• играет роль посредника между руководством компании и техническими специалистами; проводит переговоры, чтобы найти выгодные решения;

• оптимизирует текущие процессы бизнеса.

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

Инженер-аналитик (Analytics Engineer)

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

Типичные задачи инженера-аналитика:

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

• Поиск ответов на вопросы:

✓ Можно ли построить единую таблицу данных, отвечающую потребностям всех бизнес-подразделений?

✓ Как увидеть проблемы с данными до того момента, пока бизнес-пользователь не найдет некорректную диаграмму в отчете?

✓ Что аналитики или другие бизнес-пользователи должны знать о таблице данных, чтобы быстро ею пользоваться?

✓ Как можно улучшить качество данных в процессе производства, чтобы не очищать их в дальнейшем?

Рис. 78. Инженер-аналитик

Инженер-аналитик должен знать алгоритмы и понимать сложность вычислений, уметь работать в современных колоночных СУБД: Snowflake, BigQuery, Redshift, Clickhouse; в своей работе активно использовать технологии dbt, Meltano, Stitch, Fivetran, Airbyte, а также знать и уметь все то, что делают аналитики и инженеры.

Специалист по данным (Data Scientist)

Рис. 79. Специалист по данным

Смысл специальности уже заложен в самом названии data science – наука о данных. Специалист по данным проводит исследования, ставит эксперименты, изучает тренды и тестирует гипотезы.

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

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

Типичные задачи специалиста по данным:

• Проведение описательного и статистического анализа. В результате этого процесса специалист по данным находит скрытые связи и закономерности, может оценить А/Б-тест, его статистическую значимость и так далее.

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

• Прогнозирование, создание отчетов и визуализация результатов. Например, специалист по данным предсказывает вероятность оттока клиентов из компании.

• Кластеризация и классификация данных. Специалист разбивает информацию на группы-кластеры и определяет связи между объектами в этих группах.

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

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

Специалист по данным должен иметь все те же навыки, что и аналитик, а также владеть навыками статистического анализа и знать теорию вероятностей. От него требуются понимание методов машинного обучения и умение оценивать статистические модели. Еще специалист по данным должен владеть R/Python на продвинутом уровне.

Инженер машинного обучения (Machine Learning Engineer [ML])

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

Рис. 80. Инженер машинного обучения

Как правило, разработанные модели машинного обучения должны оказаться в «продакшене», поэтому появляется новая роль – инженер машинного обучения.

Типичные задачи инженера машинного обучения:

• Проектирование, разработка и тестирование ML-систем.

• Создание модели прогнозирования в бизнесе.

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

Инженер машинного обучения должен знать статистику и математику на высоком уровне: математический анализ, линейная алгебра, теория вероятностей, прикладная статистика, дисперсионный анализ; применять на практике основные методы машинного обучения (Supervised и Unsupervised Learning); уметь пользоваться библиотеками Eigen, ML, OpenCV, Spacy и владеть Java, Python, Scala, С++, ML-фреймворками TensorFlow, pyTorch, а также иметь навыки моделирования алгоритмов обучения.

BI-разработчик (Business Intelligence Developer)

Рис. 81. BI-разработчик

Этот специалист может пригодиться более крупному и зрелому бизнесу, так как он работает непосредственно с BI-системами и управляет структурами, связанными с аналитической отчетностью. И на малом предприятии BI-разработчику просто будет нечего делать.

Типичные задачи этого специалиста:

• Структурирование информации и разработка стратегии для ее эффективного использования другими сотрудниками.

• Автоматизация отчетности и визуализация данных.

• Проектирование и воплощение в жизнь многомерных моделей хранилищ, витрин, складов данных.

• Создание хранилищ данных, аналитических отчетов, дашбордов.

Важно! Этот специалист не занимается анализом данных.

BI-разработчик должен знать SQL для управления данными, ETL, Report Builder, SSRS/SSAS/SSIS, способы хранения данных, Power BI, DAX, OLAP, уметь проектировать дашборды, понимать бизнес-операции, свою предметную область (финансы, маркетинг и так далее) и уметь выстраивать коммуникацию с сотрудниками, а также владеть навыками установки и обслуживания BI-сервера: Tableau Server Power, BI Report Server.

Администратор баз данных (Database administrator [DBA])

Рис. 82. Администратор баз данных

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

Типичные задачи DBA:

• Обеспечение резервного копирования и восстановления данных.

• Поддержание безопасности информации.

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

• Поддержание работы баз и их целостности, определение узких мест, ограничивающих производительность.

• Объединение старых и новых баз данных.

• Проектирование архитектуры баз данных и непосредственное развертывание системы управления ими на серверах.

Администратор баз данных должен знать языки баз данных (SQL, NoSQL), основные сетевые протоколы, языки программирования. Понимать и применять механизмы восстановления баз данных, а также работать с облачными сервисами.

Это список основных специалистов стандартного аналитического отдела. Бывают и другие, более узкие, позиции:

• Исследователь и разработчик машинного обучения (ML research and development engineer). Он тестирует гипотезы по разработке алгоритмов машинного обучения для бизнеса.

• ИТ-специалист в сфере дата-инжиниринга (DataOps). Он обеспечивает стабильную поставку больших данных другим разработчиками для последующего анализа.

• MLOps – помогает бизнесу развивать Data Science и быстрее внедрять качественные ML модели.

В зависимости от размера организации и ее целей в работе с данными в отделе аналитики могут быть также специалисты и даже целые команды по визуализации и качеству информации.

Маленькие компании или те, что пока не определились, для чего им нужны данные, могут искать «многостаночников» – специалистов, которые одновременно разбираются в математике, статистике, программировании, машинном обучении и бизнес-задачах. Да, такие профессионалы существуют.

Но как показывает практика, такой подход может быть опасен как для компании, так и для дальнейшего развития самого специалиста.

Поверхностные знания в разных областях лишают шанса разобраться в одной конкретной теме досконально и глубоко.

Кроме того, периодически возникает потребность в новых профессиях. Например, не так давно появилась должность менеджера по управлению проектами в области данных (Data Project Manager) или дата проджект-менеджера.

Этой профессии пока нигде не обучают. В вузах есть специальности «Бизнес-информатика», «Математические методы в экономике», однако в них не предусмотрено обучение дата проджект-менеджменту. Поэтому такие специалисты обычно формируются внутри компании, где они занимаются доменной экспертизой данных, аналитикой и так далее.

В чем суть должности дата проджект-менеджера? Допустим, команда занимается данными и делает проекты. И ей нужен человек:

• компетентный в стеке технологий;

• умеющий общаться с заказчиком;

• корректно ставящий задачи нужным людям и умеющий проконтролировать их выполнение;

• способный работать сразу над несколькими проектами.

Рис. 83. Проджект-менеджер

Рис. 84. Основные позиции в аналитическом отделе

Именно тогда на помощь приходит этот специалист. И это не единственная профессия, которая возникла при появлении новых задач в работе с данными.

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

А мы идем дальше, чтобы понять, как эти специалисты реализуют свои задачи на практике.

Глава 20

Типовые организационные структуры

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

• Кому должен подчиняться отдел?

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

• Должен ли он быть централизованным или встроенным в жизнь других отделов?

• Насколько большой должна быть команда? Сколько нужно инженеров, аналитиков, специалистов по данным?

• В чем заключается основная задача отдела: обслуживать процессы, происходящие в организации, или создавать свой отдельный продукт?

Однозначных правил не существует. Есть только примеры работы разных команд. Вы можете лишь найти похожий и адаптировать его под свой бизнес.

Оценка размера команды

Давайте разберемся, насколько большой должна быть команда для работы с данными? Зависит от тех задач, которые вам предстоит решать в своей компании. Как правило, от общего объема сотрудников количество специалистов по анализу данных должно занимать 5–10 %. Конечно, есть компании, которые имеют гораздо больший аналитический отдел, например, Ozon или «Яндекс. Маркет», но в среднем картина такова.

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

Виды аналитических отделов в компании

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

Централизованная группа по работе с данными

Обычно ее выбирают компании на старте своего пути к управлению данными. Суть модели:

• Единый отдел по работе с информацией, он обслуживает все проекты компании.

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

• Командой управляет руководитель отдела данных.

Рис. 85. Централизованная модель управления

Преимущества централизованной модели:

• Руководитель отдела видит цельную стратегию развития компании и определяет приоритет работы над проектами.

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

• Четкие границы должностей в отделе и прозрачный карьерный рост сотрудников.

• Команда может обслуживать другие подразделения, работая над собственными проектами и адаптируясь к потребностям растущего бизнеса.

Недостатки централизованной модели:

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

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

• Из-за вовлеченности одновременно в большое число направлений и проектов отдел может не успевать заниматься собственными задачами по развитию аналитической инфраструктуры.

Пример компании с такой моделью управления данными – Micron Technology. До 2015 года вся работа с данными в корпорации была децентрализованной и нерегулярной. Но после того как ИТ-директором стал Тревор Шульце, была создана центральная группа по работе с данными. Как говорил сам Шульце в интервью Forbes, «интегрированная аналитическая информация в масштабах всей компании – это важное конкурентное преимущество. Его создание требует усилий, но оно того стоит».

Децентрализованная, или встроенная модель

В этой модели каждое подразделение нанимает своих специалистов для работы с данными.

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

Преимущества децентрализованной модели:

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

• Повышается результативность команды каждого отдела, так как специалисты уделяют все внимание только своему подразделению и досконально разбираются в его работе.

• Специалисты команды развиваются и повышают квалификацию в конкретных направлениях.

Рис. 86. Децентрализованная модель управления

Недостатки децентрализованной модели:

• Нет единого источника данных, единого хранилища, из-за чего информация может дублироваться в разных отделах.

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

• Порой непросто найти подходящего сотрудника по работе с данными для конкретного отдела.

Разберем на конкретном примере. В стартапе «Мед+» (портал и приложение с медицинским контентом) решили внедрить децентрализованную модель. Цель стартапа – помочь врачам в их работе: автоматизировать процесс создания карточки с информацией о пациенте.

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

Есть другой пример – компания, занимающаяся аналитикой продаж. О ней рассказал руководитель сопровождения и трудоустройства «Яндекс. Практикум» Алексей Макаров в интервью для Smart Data. Алексей поделился опытом работы в CoMagic:

«Здесь изначально аналитики нанимались под конкретные направления: маркетинговую аналитику, продуктовую аналитику и так далее. Специалиста по данным также нанимали для определенного продуктового направления. Его непосредственным руководителем был продакт-менеджер. Получается, единой аналитической команды в компании не было».

Децентрализованная модель подходит компаниям со множеством разноплановых аналитических задач из непересекающихся областей.

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

Федеративная модель

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

В федеративной модели есть централизованная группа по работе с данными и отдельные специалисты, работающие в других бизнес-подразделениях.

Что делает руководитель группы:

• определяет приоритеты в работе;

• контролирует выполнение проектов;

• обучает сотрудников.

Благодаря такой модели компания может реализовывать выгодные проекты в области данных.

Пример компании с такой организацией аналитики – «Яндекс Go». Вот что говорит об этом руководитель команды визуализации данных Роман Бунин в интервью каналу Smart Data:

«В команде визуализации данных основной “солдат” – это фулстек-аналитик. Этот специалист может самостоятельно разобраться в “болях” и потребностях бизнеса, собрать и подготовить данные, обработать их на Python, построить модель и создать дашборд. Его суперсила – статистика, аналитика и понимание того направления бизнеса, которое они курируют. Например, есть аналитики, отвечающие за данные по продукту, логистике, маркетингу и тому подобное.

С технической частью им помогают инфраструктурные команды:

• команды внутренних инструментов,

• команда платформы управления данными,

• команда по визуализации.

В свою очередь эти группы выполняют следующие обязанности:

Команда визуализации (менеджер продукта и BI-разработчики) помогает аналитикам с дашбордами, консультирует и обучает, создает шаблоны и руководства по стилю, делает большие отчеты и отвечает за управление контентом.

Группа платформы управления данными (инженеры данных, системные инженеры, партнеры по данным) создает низкоуровневые витрины данных и инструменты по работе с ними.

Команды внутренней разработки (фронтенд-разработчики, ML-инженеры и другие) создает инструменты и модели прогнозирования, библиотеки для Python, платформы для A/Б-тестирования».

Как вы видите из слов Романа, в случае федеративной модели необходимо нанимать множество специалистов, и это речь шла только об отделе бизнес-аналитики. А еще есть большая команда ML-инженеров, специалистов по данным и аналитиков эффективности, которые разрабатывают алгоритмы диспетчеризации, балансируют маркетплейс, настраивают юнит-экономику и так далее.

Для вашего удобства я собрал плюсы и минусы всех моделей организации в одной таблице (рис. 87).

Рис. 87. Сравнение моделей организационных структур

И напоследок расскажу вам об опыте моей команды LEFT JOIN. Какие же специалисты трудятся у нас?

В основном мы работаем с различными digital- и мобильными стартапами, помогаем им выстроить аналитику «под ключ» (end-to-end). Другими словами, мы решаем целый спектр задач от проектирования хранилищ и озер и налаживания процессов инжиниринга данных до автоматизации отчетности, а иногда даже до разработки моделей машинного обучения.

У нас компактный штат сотрудников и соответствующих ролей. Поскольку команда работает параллельно с несколькими проектами, большая ее часть кросс-функциональна. В каждом проекте есть конкретный сотрудник, который ведет команду к достижению цели, а другие коллеги помогают ему, решая конкретные задачи.

Среди наших сотрудников:

• проджект-менеджер – управляет и координирует проекты по работе с данными;

• архитектор данных – отвечает за архитектуру хранилища на проектах;

• три инженера данных – строят хранилища, среди инструментов: Kafka, Airflow; среди СУБД: BigQuery, Redshift, Clickhouse, Redshift, Vertica, MySQL, разумеется, SQL и Python;

• инженер-аналитик – работает с инструментом dbt, строит модели данных в Looker, использует Python и SQL для обработки данных;

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

• три аналитика – владеют рядом инструментов в зависимости от потребностей и возможностей заказчика: Tableau, Looker, Redash, PowerBI и Metabase, также используют SQL. Ряд задач – например, построение классификационных моделей – в компании мы выполняем с использованием Python, Jupyter и в некоторых случаях Collab;

• два Junior Data Analyst – помогают старшим аналитикам и решают часть задач с тем же стеком технологий.

Теперь вы имеете представление о сегодняшних ролях в области работы с данными. И эта область стремительно расширяется, буквально на наших глазах появляются новые задачи, требующие новых специалистов с новыми навыками. Поэтому сегодня нельзя просто опубликовать вакансию с описанием «Требуется аналитик-универсал». Такой специалист вряд ли существует: найти компетентного во всех сферах работы с данными практически нереально. А на каждом этапе развития бизнеса вам будут нужны разные специалисты. И если ваша компания не слишком большая для целого аналитического отдела, то всегда есть выход в виде партнерских отношений с приглашенной командой-консультантом – например, LEFT JOIN.

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

Заключение

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

Анализ данных – сфера деятельности на стыке многих дисциплин: науки о данных, инжиниринга, статистики, математики, экономики, управления продуктом, маркетинга и других. Важно правильно выбрать свой вектор, найти свой икигаи[7], как говорят японцы, и не прекращать развиваться, постоянно изучать новые инструменты, методы и подходы.

И помнить о том, что технологии регулярно меняются, а ваша стагнация – шанс преуспеть для конкурентов.

Сегодня, когда в свет вышла эта книга, мир уже изменился по сравнению с тем периодом, когда она писалась. Однако это не отменяет ее актуальности.

Погружение, которое мы совершили в мир аналитики, станет бесценной основой для дальнейшего роста вашего бизнеса. Мы узнали, что такое данные, что стоит за цифрами, почему они так важны и как работа аналитика помогает компаниям быть успешными, а также как эффективно использовать информацию не только для бизнеса, но и для жизни.

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

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

Книга закончилась, но это не повод прощаться. Если хотите и дальше держать руку на пульсе в сфере аналитики и инжиниринга данных, присоединяйтесь к нашим информационным каналам. Например, мы регулярно делимся актуальными новостями и секретами по работе с инструментами, языками программирования и даже поиску работы в нашем Telegram-канале @leftjoin.

Вы также можете послушать выпуски нашего подкаста Data Heroes или найти много интересного и полезного на нашем YouTube-канале LEFT JOIN.

А если вас заинтересовали услуги в сфере аналитики данных, то компания LEFT JOIN всегда рада новым партнерам. Заходите на наш сайт, чтобы узнать больше о том, что мы предлагаем и делаем. До новых встреч!

Спасибо за выбор нашего издательства!

Поделитесь мнением о только что прочитанной книге.

Примечания

1

Awaken your superhero – https://www.christopherspenn.com/why-awaken-your-superhero/. – Прим. ред.

2

«Лента» – российская розничная торговая компания, включающая в себя гипермаркеты и супермаркеты. – Прим. ред.

3

BI – это Business intelligence, набор методов и инструментов для обработки и анализа данных.

4

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

5

Acquisition Activation Retention Revenue Referral или Привлечение, Активация, Удержание, Доход, Рекомендации.

6

Edward R. Tufte, «The Visual Display of Quantitative Information» («Наглядное представление количественной информации»), изд. Graphics Pr; 2nd edition, 1997 г. – Прим. ред.

7

Икигаи – японское понятие, означающее ощущение собственного предназначения в жизни. – Прим. ред.

Content

Николай Валиотти
Аналитика для руководителей. Стратегия и развитие бизнеса на базе данных, а не на интуиции

4

Введение

Часть 1 Приносят ли данные пользу бизнесу

Глава 1 Зачем вообще бизнесу данные

Глава 2 Как верно соотнести данные с целями бизнеса

Глава 3 Основополагающие направления работы с данными

Глава 4 Жизненный цикл данных

Глава 5 Ключевые специалисты аналитического отдела

Часть 2 Как хранить и организовывать данные

Глава 6 Методы организации данных

Глава 7 Базы данных (БД)

Реляционные базы данных

Базы данных NoSQL

Колоночные базы данных

Гибридные базы данных

Глава 8 Хранилища данных (DWH)

Глава 9 Озера данных (Data Lake)

Как работает озеро данных?

Подводные камни в работе с озерами данных

Дома у озер данных (Lakehouse)

Часть 3 Как быстро и эффективно обрабатывать данные

Глава 10 Инжиниринг данных

Глава 11 Пайплайн и стек данных

Процессы в стеке

ETL-процессы (Extract, Transform, Load)

ELT-процессы (Extract, Load, Transform)

Глава 12 Трансформация и оркестрация данных

Трансформация данных и dbt

Оркестрация данных

Часть 4 Как аналитики работают с данными и создают отчеты

Глава 13 Чем занимается аналитик данных?

Глава 14 Типы аналитиков и задачи, стоящие перед ними

Продуктовый аналитик

Маркетинговый аналитик

Клиентский аналитик

Финансовый аналитик

Операционный аналитик

Аналитик продаж

Глава 15 Строим систему метрик

Метод AARRR

A – Привлечение клиентов

A – Активация клиентов

R – Удержание клиентов

Когортный анализ в работе аналитика

R – Монетизация

R – Рекомендации

Связь метрик и юнит-экономики

Юнит в сделке

Юнит – клиент

Глава 16 BI-инструменты

Виды BI-инструментов

BI-инструменты или табличные редакторы?

Как выбрать BI-инструменты?

Глава 17 Процесс формирования отчетов, визуализация и способы отображения результатов анализа

Аналитические отчеты

Дашборды

Основные типы графиков в визуализации данных

Часть 5 Как организовать работу аналитического отдела

Глава 18 Интересы клиента на первом месте

Глава 19 Роль специалистов по работе с данными в бизнесе

Архитектор данных (Data architect)

Инженер данных (Data engineer)

Аналитик данных (Data analyst)

Инженер-аналитик (Analytics Engineer)

Специалист по данным (Data Scientist)

Инженер машинного обучения (Machine Learning Engineer )

BI-разработчик (Business Intelligence Developer)

Администратор баз данных (Database administrator )

Глава 20 Типовые организационные структуры

Оценка размера команды

Виды аналитических отделов в компании

Централизованная группа по работе с данными

Децентрализованная, или встроенная модель

Федеративная модель

Заключение

Примечания