Как правильно внедрить Self-service-аналитику и для чего вам это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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