Как распутать нераспутываемое: настройка электронной торговли ecommerce проекта

Когда к агентству в работу попадает большой 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 хранится много триггеров, которые не привязаны ни к какому тегу.

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

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

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

Выводы

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

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

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