Привет, Хабр! Я Лена Маеркина, CPO в AGIMA. Сегодня хотела бы поделиться опытом, который упростит жизнь продактам и сделает продукт удобнее для пользователей. Как вы поняли, речь пойдет о Self-service-аналитике. Погнали!

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

Если и у вашего бизнеса есть массивная Backend-часть со складами, логистикой, доставкой, товарооборотом, офлайн-заказами, мы рекомендуем внимательно изучить наш опыт. Также такой сетап Self-service-аналитики подходит в том случае, если:

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

  • у вас много продуктовых команд, которым нужно работать с данными;

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

Задача

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

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

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

Проект вели по гибкой методологии Scrum: работа короткими циклами (спринтами), постоянное присутствие заказчика в проекте, совместное формирование бэклога — всё это помогает минимизировать ошибки в итоговом продукте и добиваться результатов в четко обозначенные сроки.  

Как мы внедряли Self-service-аналитику

Команда продуктовой аналитики AGIMA на разных этапах включала от 2 до 9 человек: аналитики, тестировщик, тимлид аналитиков, менеджер. В начале сотрудничества мы подключили одного аналитика и менеджера: собирали данные (приложение + веб) и оборачивали их в отчеты для заказчиков внутри компании.

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

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

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

В рамках задачи по внедрению Self-service-аналитики мы: 

  1. Выстроили иерархию метрик.

  2. Развернули ELT-слой и внедрили BI-инструмент для визуализации данных.

  3. Разработали дата-каталог.

Иерархия метрик

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

С каждой командой мы провели интервью. Узнали, какие у них КПИ, метрики, какие данные собирают.  В результате обнаружили следующие пробелы:

  • командам не хватает некоторых данных, поэтому часть решений принимается наугад;  

  • нет сквозного понимания, как действия каждой из команд влияют на соседей.

На основании собранной информации приняли решение выстроить иерархию метрик

Иерархия метрик — одна из методик работы с метриками, представляет собой древовидную структуру, во главе которой находится ключевая метрика продукта (North Star или метрика «полярной звезды»).

У нас получилось две North Star-метрики — это оборот и MAU, за которые отвечает каждая из команд. Для подготовки иерархии мы:

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

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

  • расписали все эти метрики — от более общих к детализированным.

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

Фрагмент иерархии метрик, на котором видно, как метрики одной из продуктовых команд влияют на North Star-метрику — оборот.
Фрагмент иерархии метрик, на котором видно, как метрики одной из продуктовых команд влияют на North Star-метрику — оборот.

Тут вы можете спросить: зачем это всё? Ведь можно и без иерархии собирать данные и готовить нужные бизнесу отчеты. Да, конечно, можно! Но на наш взгляд, иерархия метрик — это более основательный подход, который помогает выстроить работу с данными в стратегическом разрезе, а не операционном. Бизнесу, особенно крупному, очень важно видеть, как метрики с низких уровней влияют на верхнеуровневые, самые важные. 

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

ELT-слой и Metabase

В основе Self-service-аналитики лежит простой в использовании BI-инструмент с базовыми аналитическими возможностями и удобной визуализацией данных. В нашем случае был выбран Metabase — бесплатный Open Source-инструмент, который имеет низкий порог входа для пользователя и закрывает следующие задачи клиента:

  • позволяет делать дашборды стандартным способом;

  • реализует богатый функционал Self-service-аналитики. 

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

Чтобы запустить работу с BI-инструментом, мы развернули всю инфраструктуру ELT.

ELT (от англ. Extract — извлечение, Load — загрузка, Transform — преобразование) — это совокупность инструментов аналитики, которые позволяют получать данные из разных источников и сразу их визуализировать в BI-инструменте.

Отметим, что изначально все продуктовые команды работали напрямую с Google Analytics, из-за этого многие данные были неточны, потому что был семплинг. Для решения этой проблемы мы создаем единое хранилище данных (DWH). Оно позволит бизнес-пользователям работать со сквозной аналитикой — связать действия от клика на сайте до покупок в том числе в офлайне. С помощью Meltano преобразовываем данные из Google Analytics в аналитическую форму. И на основании этих данных делаем аналитический слой с подготовленными очищенными данными, которые реализуют те метрики, которые нужны продуктовым командам.

Технологический стек ELT-слоя выглядит так:

Экстракторы выгружают данные из Google Analytics UA (Web), AppsFlyer и API Firebase.

Загрузчики передают данные из вышеперечисленных источников в BigQuery.

Трансформеры настроены посредством BigQuery и SQL-запросов. Данные организованы по трем слоям:

  1. Сырые данные.

  2. BI-данные, где сырые данные были очищены и приведены в аналитический вид.

  3. Данные из BI-слоя, в который смотрит визуализатор Metabase.

Все собранные данные Metabase оборачивает в наглядные графики, диаграммы, дашборды. В общей сложности отслеживаем почти 140 разных метрик, таких как:

  • Общее MAU (Monthly Active Users)/DAU (Daily Active Users) по всему приложению.

  • MAU/DAU различных разделов.

  • Количество активированных пластиковых карт в месяц.

  • Android/iOS-установки за месяц.

Это один из самых больших по объему данных проект, только уникальных событий тут 100 000, это очень много. С помощью Self-service-аналитики мы упростили работу с таким объемом данными, постарались снять нагрузку с аналитиков и ускорить получение необходимой информации для заказчиков данных. 

Например, благодаря дашбордам мы максимально снизили количество Adhoc-ов (обращений за выгрузками, отчетами). В начале 2021 года их было до 5 в месяц, сейчас 1 раз в две-три недели

Татьяна Гайнутдинова, Delivery Manager AGIMA

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

  • Работаем над качеством данных, которые попадают в инструмент.

  • Работаем над RnD-задачами, связанными с развитием аналитики. Например, поиск данных, которые мы еще не получаем, но можем.

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

Дата-каталог 

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

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

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

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

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

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

Документация 

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

  • описали дашборды;

  • рассказали, как работает ELT-слой;

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

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

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

Заключение 

Это был интересный опыт для AGIMA. Мы постарались сделать счастливее еще одну компанию — выстроили для бизнеса удобную Self-service-аналитику. Оптимизировали и упростили процесс сбора и анализа данных, сделав их более точными (иерархия метрик), наглядными (Metabase) и понятными (дата-каталог). 

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

Комментарии (5)


  1. Ivan22
    17.10.2022 18:13
    +2

    в чем self-service то? Где примеры того как директор заходит в BI тул, пишет sql запрос к витрине, рисует ссам себе дашбоард, подбирает шрифты и маштаб, цвета раскрашивает и в конце удовлетворенный восклициет - вот то что я хотел!


    1. ms_causa Автор
      17.10.2022 18:25
      -1

      Идея как раз в том, чтобы директор не писал запросы, а наслаждался понятно визуализированными данными (и в процессе восклицал: «Вот именно этого я и хотел!», да)


      1. Ivan22
        17.10.2022 18:55

        давайте почитаем определение, от например уважаемых Gartner:

        https://www.gartner.com/en/information-technology/glossary/self-service-business-intelligence

        "Self-service business intelligence is defined here as end users designing and deploying their own reports "

        Т.е. конечные потребители должны сами и дезайнить и деплоить свои репорты. Иначе это что угодно но не self-service bi


        1. ms_causa Автор
          18.10.2022 15:22

          Ни в коем случае не спорю с уважаемыми Gartner и вами)
          Просто Metabase как раз позволяет пользователю самостоятельно собрать отчет, но без написания sql-запроса — можно "накликать" ответ по данным из подготовленных витрин. А потом уже сохранить полученный репорт на собственный дашборд.


          1. Ivan22
            19.10.2022 23:00

            Любой BI tool это позволяет, но практика показывает что как селф-сервисом этим никто (почти) не пользуется. Все равно все дашборды делают не юзера, а ИТ-шники. Исключние - эксель, там себе репорты рисуют сами юзеры.