Читайте наші статті першими

Коли до агентства в роботу потрапляє великий 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. Можна нескінченно довго качати м’язи шляхом вливання в проект рекламних бюджетів, але якщо кістки між собою не пов’язані, такий організм далеко не втече.