Як створити data layer для server-side Google Tag Manager

Механізми захисту від відстеження браузера стають надійнішими, деякі браузери блокують сторонні файли cookie, Chrome планує поступово відмовитися від сторонніх файлів cookie до 2022 року, Apple запровадила обмеження на відстеження для користувачів iOS. Усі ці зміни торкнулися веб-аналітики.

Раніше ми вважали відстеження веб-сайтів front-end, але з усіма новими обмеженнями відстеження веб-сайтів стає все складнішим. Деякі кажуть, що відстеження на стороні сервера стане новим стандартом.

Одним із найпростіших і найдешевших способів застосування тегів ss є використання серверного Google Tag Manager. Після того, як ви налаштуєте хостинг sGTM, наступне питання полягатиме в тому, як доставити дані на серверний GTM. Вам потрібно створити data layer, схожий на веб-контейнер, чи є інший спосіб?

У цьому блозі я хочу обговорити створення data layer для серверного Google Tag Manager.

В web Google Tag Manager дані збираються на стороні клієнта. Ви використовуєте елементи DOM або витягуєте дані із сайту за допомогою селекторів CSS. Але в деяких випадках ці методи можуть бути нестійкими.

Золоте правило веб-відстеження GTM – це створення надійного рівня даних (data layer). Створення належної структури рівня даних та впровадження її на веб-сайт займає деякий час не тільки для маркетологів, але й для розробників. Але це варте часу. За допомогою рівня даних ви отримуєте більше даних, і ці дані є надійними.

До GTM на стороні сервера додано новий об’єкт; це називається Клієнт. Основною метою Клієнта є перетворення даних запиту в дані про події всередині GTM сервера.

Як Клієнт розуміє, який запит вимагати та обробляти? Він перевіряє шлях запиту. Наприклад, Universal analytics надсилає запити, які містять /collect. Клієнт переглядає шлях вхідних запитів HTTP, і якщо шлях запиту має свій «ключ», Клієнт перетворює дані запиту в дані події в sGTM.

Іншою важливою метою клієнтів sGTM є обробка вихідних запитів HTTP. Після того, як тег запускається в sGTM, Клієнт надсилає вихідний запит HTTP, щоб підсумувати всі запити, надіслані кожним тегом. Якщо з тегом сталася помилка, ви побачите причину помилки, якщо клацнете вихідний запит HTTP і прокрутіть вниз до response body.

Дозвольте показати приклад. Я буду використовувати для цього тег даних/клієнт даних. У веб-контейнері GTM я налаштував тег даних, який надсилає запити до серверного контейнера.

Шлях запитів тегу даних містить /data.

У sGTM у мене є клієнт даних, який слухає всі запити, які містять /data у вхідному запиті HTTP.

У GTM на стороні сервера є два теги (GA4 і Klaviyo, активні на сайті), які запускаються щоразу, коли запитується клієнт Data Client, а ім’я події – page_vew. Давайте подивимося, що відбувається в GTM на сервері, коли він отримує вхідний запит з /data та ім’ям події page_view. Обидва теги запускаються, і клієнт даних надсилає вихідний запит HTTP.

Якщо ви клацнете на Вхідні запити HTTP, ви побачите, які дані були надіслані в серверний контейнер. Якщо ви натиснете на вихідний запит HTTP, ви побачите, яку інформацію надіслав клієнт даних про виконання ініційованих тегів.

Коли ви клацнете на даних події, ви побачите, яку інформацію з вхідних запитів HTTP Data Client зіставив із даними події.

Рівень даних не існує в server Google Tag Manager так, як ми його використовували у web Google Tag Manager. Зазвичай ви створюєте теги в sGTM на основі даних про події та запитуваних даних.

Швидше за все, ми не зможемо перейти на відстеження на стороні сервера лише в найближчі пару років. Тим часом буде використовуватися гібридний підхід – поєднання веб-відстеження та серверного відстеження. Деякі теги все ще працюватимуть на стороні клієнта (або тому, що платформи ще не підтримують відстеження ss, або просто тому, що їх не можна перемістити до ss, вони стосуються таких інструментів, як HotJar), ​​а інші теги будуть налаштовані на на стороні сервера. Буде один тег/клієнт, відповідальний за надсилання конкретних даних або всього рівня даних з веб на серверний контейнер GTM.

На схемі нижче показано, як працює процес доставки даних до sGTM. Web GTM має рівень даних, веб-відстеження використання пікселів UA та FB. Тоді у нас є тег GA4 на стороні сервера, який відповідає за доставку даних із веб- до серверного GTM. На основі тегу даних GA4, наданого sGTM, ми можемо налаштувати теги ss Adwords і FB CAPI на сервері GTM.

Для мене два найбільш часто використовувані методи надсилання даних з веб на серверний GTM є:

• Використання Google Analytics 4
• Використання тегу даних/клієнта даних

1. Надішліть рівень даних на серверний GTM за допомогою Google Analytics 4.

Ви можете надсилати властивості користувача та параметри подій з веб на сервер GTM за допомогою GA4. Усередині веб-тегу GA4 ви побачите попередньо визначені поля для цих даних, і ви можете додати змінні рівня даних до кожного параметра окремо.

Google Analytics 4 і UA мають різні стандарти рівня даних електронної комерції (рівень даних UA, рівень даних GA4). Тому, якщо у вас є рівень даних ee на сайті, створений для UA, обов’язково змініть його для GA4. Добре те, що ви можете використовувати змінні в галереї шаблонів GTM, які перетворюють події та змінні UA до стандартів GA4.

Цей варіант найкраще працює, якщо ви плануєте налаштувати відстеження на стороні сервера для Google Ads або Floodlight, оскільки вони працюють лише на основі тегів GA4.

2. Використовуйте тег даних/клієнт даних для надсилання рівня даних із веб- до серверного GTM.

Найважливіша перевага використання тегу даних/клієнта даних полягає в тому, що DT автоматично надсилає рівень даних та інші загальні дані з веб на сервер GTM. Якщо ввімкнути два прапорці «Надіслати загальні дані» та «Надіслати все з DataLayer», він аналізуватиме дані у веб-мережі GTM та надсилатиме всю інформацію, яку може знайти, на сервер GTM. Немає необхідності налаштовувати кожен параметр вручну.

Ось як ви побачите дані eCommerce в sGTM. Ви можете використовувати змінну даних події (event data variable), щоб витягти її та використовувати для тегів сервера, і у мене є більш детальна публікація, яка описує тег даних/клієнт даних.

Server GTM container не має нічого схожого на рівень даних, який ми використовували у веб-контейнері. Але є кілька способів передачі параметрів події та користувача або події всього рівня даних із веб на серверний Google Tag Manager.