Пошук рішення для e-commerce відстеження в Google Ads

1. Огляд проєкту

Наш клієнт — мережа закладів харчування в Києві, з кількома філіями в центрі міста. Заклад пропонує клієнтам не лише можливість поїсти на місці, але й кілька варіантів доставки їжі по Києву через популярні сервіси, такі як Glovo, Bolt, а також власну службу доставки. Для зручності клієнтів також доступна опція самовивозу їжі.

Клієнт звернувся до нас для покращення онлайн-продажів та збільшення кількості замовлень через сайт. Основною метою було запустити рекламне просування в Google Ads, щоб залучити нових клієнтів і стимулювати поточних до частішого використання онлайн-сервісу для замовлень. 

Сайт був створений на популярній спеціалізованій для закладів харчування платформі, яка надає інструменти для управління контентом та інтеграцією з різними онлайн-сервісами. Крім того, система платформи дозволяє зручно відстежувати замовлення, керувати філіями та отримувати аналітичні дані, що забезпечує прозорість і ефективність в управлінні бізнесом. Також платформа надає можливість налаштувати коректне відслідковування конверсій, що є ключовим елементом для успішного рекламного просування. Вона дозволяє підключити Google Tag Manager (GTM) через панель керування та інтегрувати ID Google Analytics 4 (GA4) безпосередньо в налаштуваннях.

Оскільки ми вже мали досвід роботи з цією платформою, ми були впевнені, що з відслідковуванням замовлень не буде проблем.

2. Визначення викликів

Після отримання доступів до облікових записів, ми перевірили налаштування у панелі керування, і все виглядало коректно. В налаштуваннях були прописані GTM та GA4, що дозволяло передавати дані в аналітику. Однак, незважаючи на правильне налаштування, ми помітили, що дані не передавались до аналітики.

При проведенні тестових транзакцій ми бачили, що потрібні дані на відповідних етапах замовлення (наприклад, view_item, add_to_cart тощо) пушились в DataLayer, але самі події не фіксувались і не передавались в GA4. Така ситуація вимагала подальшого розслідування причин і пошуку рішення для правильного налаштування передачі даних в GA4.

3. Реалізація

Ми припустили, що проблема з відсутністю подій у GA4 може бути пов'язана з налаштуваннями контейнера в Google Tag Manager (GTM). Оскільки доступів до актуального GTM не було, ми не мали змоги перевірити, що і як в ньому налаштовано. То ж для перевірки цієї гіпотези ми створили новий контейнер, підключили через нього GA4 і налаштували відстеження подій. Результат показав, що всі етапи ecom-воронки коректно фіксуються та передаються в GA4. Однак, при тестуванні події purchase під час оформлення транзакції, ми виявили, що вона не передавалась в GA4 і не відображалась у реальному часі, хоча в адмін-панелі платформи ми бачили тестове замовлення.

Ми звернулись до служби підтримки платформи для детальнішого розслідування. З’ясувалося, що проблема була на стороні налаштувань платформи, і після виправлень дані про оформлені замовлення почали відображатися в GA4. Проте кількість покупок, що фіксувалася в аналітиці, була значно нижчою в порівнянні з адмін-панеллю платформи — різниця складала майже вдвічі.

Щоб вирішити це, ми повторно звернулись до технічної підтримки платформи. Тим часом ми вирішили розпочати рекламне просування, орієнтуючись на мікроконверсії та вже доступні конверсії, не чекаючи повного вирішення питання з фіксацією покупки.

Імпорт конверсій в Google Ads з GA4

Ми імпортували всі події електронної комерції в кабінет та запустили рекламні кампанії. Однак після старту стало очевидно, що ecommerce-події не передаються з аналітики в кабінет. Водночас додаткові конверсії, такі як перехід з головної сторінки сайту на сторінку філії, в кабінеті відображалися.

Таким чином, проблема розділилась на два основних напрямки: перший — не всі конверсії потрапляли в аналітику, і другий — навіть ті події електронної торгівлі, які потрапляли в аналітику, не передавалися в рекламний кабінет як конверсії.

Створення нового кабінету Google Ads

Ми детально перевірили налаштування аналітики, кабінету, тегів та utm-міток, переконавшись, що всі необхідні параметри були встановлені коректно. Оскільки самостійно не вдалося виявити очевидних помилок, ми звернулися до служби підтримки Google, сподіваючись на детальну консультацію. Однак відповідь, яку ми отримали, не допомогла вирішити проблему, оскільки служба підтримки лише порадила ознайомитись із довідковими матеріалами. Це залишило нас без чіткої відповіді та змусило діяти далі самостійно.

Наше припущення полягало в тому, що проблема може бути пов'язана з технічним збоєм при зв'язуванні аналітики з обліковим записом. Тому ми створили новий кабінет, з нуля налаштували всі зв'язки та параметри, проте це не призвело до вирішення проблеми — передача e-commerce подій все одно не працювала належним чином.

Налаштування відстежень за допомогою Google Tag

Після цього ми вирішили протестувати альтернативний варіант — налаштували передачу даних про e-commerce події безпосередньо через тег Google Ads, минаючи аналітику. Це дозволило перевірити, чи можливо отримувати хоча б часткові дані напряму в рекламний кабінет без участі GA4.

Результати тесту показали, що події дійсно почали надходити до кабінету Google Ads, однак їх обсяг був неповним. Частина e-commerce подій фіксувалась, але загальна кількість конверсій не відповідала фактичній активності користувачів. Це дозволило зробити висновок, що хоча в нашому випадку передача через тег AW може частково вирішити проблему, вона не є повноцінною заміною інтеграції з аналітикою.

 

Створення нової аналітики GA4

Наступний крок полягав у припущенні, що проблема може бути в збої самої аналітики. Ми вирішили створити новий обліковий запис у Google Analytics і налаштувати все заново. Однак і це не дало позитивного результату, і проблема залишалась невирішеною.

При цьому, як в адмін-панелі платформи, так і в GA4 ми бачили, що з каналу платного трафіку були конверсії і навіть бачили з якої конкретно рекламної кампанії. (скрін 4)

Таким чином, навіть якщо б служба підтримки успішно вирішила проблему з точною передачею даних до аналітики, це не вирішувало нашу головну задачу — дані повинні були передаватися саме в кабінет для подальшого аналізу та використання в рекламних кампаніях. 

Реалізація імпорту конверсій з кліків

Оскільки проблема полягала саме в передачі еком-подій з аналітики до кабінету, ми звернулись до служби підтримки платформи з новим запитом, щоб дізнатися, чи є можливість налаштувати фіксацію gclid та завантаження конверсій для їхнього подальшого імпорту в кабінет.

На той момент, така можливість в системі була відсутня. Однак, після детального обговорення нашої ситуації, служба підтримки погодилась реалізувати цей функціонал. Вони підтвердили, що зможуть розробити та впровадити механізм для автоматичного збору даних і їхньої подальшої передачі в кабінет, що значно полегшило б наш процес роботи з конверсіями.

Після того, як ми отримали повідомлення, що функція вигрузки даних була реалізована, ми виконали першу вигрузку, але виявили, що файл пустий. Після проведення розслідування, служба підтримки платформи з’ясувала, що проблема полягала в тому, що реклама вела на головну сторінку сайту, де були розміщені посилання на філії. І при переході з головної сторінки на сторінку конкретної філії gclid (ідентифікатор кліку) обрізався, і таким чином не передавався далі на наступну сторінку.

Обрізання gclid стало проблемою, оскільки цей ідентифікатор є важливим для зв’язку між рекламним кліком і подальшими подіями. Після виправлення цієї проблеми дані почали коректно вигружатись. Нарешті, через два місяці від початку роботи над проєктом, ми побачили перші покупки в кабінеті.

Передача даних в кабінет з аналітики

Однак, вже на наступний день після виправлення проблеми з обрізанням gclid, ми помітили, що не лише почали коректно вигружатись дані в документ, а й e-commerce події почали з’являтись в кабінеті: система змогла коректно зв'язувати рекламний клік з подальшими діями користувача на сайті.

Одночасно з цим служба підтримки платформи з’ясувала в чому конкретно полягає причина неточної передачі даних про покупки в аналітику і поставила в план робіт це виправити.

4. Висновки

1. Не завжди проблема полягає в налаштуваннях аналітики або кабінету.
   В даному випадку, хоча ми спочатку зосередились на перевірці налаштувань аналітики та кабінету, проблема виявилась зовсім в іншій області. Обрізання gclid при переході з головної сторінки на сторінку філії стало причиною того, що дані не фіксувались і не передавались коректно. Це підкреслює важливість комплексного підходу до пошуку і вирішення проблем, оскільки неполадки можуть бути пов'язані з різними етапами і технологічними аспектами, які на перший погляд можуть залишатись непоміченими.
   
2. Не завжди проблему можна вирішити швидко.  Незважаючи на те, що ми доклали значних зусиль для налаштування та перевірки всіх етапів, процес пошуку і вирішення проблеми не був миттєвим. Проблема вимагала не тільки детального аналізу, але й взаємодії з технічною підтримкою платформи. І, хоча, після виправлення, ситуація почала налагоджуватись, все ж варто зазначити, що такий процес може зайняти значний час, особливо коли йдеться про технічні питання, що потребують детального розслідування.
   
3. Тісна співпраця дає результат.  У даному випадку тісна взаємодія між командою підрядника, клієнтом та технічною підтримкою платформи була вирішальною для знаходження та усунення проблеми. Постійне обговорення, надання доступів і зворотний зв'язок дозволили швидше і точніше ідентифікувати проблему та ефективно її вирішити. Така співпраця є критично важливою для забезпечення успіху у вирішенні складних задач.
   
4. Необхідність у взаємодії між підрядником і командою підтримки також відкриває нові можливості для покращення продукту. У нашому випадку, після того як ми звернулись до підтримки з питанням про можливість фіксації Gclid, була реалізована нова функція, яка дозволила нам вивести дані про конверсії для подальшого імпорту в кабінет. Це не тільки дозволило вирішити нашу проблему, але й стало основою для покращення функціональності платформи для інших користувачів. Крім того, командою платформи була виявлена причина неточної передачі даних про покупки в аналітику, яка найближчим часом буде вирішена.
   

Таким чином, цей кейс демонструє важливість комплексного підходу, готовності до співпраці та терпіння в процесі вирішення технічних проблем.