Как и зачем мы построили кастомную систему аналитики вместо Google Analytics
Привет, Хабр! Меня зовут Иван Кизименко, я Head of Analytics в компании Outside. В этой статье мне хотелось бы рассказать о том, как и зачем мы разработали собственную кастомную систему аналитики вместо Google Analytics. Собственно, мы работали не только с аналитикой от Google, но и других компаний, включая, например, Adobe.
Но в один хороший день (а он реально был неплохим) мы решили: «Хватит это терпеть! Пора делать собственную систему». Под катом — о причинах этого решения, особенностях кастомной системы и ряде других интересных для многих читателей Хабра вещей.
Зачем нам это все?
Мы работаем с достаточно крупными заказчиками с глобальными решениями, у которых очень разные системы аналитики. У кого-то — Adobe, у кого-то Google Analytics базовой версии, у кого то 360.
Но у глобальных решений есть ряд проблем:
- Это закрытые системы с рядом ограничений доступа к функционалу.
- У них минимальная возможность кастомизации.
- Если что-то и можно доработать, то это очень дорого и, к тому же, долго.
- Аналитика покрывают собственные решения, не учитывая локальные разработки.
Поскольку Google Analytics, пожалуй, самая популярная система аналитики, то перечислим ее недостатки первой:
- Для построения нестандартных отчетов и дашбордов нужно приложить массу усилий.
- В отчетах системы данные всегда агрегируются, и этот процесс совсем или по большей части не поддается контролю.
- Есть семплирование, которое в некоторых случаях приводит к искажению данных и, соответственно, к неверным выводам и основанным на них бизнес-решениям. Особенно это актуально для данных по событиям и целям.
- В отчетах содержится ограниченный объем определенных комбинаций параметров и показателей.
- Есть ограничение на количество строк для выгрузки по API.
- Что касается времени обработки данных — то обычно нужно ждать 24–48 часов, прежде, чем система обработает информацию.
- В базовой версии Google Analytics количество пользовательских параметров ограничено 20. В платной версии — 200.
- И одна из главных проблем — невозможность исправления или динамического исключения данных при формировании отчетов. Ну, например, не учитывать данные с рабочих IP или исключить учет тестовых заявок.
В целом, мы не ругаем Google Analytics — вовсе нет. Это отличная система, но годится она для ограниченного, хотя и довольно объемного, круга задач. Но как только возникает специфический таск, вроде подсчета показателей за год и сравнения с прошлым периодом, начинаются проблемы. Где-то разметка вообще не покрывает запрос, где-то она отвалилась. Ну или способ написания события изменился, так что приходится «заводить» Python, сортировать данные по дням и неделям и формировать хотя бы минимально приближенные к реальности данные.
Проблемы есть и у других систем, включая Adobe Analytics. Так, если требуется подключить инструменты, которых нет в Adobe, то это долго и дорого. В этом случае построить систему на базе Adobe которая покроет все потребности веб-аналитики компании будет экономически невыгодно. Существенный недостаток системы — покрытие лишь глобальных проектов.
Проблемы иногда возникают там, где их не ждешь. Например, нам понадобился отчет за прошлый год, мы хотели «вытянуть» их из Google Analytics, но не получилось. Оказалось, что кто-то из менеджеров штаб-квартиры зашел в настройки счетчика и изменил настройки, так что все нужные нам исторические данные просто были удалены.
В сухом остатке получаем базовые вещи в довольно сложных системах. Это трафик, лиды, процент отказа (BR).
День, когда все изменилось
Все бы ничего, но есть одна большая проблема — это процент отказов, показатель, на который обращает внимание большинство специалистов. Конечно же, все хотят его снизить. При желании сделать это очень просто — «вешается» таймер на 25 секунд, событие уходит, и получаем снижение процента отказа. Но это лишь формально, в реальности же все осталось, как и прежде.
Если же изменить методику подсчета, например, добавить к секундам 2 события скролла браузера, то BR растет, а сомнительные источники из CPA и Programmatic начинают показывают 80% процент отказа. После смены методики посчитать процент отказа за год, в течение которого использовалось несколько методик, практически невозможно.
Есть и другие проблемы, включая большой объем работы, рост количества Python-скриптов и CRON-задач, сложные отчеты построить сложно, сквозная аналитика оказывается недоступной. В общем, мы решили пересмотреть подход как к ведению аналитики, так и к разметке. Для начала определились с критически важными потребностями:
- Получение доступа к raw-данным.
- Возможность передавать любое количество дополнительной информации.
- Возможность делать Backup.
- Использование авторазметки.
- Возможность подключения базы к BI-инструментам.
Оптимальный вариант — собрать свою систему для сбора данных, которую можно без проблем дорабатывать и кастомизировать с кратчайшие срок. Ну, а в качестве хранения данных воспользовались Clickhouse. Понятно, что собственная система аналитики должна соответствовать ряду критериев, которые мы сформулировали в самом начале:
- Возможность хранения любого объема данных на собственных серверах. Также при необходимости доступ к данным можно ограничивать.
- Собирать любое количество событий и параметров, что дает гораздо больше данных для анализа.
- Возможность интеграции с такими сервисами, как CRM, CAllTracking, BI, мессенджеры, рекламные системы и т.п.
- Кроссплатформенное отслеживание пользователей по cookie и userid.
- Создание собственных моделей атрибуции.
- Работа с Open Source и отсутствие проблем с безопасностью.
- Своевременная обратная связь с сайтом, отправка событий из аналитики на сайт прямо во время сессии пользователя.
- Адаптация аналитического решения под требования определенного бизнеса.
По этим критериям мы и собрали собственную систему аналитики, которую теперь используем. Что касается данных, то они в сыром виде хранятся в ClickHouse. Кстати, еще одно достоинство кастомной системы аналитики в том, что нет ограничений на количество параметров. Это сразу же открыло возможность, например, получить больше информации. Сейчас мы знаем, например, какие цвета, опции, двигатели и другие параметры пользуются большой популярностью в конфигураторах автомобилей.
А что с визуализацией?
В качестве BI-инструмента сначала опробовали metabase, который не подошел, поскольку он странно работает с кэшами и который сложно кастомизировать. Мы выбрали Apache Superset и вот почему:
- Быстро развивается. Каждый месяц какие то новые улучшения и обновления.
- Можно делать свои графики и визуализацию, например, Echarts, у которого в арсенале огромное количество возможностей.
- Кастомизация внешнего вида дашбордов на CSS — довольно просто построить дашборд под фирменный стиль бренда.
- Хороший инструмент для ресерча. Можно быстро зайти набросать SQL запрос, получить ответ.
- Есть возможность отправки отчетов на Email и в Slack
- Разграничение доступа из коробки. Для каждого графика, набора данных, чего угодно можно настроить доступ определенным пользователям.
Сейчас доступно несколько десятков дашбордов с разным уровнем доступа для разных задач. Сюда входят дашборды с базовыми показателями по трафику, дашборды для продуктовой команды/команд и для других агентств.
После того, как система была принята, значительно увеличилась скорость обработки нестандартных вопросов. Сейчас это набор SQL-запросов через SQLab в Superset. А еще — внимание — можно подключить другие, БД, лишь частично занятых в веб-аналитике.
Не забудем про автоматизацию
Для решения рутинных задач мы использовали Apache Airflow 2. это позволило выгружать данные и формировать отчетности в едином инструменте. В конечном итоге удалось агрегировать данные из других источников и других агентств для формирования финальных отчетов.
Спустя некоторое время удалось разработать систему аналитики, которая позволяет не только создавать сервисы, которые реагируют на события в реальном времени, но и отравлять e-mail и Push, плюс отправлять Webhooks либо передавать сигналы прямо в браузер.
Кастомная система, кроме прочих достоинств позволяет без проблем подключаться к любым сторонним IP.
«Под капотом» у системы собственной аналитики — framework для Python и Type/JavaScript, которые упрощают и ускоряют процесс разработки. Можно отметить еще систему запуска и управления, плюс встроенная среда разработки на основе Theia IDE, а также Jupiter Lab для быстрых исследований и создания прототипа. Наконец, Grafana — инструмент для визуализации и несложных дашбордов.
В качестве примера работы получившейся системы можно привести ее использование для обсчета АБ-теста АВН компании Skoda. Кастомная аналитика дала возможность:
- Получить данные из Clickhouse.
- Обрабатывать информацию на Pythone + Clickhouse.
- Хранить рассчитанные данные в CSV.
- Устанавливать таймер на запуск каждые 6 часов.
- Возможность остановить или пересобрать или кастомизировать сервис, поскольку работает он независимо от прочих систем.
Звучит немного сложно, но можно пояснить на примере. Ранее, когда пользователь оставляет заявку на покупку автомобиля, до менеджера по продажам доходил только номер телефона покупателя. Так что специалисту приходится снова звонить клиенту и спрашивать все, что уже было заполнено ранее.
Сейчас менеджер кроме заявки получает сводную информацию о посетителе, включая заинтересованность последнего определенной маркой авто, конфигурацией и т.п. И, к слову, менеджер получает персонализированную информацию. Плюс менеджер лучше понимает, что нужно человеку и что он сможет предложить.
В качестве вывода стоит сказать, что в итоге все получилось — кастомная система аналитики работает на благо клиентов без угрозы потерять данные за полгода или даже год. Анализ данных с последующей визуализацией занимает минимум времени. Ну, а если нужно что-то добавить и убрать — сделать это можно очень оперативно с минимальными затратами.
