Читайте наши статьи первыми

Когда к агентству в работу попадает большой e-commerce проект с уже настроенной аналитикой, можно только порадоваться.

Или наоборот, обнаружить, что за годы работы предыдущих подрядчиков на сайте стоит 100500 тегов, между собой неструктурированных. Программисты не берутся доделывать сайт после «попередников» – все равно черт ногу сломит, пока что-то исправит в коде.

Что-то похожее почувствовали и мы, когда начали настраивать рекламу для нашего нового клиента 🙂

С чего всё начиналось

Сначала всё шло нормально, но количество целей, тегов и триггеров только росло. Стало ясно, что «в этом доме пора навести порядок». Так мы начали перенастраивать электронную торговлю Google Tag Manager и Google Analytics Ecommerce Enhanced.

Ecommerce Enhanced – это специальный расширенный модуль Гугл Аналитики для сбора информации о действиях пользователя на сайте, их взаимодействия с товарами и пути к покупке.

Чаще всего самая большая сложность возникает при внедрении в исходный код сайта дополнений. Для настройки Ecommerce Enhanced подключаем разработчиков сайта и человека, который сможет правильно сформировать для него тех. задание. Однако, с последним в целом можно справиться и самостоятельно, для этого Google дает много туториалов и обучающих материалов.

Что мы сделали?

Или чек-лист по настройке электронной торговли GA Ecommerce Enhanced и GTM.

  1. Разработали техническое задание по интеграции электронной торговли Google Analytics в код страниц сайта.
  2. Провели инвентаризацию текущей версии EE и диспетчеров тегов сети Google. Описали ошибки, создали список нужных доп. настроек.
  3. Настроили расширенную электронною торговлю, включая:
    • импорт расходов рекламных кампаний Google Ads, Facebook Ads
    • настройку отслеживания электронной торговли (оценка продаж, товаров, списков товаров, добавление товара в корзину, удаление, отмененные покупки, шаги к оформлению заказа, совершение покупки)
    • перенастройку тегов, триггеров и переменных в GTM, корректировку целей и их описаний
  4. Создали иерархию пользователей GTM (с разным уровнем доступа).
  5. Настроили сбор данных для отчета «Анализ поведения при оформлении покупки» по воронке.
  6. Устранили текущие ошибки кода веб-аналитики и настроили кросс-девайсное отслеживание.

С помощью визуализации структуры GTM мы определили, что в проекте на момент старта проекта работало: 24 встроенных и 60 кастомных переменных, 108 тегов, 88 триггеров, 99 элементов без связей и зависимостей и 21 дубликат.

Оказалось, многие связи дублируют друг друга, что только лишний раз нагружает сайт ненужными процессами. А часть триггеров и тегов вообще находится без каких либо связей. Часто создаются теги и триггеры в тестовых целях, либо в разное время для разных рекламных кампаний. Либо наоборот в контейнере GTM хранится много триггеров, которые не привязаны ни к какому тегу.

Для распутывания «клубка» тегов и триггеров мы использовали специальный инструмент для визуализации связей. Вот как выглядела структура связей до перенастройки:структура версии GTM до перенастройки была очень запутаннойКак видно на рисунке 1, структура версии GTM до перенастройки была очень запутанной.  структура версии GTM после перенастройки

Визуализация после перенастройки хорошо иллюстрирует упрощение взаимосвязей между всеми элементами GTM – она содержит намного меньше линий. На ней мы могли увидеть для каждого элемента тот элемент, от которого зависит текущий (зеленые линии, рис 2). И тот – для которого текущий является зависимостью (красная линия, рис 2). А ещё мы выявили абсолютные дубликаты и оторванные от структуры элементы (без связей и зависимостей).

Итоговое количество элементов удалось значительно уменьшить, дубли – исключить, а все связи – подчистить.

структура GTM

Выводы

  1. В больших проектах следует содержать элементы GTM в порядке и по папочкам. Это сильно облегчает управление тегами, особенно когда подрядчиков много.
  2. Права на публикацию в GTM должны быть только у клиента. Именно аналитик со стороны клиента предотвращает создание дублей, не связанных между собой тегов и прочего. Практика показывает: если подрядчики имеют права публикации версий тегов в GTM, начинается бардак.
  3. Чем больше элементов(тегов, триггеров, переменных) тем больше ошибок может находиться в проекте, так как один триггер может блокировать работу другого триггера. Аналитика для e-commerce – невероятно важная штука для развития бизнеса, поэтому нужно удалять лишние теги и триггеры, которые не будут использоваться в дальнейшем.
  4. Введите описания тегов. Так всегда можно понять, что имелось ввиду. Даже если поменяется команда клиента или подрядчика.
  5. Чтобы избежать искажения статистики, передавайте события с названиями, четко прописанными в ТЗ, и удаляйте старые события
  6. Передавайте события согласно ТЗ (показ товаров в каталоге, клики по товарам, добавление и удаление товара в корзину, заполнение контактной информации о покупателе), чтобы правильно отображать последовательность шагов к оформлению покупки и отслеживать эффективность внутренней рекламы

Больше всего результатам этого проекта обрадовались РРС-специалисты, у которых, наконец, стали трекаться все конверсии 😉

Ну, а бизнес начал видеть реальные результаты вливаний бюджетов в рекламу. Воронки стали прозрачными, отчетность – легче в подготовке. Как не крути, а аналитика – это как скелет для e-commerce. Можно бесконечно долго качать мышцы путем вливания в проект рекламных бюджетов, но если кости между собой не связаны, такой организм далеко не убежит.