Server side GTM – тестирование функционала базовых тегов
Опубликовано: 19 сен 2020
Часть 1 Часть 2
Как вы наверное знаете, разработчики GTM выпустили версию менеджера тегов, которая функционирует на стороне сервера, пока на этапе beta. Данная статья рассказывает о моем первом тесте server-side GTM. Сразу хотелось бы сказать, что совсем простой вариант установки был бы не очень интересен, поэтому я постарался подключить несколько дополнительных функций, в первую очередь - это свой домен в качестве ендпоинта для сбора данных.
Для теста я создал новые пустые контейнеры стандартного GTM и серверного GTM. В качестве варианта сервера был выбран вариант "Automatically provision tagging server", который создает проект в Google Cloud и в нем разворачивает код серверного GTM в App Engine со следующей минимальной по ресурсам конфигурацией:
runtime: nodejs10
env: standard
instance_class: F1
Подключение своего поддомена
Привязать к серверу GTM собственный поддомен можно в настройках соответствующего проекта App Engine на вкладке Custom Domains:
В качестве имени поддомена можно выбрать, например, gtm.mysite.com или любую другую приставку. Вас попросят верифицировать ваш домен в Webmaster Central
Это можно сделать добавив соответствующую запись TXT в конфигурацию вашего DNS. Если вы используете Google Cloud DNS, это выглядит так:
Когда домен успешно верифицируется, на следующем шаге вам предложат добавить записи в конфигурацию DNS для SSL безопасности. Делается это аналогичным стандартным образом.
Через нисколько минут можно протестировать, что поддомен подключился корректно. Для этого заходим в Admin панель серверного GTM и в настройках (Container Settings) в поле Tagging server URL указываем URL нашего поддомена. Затем в основном разделе нажимаем кнопку Preview – окно preview должно открыться по адресу нашего поддомена.
Настройка базового тега аналитики App+Web
Тестировать серверный GTM будем на новой аналитике App+Web и начнем с самого простого варианта — всего один тег App+Web Configuration запускающийся по триггеру All Pages, в котором отправляется событие page_view. Поле, в котором мы указываем, что данные нужно отправлять на ендпоинт нашего серверного GTM называется transport_url — в нем указываем имя нашего поддомена. Также можно дополнительно в поле debug_mode указать встроенную переменную Debug Mode для использования раздела DebugView в интерфейсе App+Web в режиме preview клиентского GTM.
Публикуем контейнер и переходим к настройкам серверного GTM. Для обработки данного события нам нужно создать в нем тег App+Web, который будет запускаться при условии, что полученный сервером хит (событие) отдается клиенту App + Web Client (т. е. является хитом Measurement Protocol v.2). Это мы и указываем в настройках соответствующего триггера и тега.
Для проверки нам нужно открыть окно Preview серверного GTM и зайти на наш сайт, если все ОК, то в окне Preview серверного GTM мы должны увидеть наше событие page_view:
Также его можно отслеживать в разделе DebugVIew и в разделе Real-time интерфейса аналитики.
Как мы видим из раздела Real-time на момент написания статьи геолокация пользователя при использовании серверного GTM к сожалению не определяется.
Это происходит потому, что серверный GTM должен передать информацию об ip пользователя для создания в аналитике полей геолокации. Для этого в модели данных события используется параметр ip_override, и похоже аналитика App+Web пока его не поддерживает, хотя анонимизация IP-адресов в ней происходит автоматически. В случае же с Universal Analytics, которая данный параметр поддерживает, локация при использовании server-side GTM должна определятся.
На данный момент серверный GTM содержит небольшое количество встроенных клиентов, а именно только App+Web аналитика и стандартная Universal Analytics, но есть механизм создания кастомных клиентов с использованием sandboxed javascript и Server-side tagging APIs для обработки практически любых входящих хитов.