Как получить максимум от внедрения BI-системы: опыт команды аналитики KazanExpress

KazanExpress — российский аналог Aliexpress и Amazon. Маркетплейс бесплатно доставляет товары за один день в 60 городах России.

Руководитель команды анализа данных KazanExpress Юрий Гаврилин рассказывает, как запустить BI-аналитику в облаке за месяц, найти локации для 90 пунктов выдачи в 25 городах России в минимальные сроки и сократить time-to-market новых продуктов от недель к дням.

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

К тому же за три года в 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 для анализа и визуализации данных. Он умеет подключаться к разным базам данных, запущенным в облаке, не требует затрат на поддержку и администрирование, а лицензия бесплатная. По совокупности наших требований выбрали именно его.

Мы изучали инструмент на протяжении нескольких спринтов:

• Первый спринт. Разбирались с интерфейсом и сущностями. Стали добавлять основные модели данных. Сделали интеграцию с Яндекс.Метрикой и AppMetrica. Это было полезно, так как мы исторически использовали AppMetrica для сбора пользовательской аналитики.
• Второй спринт. Из чартов, созданных во время первого спринта, собрали дашборд для команды и отобразили на нем отчет о финансовых результатах в разных разрезах.
• Третий спринт. Определились, что DataLens будет основным BI-инструментом. Дали доступ большему числу сотрудников.
• Четвертый спринт. Вышли на операционное использование.

В работе аналитика можно выделить три направления:

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

Self-service-инструменты снижают нагрузку на аналитиков, позволяя автоматизировать рутинные вопросы. В KazanExpress мы создали несколько таких инструментов с помощью дашбордов DataLens. Эти дашборды можно разделить на три группы:

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

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

• Количество заказов и выручка.
• DAU и MAU.
• Конверсии воронки продаж: просмотр товара, добавление в корзину, покупка.
• Количество новых покупателей.

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

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

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

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

Например, частый случай — это выгрузка типа «Пользователи, которые сделали заказ в период с XXX по YYY в категориях C1, C2, C3 и средним чеком $$$». Для автоматизации кейса мы подготовили простенький дашборд, где все эти параметры отражены в виде селекторов. Так маркетинг быстро получает список пользователей, для которых может быть релевантна акция в той или иной категории.

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

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

В этот дашборд мы добавили:

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

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

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

Мы не смогли и дальше использовать DataLens, так как у него были свои минусы: авторизоваться в личном кабинете можно только через Яндекс, нужно знать почту каждого продавца, добавлять его данные в Yandex.Cloud и настраивать авторизацию. Масштабировать продукт на несколько тысяч продавцов в таких условиях сложно. Поэтому сейчас для этой задачи мы используем Cube.js: он легко интегрируется с нашей авторизацией.

Улучшился time-to-market продуктовых решений

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

Сократились ошибки в отчетности и операционные расходы

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

Теперь сводные таблицы создают в DataLens:

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

Пункты выдачи открываются в самых нужных местах

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

Данные для принятия решений стали доступнее

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

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

• Интересуйтесь, какие инструменты и паттерны обработки данных есть в индустрии. Рынок быстро меняется: постоянно появляются новые технологии.

• Выберите шаблоны дашбордов, на основе которых будете создавать новые.

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

Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

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

• Облака, ML и AI в августе: как дипфейки вышли на работу, зачем беспилотнику морское дно и что с подписками Docker
• Как бизнесу выбрать базу данных под свой проект? Сравниваем on-premise и управляемую БД
• Где открыть бизнес: ищем точки на карте с помощью сервиса Yandex DataLens