Представим ситуацию: в готовом и уже работающем продукте меняется команда. В проект приходит новый специалист и вынужденно сталкивается с неопределенностью: ему в наследство достаются каким-то образом собираемые данные и кем-то выбранные метрики. Как быть с таким легаси и возможно ли всё поставить на места — разбираемся вместе с диджитал-стратегом JetStyle Евгением Кузнецовым.
Задача
Рассмотрим пример из практики. В проект, где мы отвечали за дизайн, разработку и контент подключился новый продакт-менеджер. Коллегам потребовалась помощь в том, чтобы навести порядок в веб-аналитике и выстроить системную работу. В силу NDA мы не можем называть компанию, поэтому представим, что перед нами крупный мультиязычный сайт, работающий по всему миру.
Решение
Наводим порядок в веб-аналитике
Шаг 1. Определяемся, где мы сейчас
Первым делом мы собрали карту аккаунтов, систем веб-аналитики и рекламных пикселей. Такая карта нужна, чтобы определить, какие системы отслеживают действия пользователей на сайте, и отказаться от тех, которые утратили актуальность.
Важно: каждый устаревший счетчик может не только собирать и передавать данные третьим лицам, у которых остался доступ к аккаунту, но и замедлить работу сайта, что в свою очередь негативно влияет на пользовательский опыт.
В нашем случае карта получилась сложной, так как мы взялись за проект с большой историей в Google Tag Manager (GTM): компания в разное время работала с большим количеством подрядчиков по рекламе из разных регионов, каждый из которых устанавливал свои пиксели рекламных систем. В итоге накопилось большое количество тегов, некоторые из которых зависели друг от друга и содержали кастомный код.
Всё осложнялось тем, что некоторые данные собирались в Google Analytics 3 некорректно, так как сайт компании выполнен по технологии Single Page Application (SPA). SPA — это приложения или сайты, которые состоят из одной HTML-страницы. Они подключаются к серверу только один раз, а затем динамически обновляют содержимое по мере взаимодействия с пользователем, без необходимости перезагрузки всей страницы. Ключевые элементы интерфейса страницы остаются неизменными, обновляются только те блоки, которые использует пользователь, например, переход от одного раздела к другому. GA3 на тот момент была стандартом отрасли, но для работы с ней необходимо дополнительно настраивать трекинг SPA. Миграция на Google Analytics 4, которая умеет работать с SPA из коробки, была еще впереди.
Шаг 2. Составляем карту событий
Мы вручную проверили более 200 тегов и вместе с заказчиком оставили только те, которые были актуальны и собирали полезные данные.
Затем переключились на следующий этап — составить карту событий. Этот подход систематизирует сбор данных и служит справкой для новых участников команды. Карта отражает как, когда и в каком виде мы передаем действия пользователей в систему аналитики. При совершении действия выполняются условия триггера A, который активирует тег B, который передает в метрику событие С с параметрами.
Примеры действий, которые нас интересовали:
- клики по элементам навигации,
- взаимодействия с контактами (телефон, почта),
- взаимодействия с контентом (скролл страниц, просмотры видео),
- клики на CTA (Call To Action),
- отправка форм и заявок.
С помощью собранной и описанной схемы данных мы достоверно понимаем:
- где наступает событие;
- какой триггер в GTM описывает это событие, и как он срабатывает;
- куда и какое событие передается при наступлении;
- как описывается событие в конечной системе.
В конечном счете это позволяет нам системно работать, понимать, что происходит, и легко передавать дела при появлении новых участников в команде.
Шаг 3. Отлаживаем работу Google Analytics с SPA
Главная цель заказчика при запуске рекламных кампаний — генерировать целевые действия пользователей, а именно события регистрации на сайте. Трекинг же нужен, чтобы оценить эффективность каждой РК, успешность заполнения формы и вовлеченность пользователей в контент. Действия посетителей сайта поступают в систему аналитики и формируют статистику, на основе которой принимаются решения.
В нашем примере сайт реализован на технологии SPA. С ней сайты работают быстрее и получаются удобнее для пользователей. Но у таких сайтов есть нюанс: при переходе на следующую страницу не происходит полная перезагрузка фронтенда — меняется не вся структура HTML. Google Analytics 3 не умеет отслеживать просмотры страниц на таких сайтах из коробки, поэтому мы дополнительно отладили работу сервиса.
Мы настроили трекинг SPA через пользовательское событие: в момент перехода разработчики отправляют с фронтенда в dataLayer данные о смене состояния с его новыми характеристиками: Title — заголовок и Path — путь новой страницы. Дальше из dalaLayer эти данные поступают в нужные системы аналитики (GA3) и пиксели при необходимости.
Шаг 4. Отлаживаем систему и документируем изменения
В больших проектах необходимо регулярно проводить отладку системы аналитики и документировать любые преобразования. Иначе большой клубок изменений может запутать не только новых специалистов, но и существующую команду, которая работает над проектом продолжительное время.
Для отладки сбора пользовательских действий мы рекомендуем:
- исследовать текущие события, отправляемые из GTM, удалить устаревшие теги и триггеры;
- понять, каких событий не хватает, а какие можно объединить и ввести параметризацию;
- настроить необходимые теги и триггеры, где необходимо — попросить разработчиков передавать информацию об отправке форм в dataLayer, чтобы быть на 100% уверенными, что событие конверсии отправляется в аналитику только тогда, когда происходит успешная отправка формы;
- настроить логирование ошибок при отправке сложных форм и записать в параметры событий типы этих ошибок, чтобы понимать, где пользователь ошибается при попытке отправить форму;
- протестировать все события в режиме отладки и зафиксировать информацию.
Сложности могут возникнуть на этапе установки рекламных пикселей. Если компания работает с разными подрядчиками, в том числе международными и с отдельными аккаунтами в нескольких сервисах рекламы, то важно проследить за тем, чтобы пиксели конкретных агентств стояли только на тех страницах, которые к ним относятся. Также необходимо задать единую логику по созданию посадочных страниц и стараться соблюдать правило: одно агентство — одна система — один пиксель.
Шаг 5. Разрабатываем правила UTM-разметки и кастомный конструктор UTM-меток
UTM-метки нужны, чтобы получать подробную информацию о каждом источнике трафика и отслеживать эффективность рекламных кампаний.
В проектах заказчиков мы часто замечаем, что метки составлены без единой системы, что сильно усложняет анализ данных по РК.
Для решения проблемы мы разработали систему правил разметки трафика и собрали ее в виде конструктора в Google Таблицах, в котором можно автоматически получать корректные метки, ответив на семь вопросов. Инструментом могут пользоваться как команды внутри компании, так и подрядчики.
Такая стандартизация UTM-разметки упрощает анализ трафика по различным источникам: каналам, кампаниям и бизнес-направлениям.
Строим наглядные аналитические дашборды
Когда клубок распутан и веб-аналитика настроена под заказчика, время сделать так, чтобы системой было просто пользоваться.
Для наглядной визуализации мы использовали удобный инструмент — систему дашбордов. Она не очень подходит для глубокой аналитики, однако позволяет отлично видеть динамику ключевых метрик продукта в одном интерфейсе и вовремя дает понять, если что-то идет не так и нужно копнуть глубже в данные.
Дашборды позволяют оптимизировать трудозатраты продактов на мониторинг состояния и сбор отчетности о работе продукта, а также взглянуть на метрики в различных срезах с удобной фильтрацией данных и наглядной визуализацией.
Чтобы дашборд отражал всю нужную информацию, но при этом не был громоздким, важно:
- определить конкретных людей, кто будет пользоваться дашбордами;
- выделить ключевые метрики для каждого пользователя;
- учесть разные сценарии использования инструмента, например, для подготовки регулярных отчетов аналитик должен видеть динамику по конверсиям.
Дашборды визуализируют информацию под конкретные задачи, например:
- источники трафика и рекламные кампании;
- детализированную статистику по эффективности посадочных страниц;
- данные по ключевым конверсиям на основе расходов из рекламных систем;
- данные о производительности сайта и используемых устройствах пользователей;
- данные об эффективности контента, включая вовлечение в скролл-страниц и просмотр видео на сайте;
- статистику использования поиска по сайту;
- эффективности рекламных кампаний подрядчиков;
- данные поиска Google (Search Console), в том числе те, которые подсвечивают основные точки роста по улучшению видимости и ранжирования в поиске;
- данные о географии пользователей и, например, детальная статистику использования различных языковых версий сайта;
- детальную статистику использования навигации на сайте — по основным блокам элементов и конкретным элементам навигации.
Когда определены срезы и пользователи, можно собрать первый драфт борда и протестировать его. Этот этап дает понять, что нужно переделать и где добавить UI. Дашборды также помогают определить недостающие данные и скорректировать настройки системы аналитики.
Дашборд в Looker Studio (ex.Google Data Studio) на базе данных Universal Analytics
Дашборд в Looker Studio (ex.Google Data Studio) на базе данных Google Analytics 4
Результат
Упорядоченная система веб-аналитики упрощает работу над проектом даже в условиях смены команды, а именно:
- наглядно показывает взаимосвязи между различными тегами и триггерами, например, с помощью карты тегов, аккаунтов, событий и конверсий;
- помогает отслеживать любые события не только на SPA-сайтах, но и на любых других;
- повышает правдивость результатов трекинга благодаря корректным стандартизированным UTM-меткам;
- упрощает принятие решений на основе нужных срезов с помощью дашбордов.
Запутались в легаси проекта и хотите логично выстроить веб-аналитику? Мы поможем не только навести порядок в метриках, но и составим необходимую документацию, чтобы снизить уровень неопределенности для новых специалистов проекта.
