Створення кастомної CDP та збагачення даних подій за допомогою серверного GTM

Перш ніж здійснити покупку, клієнти взаємодіють із брендами через різні канали — як онлайн, так і офлайн. Через це маркетологам та аналітикам буває складно відстежувати всі взаємодії в одному місці. Стандартні інструменти, такі як Google Analytics або серверний трекінг Matomo, часто не здатні відстежувати офлайн-події. Для розв'язання цієї проблеми зазвичай використовують платформи клієнтських даних (CDP). 

Один зі способів використовувати CDP — придбати готовий інструмент, що може бути досить дорого. Інший варіант — створити власну CDP. У цій статті ми покажемо, як побудувати просту версію CDP за допомогою серверного Google Tag Manager та бази даних. 

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

Серверний контейнер Google Tag Manager отримуватиме запити про всі взаємодії користувачів — як онлайн, так і офлайн. Ви можете використовувати стандартні клієнти, як-от GA4 або Data Client, для отримання онлайн-подій із вебконтейнера GTM. Для отримання офлайн-подій можна застосовувати вебхуки. Далі в статті я покажу, як надсилати та налагоджувати дані вебхуків усередині sGTM.

Незалежно від типу даних, які отримує sGTM, він зберігатиме їх у базі даних. Є кілька баз даних, з якими можна інтегрувати sGTM, наприклад, Firebase, Supabase (значно дешевша за Firestore) або Data Store. Тут я використовуватиму Stape Data Store, оскільки це вбудована функціональність у Stape, яка є безкоштовною для платних користувачів Stape (плани Pro та вище).

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

1. Джерело даних (CRM, SDK, CMS, мобільний додаток, вебсайт тощо).

2. Серверний контейнер GTM.

3. База даних (у цьому гайді я використовуватиму Data Store. Ви також можете застосувати Firestore або Supabase, для якої Stape створив тег Supabase writer).

4. Для читання та запису даних із бази даних можна використовувати такі шаблони sGTM:

• Тег Stape Store writer
• Змінна Stape Store lookup
• Змінна Stape reStore
• Тег Firestore Writer (якщо ви використовуєте Firestore)
• Змінна Firestore reStore
• Тег Supabase Writer (якщо ви використовуєте Supabase)
• Змінна Supabase Lookup

5. Унікальні ідентифікатори користувачів. У цьому гайді я використовуватиму унікальний User ID або WordPress User ID, який генерує плагін Stape для WordPress. 

Ось як дані користувача передаються з джерела даних (CRM) до CDP:

1. 1.
   Щоразу, коли користувач здійснює покупку, CRM надсилає вебхук до sGTM. 
2. 2.
   Data Client у sGTM обробляє вхідний запит та узгоджує його з форматом sGTM. 
3. 3.
   У серверному контейнері GTM ми використовуємо змінну reStore, щоб визначити, чи існує користувач, який здійснив покупку, у базі даних. Якщо користувач існує, ми перевіряємо, чи містить запит нову інформацію про нього, і об'єднуємо актуальні дані з тими, що вже є в базі даних. Після цього записуємо збагачену інформацію. Якщо користувача ще немає, просто створюємо новий запис клієнта. 
4. 4.
   Об'єднання даних користувача з вхідного запиту з даними в базі. Наприклад, якщо параметр міста відсутній у вебхуку CRM і відповідного поля немає, це поле буде взято зі Store. Якщо вхідний запит містить поле міста, але у Store воно відсутнє або відрізняється, дані для цього поля з запиту будуть записані у сховище.
5. 5.
   Використання повного профілю клієнта для надсилання вендору через з'єднання server-to-server.

1. 1.
   Вебсайт. Два найпопулярніші способи передачі даних із вебсайту до sGTM — це налаштування серверного GA4 та Data Tag.
2. 2.
   Вебхуки CRM (Hubspot, Salesforce, Jira тощо).
3. 3.
   CMS. Ви можете використовувати плагіни для серверного трекінгу Shopify, WordPress або Magento 2 Google Tag Manager, щоб надсилати вебхуки про повернення коштів і покупки до sGTM.
4. 4.
   SDK та мобільний додаток. Stape створив iOS, Android, PHP SDK та Node.js SDK.
5. 5.
   Платіжні системи (Stripe, Braintree тощо).

Спосіб отримання даних залежить від того, як ви надсилаєте їх до sGTM. Ось три варіанти отримання даних:

1. 1.
   Клієнт GA4. Працює, якщо ви використовуєте GA4 для передачі даних до sGTM.
2. 2.
   Клієнт Measurement Protocol. Його можна використовувати для контролю типу запитів, що надсилаються до sGTM, приводячи їх до стандарту Measurement Protocol. Зазвичай це код вашого додатка.
3. 3.
   Data Client. Підходить для випадків, коли ви не контролюєте вхідні запити, оскільки в Data Client можна змінювати шлях запиту, як-от для вебхука Stripe.

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

Для ідентифікованих користувачів можна використовувати email або внутрішній ID, придатний для використання в різних системах. Якщо користувач не ідентифікований, це може бути Stape User ID, що складається з хешу таких параметрів:

• IP клієнта (IPv4/IPv6)
• User-Agent браузера
• Налаштування TLS браузера
• Ім'я хоста (Hostname)

Якщо ваш бренд працює на кількох доменах, ви також можете увімкнути опцію Cross-domain ID у покращенні User ID. Вона генерує додатковий ID (X-Stape-Cross-Domain-Id) на основі тих самих сигналів, але без імені хоста, тому один і той самий неідентифікований користувач отримує єдиний ID на всіх ваших доменах, підключених до серверного контейнера. Це допомагає уникнути дублювання профілів у вашій CDP.

Якщо з міркувань конфіденційності ви хочете зробити свій User ID ще більш унікальним, можна додати залежну змінну. Це може бути день, місяць, тиждень або рік. Усе залежить від того, наскільки унікальним має бути ID. 

Ми використовуватимемо змінну reStore або тег Stape Store Writer та Stape Store Lookup для об'єднання та зшивання профілів користувачів із запитів і бази даних. Копії цих шаблонів також доступні на GitHub Stape.

Призначення тегу запису (Writer tag) та змінних пошуку (Lookup variables) є цілком зрозумілим. Ці два шаблони дозволяють записувати та зчитувати дані з Data Store. 

Змінна reStore спершу визначає, чи існує користувач у базі даних. Спочатку змінна отримує всі ідентифікатори користувача з нашої події (email, телефон або Client ID). Потім вона надсилає запит до Store для вибору клієнтів, які мають один із таких ідентифікаторів. Якщо інформація про клієнта є в базі даних, вона поверне дані про нього.

Коли змінна отримує відповідь від Store, вона об'єднує її з вхідним запитом. Наприклад, якщо поле city відсутнє, буде використано це поле зі Store. Якщо у вхідних запитах є поле city, але в Store його немає або воно відрізняється, тоді дані із запиту для цього поля будуть записані в store. Ця змінна створює нову сутність, якщо клієнта частково знайдено в store.

Після того як дані в sGTM оброблено та відформатовано у формат sGTM, ви можете використовувати їх для надсилання будь-якому потрібному сервісу, такому як Meta, TikTok, Google Ads або Analytics. Звертайте увагу на дані користувачів, які надсилаються в запитах. 

Налагодження в sGTM — непросте завдання, а з офлайн-подіями все може бути ще складніше. Ми розглянемо, як використовувати наступні інструменти:

• дебагер sGTM
• Логи Access/Request/Response у Stape
• Тег Logger
• sGTM Preview Header

Я наведу два приклади використання, щоб продемонструвати можливості Data Store. Ми з'ясували, що це найпопулярніші сценарії серед клієнтів Stape.

1. Налаштуйте User ID. Я використовуватиму покращення Stape User ID, яке допоможе об'єднати користувачів із клієнтами.

a. Увійдіть у свій акаунт Stape та ввімкніть покращення. Для цього відкрийте контейнер sGTM, перейдіть на вкладку Power-ups, відкрийте User ID, перемкніть тумблер і збережіть.

b. У серверному контейнері GTM створіть змінну, яка отримуватиме User ID із заголовків запиту на сервері.

2. Запишіть дані в базу даних під час події purchase. Переконайтеся, що ви додаєте Stape User ID до даних події. 

a. Додайте тег Stape store writer до галереї шаблонів sGTM (завантажте його з GitHub та імпортуйте в розділ шаблонів тегів sGTM) і створіть тег для запису даних події під час події purchase. Я записую всі дані події та додаю Stape User ID до запису в сховищі. Це знадобиться для об'єднання користувачів під час події pageview.

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

3. Збагатіть дані події pageview даними, збереженими у сховищі даних.

a. Щоб об'єднати користувачів із події pageview та тих, які збережені в базі даних, ми знову використаємо Stape User ID та змінну Stape Store Lookup, яка може отримувати дані зі сховища. Додайте змінну Stape Store Lookup до галереї шаблонів змінних sGTM. Щоб завантажити шаблон із GitHub, перейдіть до розділу шаблонів sGTM. Натисніть New у розділі змінних, а потім Import.

b. Створіть змінну Stape Store Lookup для параметрів, які ви хочете відновити: додайте document path та path name. 

c. Додайте змінну Lookup до тегу pageview. 

4. Протестуйте налаштування. Ви маєте побачити збагачені дані користувача в тегу, що спрацював у контейнері sGTM. 

У цьому сценарії використання я хочу надсилати дані офлайн-подій до рекламної мережі. Під час надсилання даних про конверсії на платформу рекламодавця критично важливим елементом є надсилання click ID. Click ID — це ідентифікатор, який додається до URL-адреси або cookies, коли користувач переходить за рекламним посиланням. За допомогою Click ID рекламна мережа може легко атрибутувати конверсію до рекламної кампанії. 

Click ID доступні для всіх вебподій, але якщо ви хочете надсилати дані про конверсії з CRM або CMS до рекламної мережі, у більшості випадків Click ID недоступні.

Щоб налаштувати цю опцію, я використаю змінну відновлення Stape, щоб записувати дані в Data Store під час перегляду сторінки та відновлювати їх під час подій покупки. Крім того, мені знадобиться трансформація в контейнері sGTM для збагачення події, яка надсилається у Facebook. Ще один критично важливий елемент — зіставлення користувачів у подіях перегляду сторінки з користувачами у вебхуках офлайн-покупок. Для цього необхідно використовувати ідентифікатор користувача, який залишатиметься незмінним як для вебподій перегляду сторінки, так і для офлайн-покупок. 

У стандартних CMS цього легко досягти, оскільки вони зазвичай зберігають такий ідентифікатор у cookies. Для клієнтських вебсайтів вам потрібно буде попросити розробників додати ці параметри. Моє налаштування виконано на сайті WordPress. Плагін Stape для WordPress надсилає унікальний User ID у вебподіях і додає його до вебхука. За допомогою цього User ID я можу зіставляти користувачів із переглядів сторінок і вебхуків покупок у базі даних. 

1. Отримайте вебхук покупки з офлайн-джерела даних у sGTM. 

a. Надішліть вебхук із CRM. Для цього я використаю додаток Stape для WordPress. Перейдіть на вкладку Webhooks і додайте URL-адресу контейнера Server GTM. Це домен, який ви використовуєте для вашого серверного контейнера GTM. Ми рекомендуємо налаштувати кастомний домен у межах домену вашого вебсайту, оскільки це дозволить встановлювати 1st party cookies. Не забудьте встановити прапорці. 

b. Додайте Data Client до шаблонів клієнтів sGTM і налаштуйте його на отримання вебхуків, які ви надсилаєте з CRM. Для цього створіть шаблон Data Client і додайте Webhook path.

c. Налаштуйте паверап Preview Header config для sGTM на Stape, щоб налагоджувати вхідні вебхуки в sGTM. Перейдіть у режим попереднього перегляду sGTM, натисніть на три крапки у правому верхньому куті та виберіть send requests manually. Скопіюйте HTTP-заголовок X-Gtm-Server-Preview і вставте його в паверап Preview Header config для sGTM.

d. Відкрийте налагоджувач sGTM і перевірте, чи отримав він вебхуки. Щойно вебхук спрацює, ви маєте побачити вхідний запит усередині sGTM і те, що Data Client перехопив цей запит.

2. Запишіть параметри fbc, fbp і client ID для події pageviews до бази даних.

На цьому кроці я покажу, як записати параметри fbc і fbp до бази даних за допомогою змінної reStore. Для цього ми використаємо тег Facebook pageview для запуску подій pageview і трансформацію, яка записуватиме дані до сховища за допомогою змінної reStore.

a. Додайте змінну reStore до змінних sGTM за цим посиланням. Вам потрібно буде завантажити її з GitHub, створити новий шаблон змінної в sGTM і натиснути Import.

b. Налаштуйте змінну reStore. Вона має використовувати WordPress User ID як ідентифікатор і записувати fbp, fbc та WordPress User ID до сховища.

c. Створіть трансформацію, яка збагачуватиме дані подій для подій Facebook pageview за допомогою змінної reStore, і додайте цю трансформацію до вашого тегу FB pageview.

d. Протестуйте налаштування. Якщо все налаштовано правильно, ви маєте побачити дані, записані в Data Store. 

e. Налаштуйте подію Facebook purchase, яка спрацьовуватиме щоразу після отримання вебхука. Щоб доповнити цю подію даними з Data Store, нам знадобиться трансформація та та сама змінна відновлення, яку ми використовували для трансформації події FB pageview. Це дозволить витягти потрібний параметр для події purchase. Але щоб надіслати дані у форматі, який розпізнає Facebook, нам знадобиться змінна object extractor, що витягує потрібний об'єкт зі змінної відновлення.

f. Протестуйте своє налаштування. Якщо все працює належним чином, ви маєте побачити, що параметри fbc та fbp були успішно надіслані до Facebook або в офлайн-події purchase.

За допомогою Data Store ви можете створити клієнтську базу даних або CDP. Це забезпечує простий спосіб збору та зберігання всієї інформації, яку ви можете отримати від клієнтів, що допоможе вам створювати кращі форми аналітики або покращувати результати платних кампаній. Доповнення та збагачення клієнтських даних допоможе отримати цінну інформацію про поведінку та вподобання користувачів, що, своєю чергою, дозволить покращити ваші маркетингові стратегії.