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