Создание собственной CDP и обогащение данных о событиях с помощью серверного GTM

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

Один из способов использовать CDP — купить готовое решение, что может быть недешево. Другой вариант — создать собственную CDP. В этой статье мы покажем, как создать простую версию CDP с помощью серверного Google Tag Manager и базы данных. 

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

Серверный контейнер Google Tag Manager будет получать запросы обо всех взаимодействиях пользователей — как онлайн, так и офлайн. Для получения онлайн-событий из веб-контейнера GTM можно использовать стандартные клиенты, такие как GA4 или Data Client. Для получения офлайн-событий можно использовать вебхуки. Далее в статье я покажу, как отправлять и отлаживать данные вебхуков внутри 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 отсутствует параметр city (поля city нет), то это поле будет взято из хранилища. Если во входящем запросе есть поле city, а в хранилище его нет или оно отличается, данные для этого поля из запроса будут записаны в хранилище.
5. 5.
   Используйте полный профиль клиента для его отправки вендору через межсерверное подключение.

1. 1.
   Сайт. Два самых популярных способа отправки данных с сайта в sGTM — это настройка серверного GA4 и Data Tag.
2. 2.
   Вебхуки CRM (Hubspot, SalesForce, Jira и т. д.).
3. 3.
   CMS. Вы можете использовать плагины серверного трекинга Shopify, WordPress или Google Tag Manager для Magento 2, чтобы отправлять вебхуки о возвратах и покупках в sGTM.
4. 4.
   SDK и мобильное приложение. Stape создал SDK для 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. Она генерирует дополнительный идентификатор (X-Stape-Cross-Domain-Id) на основе тех же сигналов, но без hostname, поэтому один и тот же неидентифицированный пользователь получает единый ID на всех ваших доменах, подключенных к серверному контейнеру. Это помогает избежать дублирования профилей в CDP.

Если для соблюдения конфиденциальности требуется сделать User ID более уникальным, можно добавить зависимую переменную. Это может быть день, месяц, неделя или год — все зависит от необходимого уровня уникальности идентификатора. 

Мы будем использовать переменную reStore либо тег Stape Store Writer и переменную Stape Store Lookup для объединения и сшивания профилей пользователей из запросов и базы данных. Копии этих шаблонов также доступны на Stape GitHub.

Назначение тега записи и переменной поиска вполне очевидно. Эти два шаблона позволяют записывать и считывать данные из Data Store. 

Переменная reStore сначала определит, существует ли пользователь в базе данных. Сначала переменная получает все идентификаторы пользователя из события (email, телефон или client ID). Затем она отправляет запрос в хранилище для выбора клиентов, у которых есть один из таких идентификаторов. Если в базе данных есть информация о клиенте, она вернет данные об этом клиенте.

Когда переменная получает ответ из хранилища, она объединяет его с входящим запросом. Например, если поле city отсутствует, будет использовано значение этого поля из хранилища. Если во входящих запросах есть поле city, но в хранилище его нет или оно отличается, данные из запроса для этого поля будут записаны в хранилище. Эта переменная создает новую сущность, если клиент частично найден в хранилище.

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

Отладка в sGTM бывает непростой, а в случае с офлайн-событиями она может быть еще сложнее. Мы расскажем, как использовать следующие инструменты:

• Отладчик sGTM
• Логи Access/Request/Response Stape
• Тег Logger
• sGTM Preview Header

Я представлю два сценария, чтобы продемонстрировать, как можно использовать хранилище данных. Мы выяснили, что это самые популярные сценарии среди клиентов Stape.

1. Настройте User ID. Я буду использовать павер-ап User ID от Stape, который поможет сопоставлять пользователей с клиентами.

a. Войдите в свой аккаунт Stape и включите павер-ап. Для этого откройте контейнер sGTM, перейдите на вкладку Power-ups, откройте User ID, переключите тумблер и сохраните.

b. В контейнере Server GTM создайте переменную, которая будет извлекать User ID из заголовков запроса на сервере.

2. Запишите данные в базу данных при событии purchase. Убедитесь, что вы добавляете Stape User ID в данные события. 

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

b. Если тег сработал правильно, вы увидите в своей базе данных запись, похожую на скриншот ниже.

3. Enrich pageview event data with the stored data in the Data Store.

a. Чтобы сопоставить пользователей из события pageview с теми, что сохранены в базе данных, мы снова используем Stape User ID и переменную Stape Store Lookup, которая может извлекать данные из хранилища. Добавьте переменную Stape Store Lookup в галерею шаблонов переменных sGTM. Чтобы скачать шаблон с GitHub, перейдите в раздел шаблонов sGTM. В разделе переменных нажмите New, затем — Import.

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

c. Добавьте переменную Lookup в тег pageview. 

4. Протестируйте настройку. В теге, сработавшем в контейнере sGTM, должны отображаться обогащенные данные пользователя. 

В этом сценарии использования я хочу отправить данные офлайн-событий в рекламную сеть. При отправке данных о конверсиях на платформу рекламодателя критически важным элементом является отправка click ID. Click ID — это идентификатор, который добавляется в URL или файлы cookie, когда пользователь переходит по рекламной ссылке. С помощью Click ID рекламная сеть может легко атрибутировать конверсию к рекламной кампании. 

Параметры Click ID доступны для всех веб-событий, но если вы хотите передавать в рекламную сеть данные о конверсиях из CRM или CMS, в большинстве случаев click ID будут недоступны.

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

В стандартных CMS этого легко добиться, поскольку они обычно сохраняют такой идентификатор в cookie. Для пользовательских сайтов вам потребуется попросить разработчиков добавить эти параметры. Моя настройка выполнена на сайте WordPress. Плагин Stape для WordPress отправляет уникальный User ID вместе с веб-событиями и добавляет его в вебхук. С помощью этого User ID я могу сопоставлять пользователей между просмотром страницы и вебхуками покупок в базе данных. 

1. Получите вебхук о покупке из офлайн-источника данных в sGTM. 

a. Отправьте вебхук из CRM. Для этого я буду использовать приложение Stape для WordPress. Перейдите на вкладку Webhooks и добавьте URL контейнера Server GTM. Это домен, который вы используете для своего серверного контейнера GTM. Мы рекомендуем настроить собственный домен в рамках домена вашего сайта, так как это позволит устанавливать файлы cookie первой стороны. Не забудьте отметить нужные чекбоксы. 

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

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

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, которое будет срабатывать каждый раз при получении вебхука. Чтобы дополнить это событие данными из Data Store, нам понадобится трансформация и та же переменная восстановления, которую мы использовали для трансформации в событии pageview FB. Это позволит извлечь нужный параметр в событии purchase. Но чтобы отправить данные в понятном для Facebook виде, нам понадобится переменная извлечения объекта, которая извлекает нужный объект из переменной восстановления.

f. Протестируйте настройку. Если все работает правильно, вы увидите, что параметры fbc и fbp были успешно отправлены в Facebook или в офлайн-событии purchase.

С помощью Data Store вы можете создать клиентскую базу данных или CDP. Это удобный способ собирать и хранить всю информацию, которую вы получаете от клиентов, что поможет создавать более точные аналитические формы или улучшать результаты платных кампаний. Дополнение и обогащение данных о клиентах помогут получить ценные инсайты об их поведении и предпочтениях, а это, в свою очередь, позволит оптимизировать маркетинговые стратегии.