Передача даних з CRM до GA4 через Measurement Protocol з допомогою Server-Side GTM

Прочитавши заголовок матеріалу, ви могли задатись питанням: “А для чого взагалі таке робити?” Чому просто не передати дані по Measurement Protocol одразу до GA4? Навіщо для цього використовувати серверний GTM?

Коротка відповідь така: Як і завжди використання будь-якого Google Tag Manager: чи то клієнтського чи то серверного, дозволяє нам зменшити навантаження на розробника. Більш детальну відповідь ви отримаєте, ознайомившись з матеріалом повністю.

Сьогодні в програмі:

• Передавати дані через Measurement Protocol з допомогою Server-Side GTM - це “костиль” чи ні?
• В чому перевага налаштування Measurement Protocol з допомогою Server-Side GTM в порівнянні з класичним підходом?
• Як налаштувати збір Client ID та Session ID без розробника для подальшого використання через Server-Side GTM
• Як налаштувати передачу даних до GA4 через Measurement Protocol з допомогою Server-Side GTM
• Замість висновку

Передавати дані через Measurement Protocol з допомогою Server-Side GTM це “костиль” чи ні?

Перш ніж розбиратись з рішенням вважаю за правильним одразу пояснити, що такий підхід ні в якому разі не є “костилем”, як комусь може здатись на перший погляд, і в підтвердження своїх слів наведу дві тези:

1. У серверному GTM майже з самої його появи є клієнт Measurement Protocol (GA4). І логічно припустити, якщо такий клієнт є - значить команда Google планувала можливість надсилання запитів Measurement Protocol до серверного менеджера тегів.

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

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

В чому перевага налаштування Measurement Protocol з допомогою Server-Side GTM в порівнянні з класичним підходом?

Тепер, коли ви знаєте, що це рішення — нормальний, продуманий функціонал, — давайте розберемо, у чому ж його перевага. Як я вже писав на початку матеріалу, основна причина — зменшити навантаження на команду розробки. Але де саме відбудеться це «зменшення навантаження»?

Для того, щоб передавати дані по Measurement Protocol, наприклад, з CRM-системи про успішний продаж, зазвичай нам потрібно наступне:

• Зібрати в момент оформлення замовлення на сайті дані про Client ID та Session ID собі в базу чи CRM;
• У момент, коли ми точно впевнені, що замовлення успішне, - передати інформацію про замовлення, включаючи збережені Client ID та Session ID, до GA4.

Всього два пункти. Але якщо з останнім часто CRM мають певний вбудований функціонал, який дозволяє відправляти в потрібні моменти вебхуки в інші сервіси, то для збору та збереження інформації про Client ID та Session ID зазвичай підключають розробника. І в цьому матеріалі ми розберемо, як серверний GTM допоможе закрити нам саме цей перший етап.

Як налаштувати збір Client ID та Session ID без розробника для подальшого використання через Server-Side GTM

Зазвичай ми звикли, що GTM, навіть серверний, - це система, яка в моменті обробляє дані і відправляє їх в інші системи. І збереження даних, особливо ще й так, щоб вони були доступні, коли користувача навіть немає на нашому сайті, могло б бути “питанням із зірочкою”. Саме “могло б”, оскільки вже давно команда GTM запропонувала нам можливість зберігати наші дані одразу з серверного GTM до BigQuery та Firestore. Саме інтеграція з Firestore нам і допоможе в нашому кейсі.

І так, що ж таке Firestore?

Firestore — це NoSQL база даних, яку пропонує Google в рамках Google Cloud Platform (GCP). Її основна перевага в тому, що вона дозволяє швидко зберігати та отримувати дані в реальному часі — без складних налаштувань та підтримки інфраструктури. Тобто саме те, що нам потрібно, щоб розібратись без команди розробки.

З серверного GTM ми можемо виконувати у Firestore як операції запису, так і операції зчитування інформації. Але якщо для останніх є вбудована змінна типу Firestore Lookup, з якою ми познайомимось трохи пізніше, то для запису даних вбудованих рішень немає. Але оскільки сам метод запису доступний через Server-side tagging APIs, то ком'юніті вже давно має готовий тег і для цього випадку. Саме ним ми і скористаємось. Але трохи пізніше.

Перш за все вам необхідно буде створити свій проєкт в GCP, активувати в ньому Firestore та створити першу колекцію. Щоб надати вам повну картину технічної реалізації, ось детальний план, який може бути використаний і як чек-лист. Далі основні пункти будуть розписані детальніше.

• Перейдіть до існуючого проєкту в GCP або створіть новий і оберіть Firestore;
• Створіть потрібну колекцію
• Налаштуйте запис даних про Client ID та Session ID в потрібний момент до колекції Firestore
• Налаштуйте отримання даних про Client ID та Session ID в потрібний момент на стороні Server-side GTM
• Налаштуйте передачу даних по Measurement Protocol з даними транзакції до серверного GTM та збагатіть їх потрібною інформацією, включаючи Client ID та Session ID
• Не забудьте насолодитись результатом ;)

Тепер детальніше про кожен пункт, окрім першого. Я свідомо упускаю процес створення нового проєкту в GCP, оскільки це типова реєстрація в ще одному сервісі, і, думаю, ви зможете пройти її самостійно (тим більше, що дуже часто для налаштування серверного GTM використовується інфраструктура GCP, і, скоріш за все, ви і так з нею знайомі). Тому продовжу я, маючи на увазі, що ви вже на сторінці Firestore.

Створення колекції в Firestore

На екрані ви маєте бачити приблизно такий напис і велику кнопку Create a Firestore database. На неї і натискайте.

На наступному екрані залишаєте все як є.

Звертаю вашу увагу ще раз - на першому екрані ЗАЛИШАЄМО ВСЕ ЯК Є. Навіть Database ID не змінюємо.

Єдине, що за необхідності можна змінити, - це локацію розміщення:

Далі натискаємо Створити, і в результаті ви потрапите до вашої (default) бази. Давайте познайомимось з базовими сутностями Firestore. Для наглядності використовуйте скріншот нижче:

1. Основна сутність - база даних. У нашому випадку вона називається (default)
2. База складається з колекцій, наприклад, це можуть бути колекції orders, sessions, users і т.д.
3. У колекції зберігаються документи. Наприклад, в колекції orders логічно буде зберігати інформацію про замовлення: кожне замовлення буде окремим документом. На скріні ми бачимо відкритий документ 765220.
4. Кожен документ може містити в собі певну інформацію, яка зберігається в базовому вигляді в полях (field).

Тепер коли ви розумієте основні сутності та термінологію - давайте створимо нашу першу колекцію orders. Для цього натисніть на кнопку Start collection.

І в вікні що відкрилось в полі Collection ID вкажіть потрібну назву і натисніть на кнопку Save.

Після цього у вас створиться перша колекція, і навіть з'явиться перший документ, який створиться автоматично. За бажанням можете видалити цей документ чи залишити на згадку. У будь-якому разі він нам більше не знадобиться. А нові документи ми будемо створювати автоматично через Server-side GTM.

Налаштовуємо запис даних про Client ID та Session ID в потрібний момент до колекції Firestore

Перш ніж перейти до практичних дій, зверніть увагу на схему процесу:

1. Перш за все у вас повинна бути налаштована передача даних про оформлення замовлення з сайту до серверного GTM. Звичайний тег події GA4, в моєму випадку назва події new_order, але ви можете назвати як завгодно. Саме з нею в тому числі будуть автоматично передаватись дані про Client ID та Session ID. Єдина особливість - в цьому івенті обов'язково має надсилатись ідентифікатор транзакції. В моєму випадку він передається в параметр new_order_id.

2. Далі нам потрібно зчитати ці дані (Client ID, Session ID та new_order_id) на стороні серверного GTM. Робимо це з допомогою змінної типу Event Data. Нижче налаштування для всіх трьох змінних.

• Client ID

• Session ID

• New_order_id

3. І на останок перейдіть в серверному GTM на вкладку Tags (Теги), оберіть пункт створення нового тегу та знайдіть в галереї ком'юніті шаблон з назвою Firestore Writer:

Далі виконайте наступні налаштування:

1. У полі Firebase Path вкажіть шлях по якому необхідно буде створювати документи orders/{{ED - transaction_id}}

2. Відмітьте пункт Add Timestamp

3. У полях Custom Data вкажіть відповідні змінні для параметрів client_id та session_id

4. Додайте відповідний тригер

Цей тег і буде записувати потрібні нам дані до Firestore, але для того, щоб все спрацювало, нам потрібно надати відповідні дозволи.

За замовчуванням інтеграція серверного GTM з Firestore шукає колекції та документи в тому самому проєкті Google Cloud, на якому запущено сервер GTM (Для цього потрібно, щоб у хмарному сервісі змінна середовища GOOGLE_CLOUD_PROJECT містила ідентифікатор проєкту).

Якщо ж у вас не вказана така змінна або використовуються різні проєкти GCP для Server-side GTM і Firestore, виконайте кроки з цієї інструкції від Simo Ahava.

На цьому етапі важливо перевірити, що серверний GTM може писати дані до Firestore. Перейдіть в режим прев’ю і виконайте дії на сайті, які генерують подію new_order. Якщо все зроблено вірно, у Firestore має з'явитися новий документ, ідентифікатор якого буде дорівнювати ідентифікатору замовлення, і в полях документа має бути три записи: client_id, session_id, timestamp.

Як налаштувати передачу даних до GA4 через Measurement Protocol з допомогою Server-Side GTM

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

• відправку даних з CRM/адмінки сайту на ендпоінт серверного GTM у форматі Measurement Protocol
• клієнт типу Measurement Protocol (GA4) який буде приймати дані
• змінну типу Event Data, щоб розуміти, по якому замовленню шукати інформацію в Firestore
• змінні типу Firestore Lookup, щоб зчитати потрібні дані з Firestore
• трансформацію типу Augment event, щоб додати потрібні технічні дані до події
• тег типу Google Analytics: GA4, щоб направити дані до GA4.

Так, список доволі великий, але загалом нічого складного. Давайте розберемо детальніше кожен крок.

1. Налаштовуємо відправку даних з CRM/адмінки сайту на ендпоінт серверного GTM у форматі Measurement Protocol

Тут фактично потрібно, щоб розробник або ви самостійно налаштували передачу даних з вашої CRM на ендпоінт серверного GTM. Зверніть увагу, вам не потрібно попередньо зберігати будь-яку додаткову інформацію про замовлення, як це потрібно зі звичайним Measurement Protocol.

Тобто достатньо буде наступної інформації в тілі запиту — і вся вона зазвичай вже є у вас в CRM.

2. Тепер, коли ми підготували потрібну інформацію в потрібному вигляді, давайте створимо клієнт типу Measurement Protocol (GA4), який буде приймати дані. Вам потрібно зробити наступні налаштування:

Зверніть увагу на поле Activation Path. Саме значення, яке вказане там, вам потрібно буде використати для формування повного шляху, на який відправляти дані з CRM. Повний шлях має виглядати так:

[Server_container_URL][Activation_Path]?measurement_id=[Measurement_id]&api_secret=[API_secret], де

• [Server_container_URL] - можна знайти в налаштуваннях контейнера серверного GTM
• [Activation_Path] - задається в налаштуваннях клієнта
• [Measurement_id] - ваш ідентифікатор потоку GA4
• [API_secret] - створюється в GA4 за шляхом Admin > Data collection and modification > Data Streams > Events > Measurement Protocol API secrets

У моєму випадку фінальний URL буде виглядати так: https://s.proanalytics.academy/mp/collect?measurement_id=G-69QKQNXXXX&api_secret=cP1HMToaS7yVTOncLV-XXX

Саме на нього ми і відправляємо дані з пункту

3. Наступний крок - створити змінну типу Event Data, щоб розуміти по якому замовленню шукати інформацію в Firestore. У її налаштуваннях просто вкажіть назву параметру, з якого потрібно брати дані:

Цю змінну ми використаємо на наступному кроці, щоб динамічно отримувати інформацію з Firestore.

4. Створюємо змінні типу Firestore Lookup, щоб зчитати потрібні дані з Firestore. Налаштування наступні:

• FL - client_id

• FL - session_id

• FL - timestamp

Як бачите, налаштування досить шаблонні:

• Lookup Type - Document Path
• Document Path - orders/{{ED - transaction_id}}
• Key Path - вказуємо відповідне значення: client_id / session_id / timestamp

5. Тепер створимо тег, типу Google Analytics: GA4, щоб направити дані до GA4. У налаштуваннях нічого особливого, тільки потрібний вам ідентифікатор потоку і назва івенту:

Тригер додаємо типу Custom Event з наступними налаштуваннями:

6. Ну і найцікавіше — наостанок: місце, де буде відбуватись основна “магія” - трансформація типу Augment event, щоб прозоро додати потрібні технічні дані до події. Налаштування будуть наступні:

Пропишіть відповідні змінні з пункту 4 для потрібних ключів client_id, ga_session_id та timestamp_micros.

І зверніть особливу увагу на налаштування в блоці Affected Tags. Для того, щоб ця трансформація не вплинула на інші теги, виберіть пункт Some Tags і далі тег, який ми створили на попередньому пункті.

Ну ось і все. Налаштування завершено. Залишилось дочекатись перших даних в GA4. Якщо ви все зробили успішно - то на вас чекає щось таке:

Замість висновку

Звісно, рішення, описане вище, з першого погляду може здатись не найпростішим з точки зору налаштування, але якщо у вас на проєкті вже налаштована передача даних через Server-side GTM, з його допомогою ви можете значно спростити життя своїм розробникам та пришвидшити процес впровадження передачі даних до GA4 з використанням Measurement Protocol.

Ну і не потрібно забувати, що це рішення досить універсальне. Зберігаючи трішки більше даних в Firestore (наприклад для Meta значення з кук _fbp та _fbc), ви можете відправити по схожій логіці дані про реальні продажі до рекламних кабінетів, наприклад, Meta чи TikTok, використовуючи Conversion API.

Це рішення, як і багато інших з цього блогу, показує, що GTM в правильних руках може значно впливати на якість вашого трекінгу і значно економити час девелопер команди. Ну а якщо вам поки це все дається трохи складно - долучайтесь до моїх курсів Server-side GTM Basics та PRO GTM, і я навчу вас спілкуватись з GTM на “ти”.