How to plug what you can't plug: setting up e-commerce e-commerce projects

З чого все починалося

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