Как мы оптимизировали сбор данных для отчёта маркетологов и придумали новую Google Analytics

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

 Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.

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

Как появилась задача

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

Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.

Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.  

Как мы её решали

Дальше разберёмся, как мы оптимизировали процесс формирования отчётов. Начнём с исходного состояния системы — того, что было до наших изменений.

Основные проблемы предыдущей схемы: 

1. Данные обрабатывались параллельно в нескольких системах, что приводило к дублированию логики и расхождениям в отчётности.

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

 Чтобы их решить, мы создали единую архитектуру, где:

1. Все данные собираются в Data Lake.

2. Появился единый источник правды о пользовательских сессиях.

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

 Это был подготовительный этап, на котором мы навели порядок в своей системе. Дальше перешли к сборке дашборда.

Наш дашборд собирает информацию из нескольких источников. Главное — это данные о действиях пользователей на сайте (сессии). К ним мы добавляем сведения о покупках, чтобы видеть не просто посещения, а реальные продажи. 

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

Большую часть данных система получает автоматически, но кое-что пока приходится вводить вручную.

Дальше мы разбирались, почему отчёты приходили поздно. Вся проблема была в сроках получения данных. Самые важные данные — информация о сессиях  — появлялись только в 12 часов дня, на их обработку уходило ещё 4 часа. Поэтому готовый отчёт мы могли отдать только в 16:00 — а маркетологам он был нужен раньше.

Что получилось

На картинке видно главное улучшение — время обработки данных сократилось до 3-х часов. Кто-то может сказать: «Всего 3 часа? Это же всё равно много!». Но нужно понимать нашу специфику. Мы работаем с Data Lake — системой, которая создана для хранения огромных объемов данных. Это даёт нам два преимущества:

1. Храним информацию очень дёшево.

2. Можем работать с действительно большими данными.

Но есть и обратная сторона — быстрые расчёты даются нам сложнее. Поэтому 3 часа — это отличный результат.

Что ещё изменилось:

• Данные о сессиях теперь доступны уже в 8 утра (на 4 часа раньше!)

• Информация об установках приложений тоже стала приходить быстрее

• Рекламные расходы поступают в 11:30, но мы научились встраивать их в отчёт моментально благодаря оптимизации расчётов.

Секрет в том, что мы перестроили процесс: самые тяжёлые вычисления делаем заранее, а последние немногочисленные данные добавляем в самом конце. Так и получилось ускориться.

Наша команда проделала огромную работу по оптимизации системы:

• Грамотно распределила вычислительные нагрузки

• Улучшила алгоритмы расчётов

• Оптимизировала хранение данных

• Максимально распараллелила процессы 

Кроме того, мы постоянно работаем над качеством данных. Хотя это не влияет напрямую на скорость формирования конкретного отчёта, это делает всю систему стабильнее и надёжнее.

Как и зачем мы отказались от Google Analytics

Чтобы получить данные о сессиях на 4 часа раньше, нам пришлось пойти на радикальный шаг — полностью отказаться от Google Analytics и перейти на собственное решение.

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

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

В-третьих, Google объявил о прекращении поддержки старой версии Analytics, которой мы пользовались. Это ускорило наше решение разрабатывать собственную систему. Над проектом мы работали вместе с коллегами из команд сайтов, мобильных приложений и других подразделений. Замена Google Analytics дала нам несколько важных преимуществ.

Точность данных увеличилась примерно на 5%, что улучшило оценку эффективности рекламных кампаний. Мы получили возможность оперативно вносить изменения в методики расчетов, что было невозможно с коммерческими решениями.

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

Как работает новая система аналитики

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

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

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

Если мы обнаруживаем аномалии в данных, то идём к аналитикам. Они понимают, что это ошибка и с ней надо что-то делать. В веб-версиях ошибки обычно исправляются быстро — выпускается новая версия сайта. С мобильными приложениями сложнее: из-за особенностей обновлений (когда пользователи не сразу устанавливают новые версии) некоторые баги могут оставаться в системе месяцами. А самые старые версии приложений вообще остаются с нами навсегда.

Мы называем наши механизмы исправления ошибок «трансформерами». Попробуйте угадать, какие из этих ошибок мы исправляем

1. Приложение «Спортмастер Казахстан» притворяется российским

2. Идентификаторы пользователей попадают в несуществующее поле

3. Идентификаторы пользователей приходят в красивой Е-нотации

4. Очистка данных приложений от неких событий, которые пользователи не совершали

На самом деле, это лишь часть из множества проблем, с которыми мы сталкиваемся ежедневно. Но благодаря нашей системе очистки мы можем обеспечивать высокое качество данных для анализа.

Что дальше?

Сейчас наш дашборд готовится к 11:30 — это уже отличный результат. Но мы видим возможности для улучшения.

Есть решение, которое позволит получать данные об установках и сессиях еще раньше — в 5 утра. Для этого нужно отказаться от ещё одного внешнего источника данных (сейчас он используется для сбора информации о мобильных приложениях).

Остаётся только одно «узкое место» — ручной ввод данных о расходах, который делают коллеги утром в понедельник. Пока мы не можем автоматизировать этот процесс. Надеемся, им не будет слишком сложно начинать работу пораньше — 5 утра ведь вполне спортивное время (шутка).

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