Всем привет! Это новый канал связи сервиса myBI Connect с читателями. Меня зовут Алексей Сидоров, здесь я буду писать обзорные статьи о функционале нашего сервиса и размещать кейсы пользователей их авторства, они, кстати, уже на подходе...
Раз это первый пост, думаю, уместно познакомиться и рассказать про себя, функционал, задачи и все остальное. Даже если вы с нами уже знакомы, вы найдете пару грядущих анонсов в этой статье, а если же еще не знакомы и вы работаете с рынком данных, визуализаций, хранилищ и аналитики – сейчас самое время, потому что мы считаем себя, как минимум, одним из лидеров этого рынка в рамках определенного пула задач.
0. Завязка
Начнем с истории, откуда мы вообще появились с такими амбициями? Пожалуй, я пропущу увлекательные рассказы про свое первое рекламно-аналитическое агентство в 2007-ом, получение сертификата партнера Google Analytics одними из первых в России, пьяные РИФЫ, соорганизацию первой конфы по веб-аналитике, продажу первого бизнеса, несколько удачных обучающих проектов и десяток провалившихся задумок в области digital, это все для мемуаров.
Важно, что примерно в 2015-ом году, имея приличный багаж в области аналитики веб-данных, мы начали плотно сотрудничать с Сергеем Казициным, берясь за заказы по разработке индивидуальных аналитических систем. Мой опыт был больше связан с интерфейсами, показателями и влиянием из на бизнес. Сергей раскрыл глаза на базы данных, системы визуализации и BI в конце концов, а позже стал моим партнером, автором и разработчиком сервиса myBI Connect.
Итак, любая аналитика, как вам известно – это сбор, обработка и предоставление данных. Именно с такими задачами нам и пришлось столкнуться в первых проектах и в этой статье мы разберем их решение на примере проектов myBI n-летней давности.
1. Сбор данных
Мы работали с множеством веб-источников – рекламные кабинеты, счетчики статистики, CRM. Как правило, нами решалась классическая задача пользователя по расчету окупаемости вложений в рекламу, сквозная аналитика, но с каким-то интересным приколом, который не могла переварить никакая коробочная система сквозной аналитики и поэтому клиенты прибегали к построению своей.
При этом набор источников данных от проекта к проекту отличался, но все они предлагали API для получения данных. Сергей прошелся по существующим системам ETL и прочим упрощающим выгрузку, но не подобрал ничего достойного и начал разрабатывать собственные скрипты выгрузки данных.
Спустя N проектов у нас появилась «коллекция» скриптов выгрузки из самых популярных сервисов, постоянные расходы на их поддержку и понимание, что заниматься дальше внедрением подобных проектов мы не хотим;)
Думаю, вы не просто так читаете эту статью и имеете представление о сложностях проектного внедрения: клиенты не хотят внедряться в проект, нет нормальных данных, да и в целом, чтобы реализовать то, что хочет руководитель – нужно перестраивать все с самых низов, а потом уже реализовывать аналитику. По крайней мере так было в 17-ом году, об этом я выступал на рифе и написал неплохую статью, основы которой встречаю почти каждый в новых интерпретациях других авторов - Подводные камни на пути к data-driven: принцип GIGO.
Проектная деятельность неизбежно сталкивала нас с необходимость создания костылей, которые позволяют обойти те или иные исходные проблемы, недоработки, ошибки на стороне клиента. Ну а поддержка таких костылей...сами понимаете. Поэтому получив в ответ на отправленный отчет очередную формулировку типа: «Такой вариант не нравится, придумайте сами чтобы понравился, вы же эксперты!» от компании, именовавшей себя экспертом в предметной области, мы решили завершить эту малополезную деятельность и заниматься тем, что получается хорошо;)
А именно – выгрузкой данных, она у нас работала стабильно, была достаточно универсальной для аналитических задач и, по большому счету, не имела аналогов. Поэтому мы посчитали, что она может получить более широкое применение, если использовать ее будем не только мы, но и другие профессиональные аналитики.
Тогда решение перестать заниматься внедрением уже родной веб-аналитикиой было не очень простым и очевидным, но сейчас понятно, что оно было единственно верным. Во-первых, мы разрешили технологический «конфликт» между костылями и качественной выгрузкой. Перестали "прогибаться" (подстраивать выгрузку под локальные задачи клиентов) и продолжили разработку в рамках общепризнанных оптимальных решений по выгрузке. Во-вторых, перестали конкурировать с рынком😉 Другими словами, те компании, которые начинали развиваться на этом рынке вместе с нами, стали пользоваться нашей выгрузкой для решения задач своих клиентов, становиться нашими партнерами и помогать развивать выгрузку и сервис.
2. myBI Connect
Так появился наш saas - myBI Connect. Мы созвонились с Сергеем после нового года, решили переключиться на сервис, зарелизили его в мае-июне 2017-ого и погнали...Ну как погнали, запрягли первую немного корявую тележку и поехали с ней искать аналитиков, которые могли бы по достоинству оценить возможность получить в пользование базу данных в облаке с оптимальной аналитической структурой данных, которые будут обновляться автоматически. И как вы догадываетесь, мы нашли таких;)
myBI Connect - инструмент аналитика, который позволяет получать данные в промежуточное хранилище для дальнейшего использования для анализа и создания отчетов. Сервис предоставляет пользователю полный доступ к классической реляционной базе данных, которую сервис обновляет автоматически ежедневно или чаще по расписанию. Далее пользователь самостоятельно обращается к этим данным, используя любой удобный инструмент визуализации и строит отчеты, а мы поддерживаем актуальность данных и соответственно его отчетов.
Список источников данных и функционал подробно описаны в нашей справке.
Мы часто говорим о том, что это стандарт и оптимальное решение для хранения, в этой статье вряд ли сможем разобрать это подробно, это сделаем в нескольких следующих, а тут основные принципы:
- Для каждого источника разработана модель данных, которая содержит таблицы фактов и таблицы измерений, вместе образующих звезду или снежинку. Если не знаете, что это – вам сюда. Эти модели лежат в основе методологии BI уже лет 20-30 и позволяют объединять данные из разных источников между собой через общие таблицы измерений, к примеру, справочник дат, идентификаторы трафика или utm-метки. Такая структура хранения дает максимальную “гранулярность” и возможности по дальнейшей агрегации, сложным расчетам, условным связям и прочему.
- Мы обновляем данные ежедневно, выгружая только измененные данные. Это позволяет не нагружать сервера и источников данных постоянной перезагрузкой всего объема данных - они это сильно не любят и блокируют доступ при превышении лимитов запросов. То есть каждый день ночью сервис обращается к источнику данных с запросом передать все измененные данные за прошедший период и добавляем их в БД.
- Похожим образом работает историческая выгрузка. Если пользователю нужно выгрузить последний год – мы разбиваем этот интервал на небольшие промежутки и последовательно выгружаем данные.
- Кроме той структуры, которую мы придумали сами, пользователь может сформировать свою собственную структуру выгрузки – выбрать параметры и показатели, которые ему требуется и сервис будет аналогичным образом выгружать такую пользовательскую таблицу в БД, одну или несколько.
Таким образом, myBI Connect – это часть аналитического "стека", мы предоставляем доступ к БД, а работать с этими данными, готовить отчеты и анализировать нужно пользователю самостоятельно. При этом сервис позволяет решить достаточно специфические задачи по выгрузке данных, к примеру:
- Выгрузить Google client_id и session_id, если пользователь предварительно настроил сбор этих параметров в пользовательскую переменную, потому как методов выгрузки их самих в Analytics отсутствует;
- Выгрузить сделки из Битрикс24 с фильтрацией по определенному менеджеру, воронке или этапу; эти фильтры будут распространяться и на другие связанные таблицы;
- Получить данные по удаленным сущностям из amoCRM практически в реальном времени с помощью вебхуков. Если вы работали с API, то знаете, что после удаления никаких упоминаний об этой сущности вы больше от API не получите, а это значит – если такая сущность была ранее выгружена, то так и останется в базе.
Фишек и особенностей у нас еще много, как и пунктов в контент плане;) Поэтом подробнее про функционал расскажем в следующих статьях.
3. Обработка и визуализация данных
За 5 лет работы мы достаточно хорошо изучили принципы API источников, их баги и скрытые недоработки. Но так или иначе без достаточно компетентного аналитика и инструмента для обработки и визуализации - данные в базе бесполезны. Тут давайте еще один виток назад в 2015 сделаем...
Один из вопросов, которые нам нужно было решить в начале нашей проектной деятельности – это выбор BI-среды для реализации отчетов. Первые демки в myBI были реализованы в Qlik, но спустя короткий промежуток Сергей наткнулся на анонс Mirosoft Power BI, который по сути являлся компиляцией уже имеющихся у Microsoft продуктов – Power Query, Power Pivot и движок xVelocity...
На этом месте я посмотрел на список оставшихся тезисов к статье и понял, что осилить ее целиком будет сложно - и писать и читать, поэтому решил разбить ее на две. Следующую часть с рассказом про визуализацию, текущую ситуацию и несколько анонсов я выложу ровно через 7 дней или раньше(!)– как только этот текст соберет 50 лайков. Если вы дочитал и было интересно, ставь лайк и шерь, дорогой читатель;)