Как получить максимум от внедрения BI-системы: опыт команды аналитики KazanExpress
KazanExpress — российский аналог Aliexpress и Amazon. Маркетплейс бесплатно доставляет товары за один день в 60 городах России.
Руководитель команды анализа данных KazanExpress Юрий Гаврилин рассказывает, как запустить BI-аналитику в облаке за месяц, найти локации для 90 пунктов выдачи в 25 городах России в минимальные сроки и сократить time-to-market новых продуктов от недель к дням.
Привет! Меня зовут Юрий Гаврилин, я тимлид команды анализа данных KazanExpress. Наш маркетплейс родом из Казани, мы продаем товары с бесплатной доставкой за один день. Стартап появился в 2017 году, в июле 2018-го мы нашли первых инвесторов, а в марте этого года привлекли инвестиции от «AliExpress Россия». Сейчас маркетплейс представлен более чем в 70 городах России. В июле мы доставили более миллиона заказов, и каждый год увеличиваем продажи на 800%.
С ростом количества заказов и задач все острее стоял вопрос об автоматизации сбора, анализа и монетизации данных. Продакт-менеджерам нужно было знать, как устроена пользовательская воронка: какие товары смотрят клиенты, что кладут в корзину, почему откладывают покупку.
К тому же за три года в KazanExpress сформировалось много внутренних отделов: от разработки и аналитики до управления складом. Многим нужен был доступ к различным данным. Коммуникация тоже стала сложнее: команды использовали свои инструменты, по-разному считали метрики и были вынуждены постоянно пересылать документы между отделами и объяснять, откуда взялись те или иные цифры.
В ноябре 2020 года мы занялись инфраструктурой для аналитики, которая позволяла бы собирать, обрабатывать и хранить большие объемы данных, легко отслеживать нужные метрики и формировать отчеты.
Как устроена наша команда аналитики
Сейчас у нас четыре аналитика, пять дата-сайентистов и два дата-инженера. Мы сами настраиваем инфраструктуру, собираем данные, анализируем их, улучшаем процессы и продукт с помощью аналитики и машинного обучения.
Информацией от аналитиков пользуются другие отделы:
- Продакт-менеджеры во всех подразделениях компании — чтобы оценивать рост продуктов и принимать стратегические решения по их развитию.
- Финансовый директор и его команда — для отчетности.
- Команда модерации — чтобы вычислять мошеннические схемы среди продавцов.
- Отдел, который отвечает за открытие пунктов выдачи заказов, — чтобы находить точки, где нужны новые.
- Департаменты маркетинга и коммуникаций — чтобы анализировать эффективность рекламы в разных пользовательских сегментах и потребительские привычки в разных городах.
Как мы строили систему аналитики
Архитектура сбора пользовательских данных
Сначала мы думали про готовые платные сервисы аналитики, например, Amplitude, а также свой вариант на основе Kubernetes, Apache Kafka и ClickHouse. Amplitude не подошел из-за дорогой лицензии, которая зависит от количества событий: у нас их очень много. Запустить несколько managed-сервисов и самостоятельно поднять инфраструктуру оказалось дешевле.
Чтобы закрыть все наши потребности, мы выбрали классическую связку Kubernetes + Kafka + ClickHouse. Микросервисы отвечают за то, чтобы принимать данные с устройств, сохраняя их в кафку, а также за то, чтобы на лету обогащать и агрегировать события. Kafka — отличное решение, потому что оно позволяет надежно сохранять прилетающие данные в очередь, где они будут ожидать обработки. Брокеры Kafka и сервисы в Kubernetes быстро горизонтально масштабируются под растущую нагрузку, и мы не переживаем, что потеряем данные.
Данные из Kafka попадают в ClickHouse, колоночную OLAP-базу, с помощью которой можно обрабатывать и хранить большой объем данных, а также выполнять аналитические запросы в режиме онлайн. ClickHouse отлично работает с Kafka: в базе есть встроенный движок таблиц, чтобы читать данные из кафки. Из-за особенностей дизайна ClickHouse в него не рекомендуется заносить данные маленькими кусочками — лучше агрегировать их большими порциями, иначе снизится производительность и скорость вставок. При интеграции с Kafka этого делать не надо — в движке таблиц все уже реализовано и работает из коробки.
Благодаря тому, что три ключевых компонента — Kubernetes, Kafka и ClickHouse — были доступны нам как managed-решения в облаке, инфраструктуру смог создать один разработчик всего за неделю. Оставалось лишь написать микросервисы, которые передавали данные в кафку, и настроить схему таблицы в ClickHouse — на это потратили еще три недели. Когда запустили систему сбора аналитики и в ClickHouse оказались данные действий пользователей, нужно было выбрать BI-систему.
Как выбирали BI-систему
Сначала мы использовали Grafana, но столкнулись с проблемой: транзакционные и пользовательские данные лежали в разных местах. Нужен был инструмент, который мог бы показывать данные из разных источников, а иногда — агрегировать их. Мы сформулировали несколько требований к будущей системе:
- Скорость запуска и стоимость поддержки. Стартапу нужно быстро запускать фичи, которые улучшат пользовательский опыт покупателей и продавцов. Именно на это должны уходить основные ресурсы команды. Поэтому мы искали управляемый сервис, который обеспечит лучший time-to-market и не потребует больших трудозатрат на поддержку.
- Приемлемая цена. Требовалась система, в которой не придется платить за доступ для каждого сотрудника отдельно. Иначе из-за экономии мы бы рисковали «недодать» кому-то доступ к данным, а это противоречит нашей цели быть data-driven-компанией.
- Поддержка разных источников данных. В нашем случае это данные из двух СУБД: PostgreSQL и ClickHouse. Были и другие СУБД, но эти стали основными.
- RLS и гибкие настройки доступа. Внутри компании с данными работает много сотрудников, к тому же доступы к аналитике получают продавцы и маркетинговые агентства. А значит, важно правильно разграничить доступ к чувствительным данным.
- Возможность описать сложную структуру данных. У нас есть центральная сущность — позиция заказа. У нее множество составляющих: заказ, пользователь, город, пункт выдачи, товар, артикул, магазин, продавец. Нужно было создать структуру, в которой отражены все сущности, чтобы сотрудники могли быстро смотреть информацию по каждой из них.
Мы протестировали четыре BI-системы:
- Tableau — популярный инструмент в индустрии. У некоторых коллег уже был опыт работы с ним, поэтому в начале мы рассматривали именно его. Не подошел из-за высокой стоимости и сложностей лицензирования.
- Apache Superset — альтернатива Tableau с открытым исходным кодом. Это бесплатное и гибкое приложение, но под него требовалось поднимать инфраструктуру, а затем самостоятельно настраивать и поддерживать систему. После пары недель тестирования мы поняли, что временные затраты на поддержку не совпадают с целевым time-to-market.
- Cube.js — инструмент, который позволяет конструировать OLAP-кубы. У него более высокий порог входа, он требует большей кастомизации и полезен для кейсов, в которых нужно, к примеру, создавать продвинутые BI-системы и вставлять их на сайт.
- Yandex DataLens — готовый облачный сервис Yandex.Cloud для анализа и визуализации данных. Он умеет подключаться к разным базам данных, запущенным в облаке, не требует затрат на поддержку и администрирование, а лицензия бесплатная. По совокупности наших требований выбрали именно его.
Как мы тестировали и запускали Yandex DataLens
Мы изучали инструмент на протяжении нескольких спринтов:
- Первый спринт. Разбирались с интерфейсом и сущностями. Стали добавлять основные модели данных. Сделали интеграцию с Яндекс.Метрикой и AppMetrica. Это было полезно, так как мы исторически использовали AppMetrica для сбора пользовательской аналитики.
- Второй спринт. Из чартов, созданных во время первого спринта, собрали дашборд для команды и отобразили на нем отчет о финансовых результатах в разных разрезах.
- Третий спринт. Определились, что DataLens будет основным BI-инструментом. Дали доступ большему числу сотрудников.
- Четвертый спринт. Вышли на операционное использование.
Как аналитики используют BI
В работе аналитика можно выделить три направления:
- Принятие решения: делаем ли мы эту фичу, какой вариант экономически выгоднее.
- Помощь в принятии решения: предоставлять и систематизировать данные и метрики, чтобы мы могли выбрать наилучшее решение.
- Создание self-service-инструментов, с помощью которых можно принимать решения без участия аналитика.
Self-service-инструменты снижают нагрузку на аналитиков, позволяя автоматизировать рутинные вопросы. В KazanExpress мы создали несколько таких инструментов с помощью дашбордов DataLens. Эти дашборды можно разделить на три группы:
- Обзорные дашборды с верхнеуровневым описанием бизнеса в цифрах.
- Дашборды-сущности с одним или двумя селекторами, но с большим количеством чартов, которые досконально описывают некую сущность.
- Дашборды-инструменты с большим количеством селекторов, позволяющие смотреть на метрики и делать выгрузки в разных разрезах.
Обзорные дашборды
Обзорные дашборды используются чаще всего и дают много полезной информации. На наших дашбордах мы следим за важными для бизнеса метриками и их изменением. Например, B2C-направление смотрит на следующие метрики:
- Количество заказов и выручка.
- DAU и MAU.
- Конверсии воронки продаж: просмотр товара, добавление в корзину, покупка.
- Количество новых покупателей.
Один из обзорных дашбордов мы показываем по телевизору в офисе, чтобы вся команда видела, с какой скоростью растет бизнес.
Дашборды-сущности
В нашем маркетплейсе есть две самых важных сущности — покупатель и продавец. Мы отразили их в дашбордах, где можно вбить ID сущности и получить полную информацию о ней.
Вот пример того, как выглядела первая версия дашборда покупателя. Он полезен в разных ситуациях, например, когда нужно узнать о пользователе чуть больше для подготовки к глубинным интервью
Дашборды-инструменты
Аналитикам часто приходится делать рутинные выгрузки. Для них мы используем дашборды, в которых селекторы выступают в роли фильтров.
Например, частый случай — это выгрузка типа «Пользователи, которые сделали заказ в период с XXX по YYY в категориях C1, C2, C3 и средним чеком $$$». Для автоматизации кейса мы подготовили простенький дашборд, где все эти параметры отражены в виде селекторов. Так маркетинг быстро получает список пользователей, для которых может быть релевантна акция в той или иной категории.
Как мы прототипировали кабинет аналитики
Одна из самых интересных задач, которую мы решили во время тестирования DataLens, — создание кабинета аналитики для продавцов.
Перед тем, как добавлять аналитику в личный кабинет, мы сделали MVP на основе дашборда-сущности продавца и предоставили доступ к нему продавцам. Создали релевантные модели данных и с помощью RLS разделили доступы, чтобы каждый продавец мог видеть данные исключительно по своему магазину.
В этот дашборд мы добавили:
- Список всех магазинов, принадлежащих продавцам, и их рейтинги.
- Раздел о выручке, в котором отображается количество заказов и покупателей, оборот товаров и прибыль.
- Раздел с товарами, в котором есть топ популярных категорий и продуктов, данные об их себестоимости и остатке на складе.
- Раздел с информацией о том, как пользователи взаимодействуют с товарами продавца: как изучают страничку, по каким поисковым запросам ищут.
- Раздел с оценками и отзывами на товары: в нем можно посмотреть, что пишут покупатели, и узнать, как менялся рейтинг конкретного товара.
- Раздел возвратов, в котором подсчитываются убытки и отображаются причины отказа от товара — это помогает заметить, например, брак в партии.
- Раздел с промокодами.
Мы собрали этот дашборд очень быстро и получили много обратной связи от продавцов. Они подсказали, в каком направлении двигаться, что им важно знать. Иногда мы отключали некоторые чарты, и продавцы тут же обращались к нам с вопросами. Благодаря таким экспериментам получилось приоритизировать работу над будущим кабинетом аналитики.
Мы не смогли и дальше использовать DataLens, так как у него были свои минусы: авторизоваться в личном кабинете можно только через Яндекс, нужно знать почту каждого продавца, добавлять его данные в Yandex.Cloud и настраивать авторизацию. Масштабировать продукт на несколько тысяч продавцов в таких условиях сложно. Поэтому сейчас для этой задачи мы используем Cube.js: он легко интегрируется с нашей авторизацией.
Что изменилось с внедрением DataLens
Улучшился time-to-market продуктовых решений
Визуальный конструктор DataLens позволяет быстро анализировать данные и проверять гипотезы. На процессы, которые раньше занимали недели, теперь уходит несколько дней.
Сократились ошибки в отчетности и операционные расходы
Раньше финансовый отдел составлял отчеты в Excel: данные брали из разных источников и переносили в таблицы вручную. Это отражалось на скорости работы, к тому же сказывался человеческий фактор и в документах встречались ошибки.
Теперь сводные таблицы создают в DataLens:
- Исчезла путаница в данных благодаря единой модели, описанной в DataLens.
- Работа финансового отдела ускорилась примерно на час в день.
- Другим командам стало легче смотреть отчеты финансового отдела.
- Упростился поиск ошибок: команда аналитики может быстро получить доступ к отчету в облаке.
Пункты выдачи открываются в самых нужных местах
С помощью встроенного в DataLens геокодинга мы транслировали адреса курьерской доставки в точки на карте и увидели, что в некоторых районах люди часто заказывают доставку курьером, потому что рядом нет пунктов выдачи. Теперь мы учитываем эти данные при открытии точек.
Данные для принятия решений стали доступнее
Все сотрудники получили доступ к релевантным отчетам с актуальными данными и аналитикой. Это делает бизнес прозрачнее, а решения — эффективнее.
Советы KazanExpress
- Обращайте внимание на то, чтобы у всех сотрудников был удобный доступ к данным и их обработке. Нужно создать такую схему доступа, которой смогут пользоваться даже не самые технически сильные команды.
- Интересуйтесь, какие инструменты и паттерны обработки данных есть в индустрии. Рынок быстро меняется: постоянно появляются новые технологии.
- Выберите шаблоны дашбордов, на основе которых будете создавать новые.
- Не тратьте много времени на поддержку, настройки и резервное копирование сервисов, если можете использовать managed-сервис. Лучше сконцентрироваться на бизнес-логике и быстрее запускать фичи.
Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.
Другие истории, которые активно читают наши подписчики:
Нет упоминаний Google data studio. Я, конечно, в таких масштабах не юзаю, но есть ли критерии, по которым data studio не прошла или вообще не рассматривали её? Чтобы потом тоже понимать, где и почему не подходит.
Комментарий недоступен
Я тоже хотел сказать, что отбор проводился несколько однобоко. По принципу "так, есть решение А, пробуем. Не взлетело - есть ещё Б, пробуем". И так по кругу пока что-то не взлетело. А то, что в рассмотрении не участвовали десятки решений, которые могли бы взлететь и повыше - не учитывается. Бэкенд - вообще безальтернативный - Кликхаус и поехали. Шина - только Кафка. Не, Кафка - ОК. Но не всегда и не во всём. Где варианты, подводные камни, наступленные грабли? :) Rabbit MQ, ELK, BigQuery. Где они? Визуализация - бесплатная Графана (у нас на ней только простые графики на офисные мониторы рисуют типа температура-влажность по помещениям) и пара подобных против Табло и всё. PowerBI, Qlik, Looker - где это всё? ))) Dash, Streamlit в конце концов или Voila: коль скоро у вас аж три датасатаниста, то они (оф корз) постоянно пишут на Питоне в Юпитере - так с этими решениями их рабочие черновики в три клика превращаются в корпоративные дашборды. Но нет их в рассмотрении.
Короч, ощущение действительно, что у нас тут просто бенефис Яндекс линз и всё.
Круто.
Я как-то написал в их чате (пока меня не забанили) Что, чтобы за сутки доставлять в другие регионы им нужна авиация.
Да да нужна транспортная ....БЕСПИЛОТНАЯ авиация. Причем не единичные полеты, а вылеты каждые полчаса. Как змейка из спутников старлинк :))
И этот паровозик на 300м летит по прямой до логистического комплекса километров за 300, а лучше за 800 (до москвы)
Все понимаю, такого сейчас нет, но вот и будет повод создать такие беспилотники которые смогут килограмм по 200 таскать на себе, сделаные из "картона и синей изоленты, короче дешевые" :))
Зачем ты спалил идею на миллиард?
Это же изменит мир!
Ты сам мог бы этим воспользоваться и создать стартап..
Теперь идею уведут…
Сравнение однобокое. Какие то левые cube.js, поломанный опен сорсным планированием superset, который не может в графики если по оси абсцисс нет времени, какой нахрен тайм ту маркет, когда суперсет разворачивается за полчаса и почти не требует поддержки?? Почему не упомянули ни один его реальный недостаток, просто придумав отговорку.
При этом из серьезных конкурентов только tableau.
Где power bi, qlik? Где опен сорсные metabase и redash? И это не говоря уже о более экзотических BI, которых еще много. Есть yandex lens, но нет google data studio? Ммм, понятно)))
Не, я понимаю, что статья рекламная и серьезный справедливый анализ тут показывать было нельзя, потому что yandex data lens вообще не факт что будет победителем, но то что написано - полный бред. Из правды только стоимость табло, но и тут это лишь повод для дискуссии и более глубоких расчетов (спойлер: часто внедрение табло даже за огромные бабки в стратегической перспективе все равно обходится выгоднее)
Какие то левые cube.js
«Вот сейчас обидно было!», — скажу я как человек из команды Cube.js 🙂
Если интересно, то Cube.js позволяет получить очень быстрый аналитический API поверх данных в любых SQL-совместимых хранилищах (от Postgres и MongoDB до BigQuery и Snowflake). Быстрым он будет из-за встроенной в Cube.js функциональности для материализации данных в виде OLAP-кубов.
Как справедливо сказано в статье, у Cube.js довольно высокий порог входа: поверх API придётся программировать UI, но этот UI сможет быть любым. Например, на этом сайте все данные приходят из Cube.js (https://nftbank.ai/explorer).
Cube.js — это опенсорс, весь код на GitHub, можно взять и попробовать (https://github.com/cube-js/cube.js). Запускется в Докере за минуту (https://cube.dev/docs/getting-started/docker).
P. S. Помню, как ребята из KazanExpress задавали вопросы в Slack-сообществе Cube.js, так что знаю, что мы в списке решений, которые они попробовали, не для галочки.