Как распутать нераспутываемое: настройка электронной торговли ecommerce проекта
Когда к агентству в работу попадает большой e-commerce проект с уже настроенной аналитикой, можно только порадоваться.
Или наоборот, обнаружить, что за годы работы предыдущих подрядчиков на сайте стоит 100500 тегов, между собой неструктурированных. Программисты не берутся доделывать сайт после «попередников» – все равно черт ногу сломит, пока что-то исправит в коде.
Что-то похожее почувствовали и мы, когда начали настраивать рекламу для нашего нового клиента :)
С чего всё начиналось
Сначала всё шло нормально, но количество целей, тегов и триггеров только росло. Стало ясно, что «в этом доме пора навести порядок». Так мы начали перенастраивать электронную торговлю Google Tag Manager и Google Analytics Ecommerce Enhanced.
Ecommerce Enhanced – это специальный расширенный модуль Гугл Аналитики для сбора информации о действиях пользователя на сайте, их взаимодействия с товарами и пути к покупке.
Чаще всего самая большая сложность возникает при внедрении в исходный код сайта дополнений. Для настройки Ecommerce Enhanced подключаем разработчиков сайта и человека, который сможет правильно сформировать для него тех. задание. Однако, с последним в целом можно справиться и самостоятельно, для этого Google дает много туториалов и обучающих материалов.
Что мы сделали?
Или чек-лист по настройке электронной торговли GA Ecommerce Enhanced и GTM.
- Разработали техническое задание по интеграции электронной торговли Google Analytics в код страниц сайта.
- Провели инвентаризацию текущей версии EE и диспетчеров тегов сети Google. Описали ошибки, создали список нужных доп. настроек.
- Настроили расширенную электронною торговлю, включая:
- импорт расходов рекламных кампаний Google Ads, Facebook Ads
- настройку отслеживания электронной торговли (оценка продаж, товаров, списков товаров, добавление товара в корзину, удаление, отмененные покупки, шаги к оформлению заказа, совершение покупки)
- перенастройку тегов, триггеров и переменных в GTM, корректировку целей и их описаний
- Создали иерархию пользователей GTM (с разным уровнем доступа).
- Настроили сбор данных для отчета «Анализ поведения при оформлении покупки» по воронке.
- Устранили текущие ошибки кода веб-аналитики и настроили кросс-девайсное отслеживание.
С помощью визуализации структуры GTM мы определили, что в проекте на момент старта проекта работало: 24 встроенных и 60 кастомных переменных, 108 тегов, 88 триггеров, 99 элементов без связей и зависимостей и 21 дубликат.
Оказалось, многие связи дублируют друг друга, что только лишний раз нагружает сайт ненужными процессами. А часть триггеров и тегов вообще находится без каких либо связей. Часто создаются теги и триггеры в тестовых целях, либо в разное время для разных рекламных кампаний. Либо наоборот в контейнере GTM хранится много триггеров, которые не привязаны ни к какому тегу.
Для распутывания «клубка» тегов и триггеров мы использовали специальный инструмент для визуализации связей. Вот как выглядела структура связей до перенастройки:Как видно на рисунке 1, структура версии GTM до перенастройки была очень запутанной.
Визуализация после перенастройки хорошо иллюстрирует упрощение взаимосвязей между всеми элементами GTM – она содержит намного меньше линий. На ней мы могли увидеть для каждого элемента тот элемент, от которого зависит текущий (зеленые линии, рис 2). И тот – для которого текущий является зависимостью (красная линия, рис 2). А ещё мы выявили абсолютные дубликаты и оторванные от структуры элементы (без связей и зависимостей).
Итоговое количество элементов удалось значительно уменьшить, дубли – исключить, а все связи – подчистить.
Выводы
- В больших проектах следует содержать элементы GTM в порядке и по папочкам. Это сильно облегчает управление тегами, особенно когда подрядчиков много.
- Права на публикацию в GTM должны быть только у клиента. Именно аналитик со стороны клиента предотвращает создание дублей, не связанных между собой тегов и прочего. Практика показывает: если подрядчики имеют права публикации версий тегов в GTM, начинается бардак.
- Чем больше элементов(тегов, триггеров, переменных) тем больше ошибок может находиться в проекте, так как один триггер может блокировать работу другого триггера. Аналитика для e-commerce – невероятно важная штука для развития бизнеса, поэтому нужно удалять лишние теги и триггеры, которые не будут использоваться в дальнейшем.
- Введите описания тегов. Так всегда можно понять, что имелось ввиду. Даже если поменяется команда клиента или подрядчика.
- Чтобы избежать искажения статистики, передавайте события с названиями, четко прописанными в ТЗ, и удаляйте старые события
- Передавайте события согласно ТЗ (показ товаров в каталоге, клики по товарам, добавление и удаление товара в корзину, заполнение контактной информации о покупателе), чтобы правильно отображать последовательность шагов к оформлению покупки и отслеживать эффективность внутренней рекламы
Больше всего результатам этого проекта обрадовались РРС-специалисты, у которых, наконец, стали трекаться все конверсии 😉
Ну, а бизнес начал видеть реальные результаты вливаний бюджетов в рекламу. Воронки стали прозрачными, отчетность – легче в подготовке. Как не крути, а аналитика – это как скелет для e-commerce. Можно бесконечно долго качать мышцы путем вливания в проект рекламных бюджетов, но если кости между собой не связаны, такой организм далеко не убежит.