Друзья, всех приветствую!
Продолжаю говорить о сборе данных из “ваших интернетов“, хочу рассказать немного о Server-Side GTM и чем он может быть полезен. Справедливости ради хочу сказать, что это статья скорее подойдет тем, кто немного знает, как пользоваться Google Tag Manager (Web) и настраивал события в нем. Для начала, предлагаю разделить свой рассказ на ряд вопросов:
Что такое Server-Side GTM и для чего он нужен?
Как поднять Server-Side GTM?
Как работать с тегами на стороне сервера?
Что такое Server-Side GTM и для чего он нужен?
Предположим, что в данный момент на своих веб-ресурсах используете Web контейнер Google Tag Manager, для большинства задач этого вполне хватает. Но зачем нам еще и серверный контейнер? На это вопрос есть ряд ответов:
При отслеживании событий на стороне клиента мы создаем нагрузку на устройства пользователей, а если тегов слишком много и их логика достаточно сложна, то это может создать ряд неудобств на устройстве пользователя (задержки в загрузке например). При отслеживании на стороне сервера мы передаем HTTP запросы на сервер, где происходит их обработка и распределение по каналам поставщиков рекламных и/или аналитических услуг. А можно сразу в БД закидывать данные, но об этом тут говорить не будем.
Cookies. Да, это тот самый файл, который храниться у пользователя и помогает нам понять, что он еще вчера к нам заходил и не является новым пользователем. В GA4 можно указать, сколько храниться этот файл. И если сервер ассоциирован с вашим доменом, тогда обработка файла будет происходить на сервере, что увеличит точность аналитики и мы соблюдаем first-party context. Возможно прошаренные веб-аналитики уже видели, что различные аналитические скрипты используют записи друг друга. С одной стороны это поможет увеличить точность, но и желания пользователей на анонимность нужно учитывать, поэтому через сервер можно передавать различным скриптам необходимую информацию.
Блокировка отслеживания скриптов на сайте. Да-да, много ли среди нас пользователей, которые пользуются различными блокировщиками? Это тоже влияет на статистику, но есть решение. Мы же отправляем данные на сервер, ассоциированный с нашим доменом, поэтому дешевые или вовсе бесплатные расширения пользователям не помогут.
При отправке дынных из серверного контейнера в рекламные кабинеты вы можете повысить точность конверсий рекламных кампаний предоставляя дополнительную информацию рекламным кабинетам, а это может улучшить обучаемость рекламных кампаний и снизить стоимость конверсионного действия на вашем ресурсе. Звучит очень заманчиво.
Предположим, что глаза у нас загорелись и мы хотим начать использовать этот функционал. Самый просто способ начать работу с ним это просто поднять серверный контейнер (об этом чуть ниже) и в тег Google внутри веб-контейнера добавить параметр server_container_url и ссылку на контейнер.
Создайте Server-Side Google Tag Manager по ссылке https://tagmanager.google.com/ .
При создании будет предложено вставить URL вашего основного контейнера (не для предварительного просмотра) и указать токен, который получили при создании контейнера в облаке.
На стороне Server-Side Google Tag Manager используйте клиент GA4. Поздравляю, теперь все события с веб-ресурсов летят на ваш сервер.
Хочу отдельно сказать, что серверный и веб-контейнер не заменяют друг друга, а дополняют. Далее возможно поймете механику взаимодействия этих контейнеров.
Как поднять Server-Side GTM?
Есть несколько популярных способов поднять серверный контейнер:
Пользоваться услугами сторонних поставщиков типа stape.io
Поднять в Google Cloud экземпляр App Engine
Поднять контейнер в Google Cloud через Cloud Run (самый простой способ)
Поднять Docker контейнер на своей виртуальной машине
Предлагаю рассмотреть самый простой и дешевый способ поднятия контейнера (через Cloud Run). Инструкция по настройке тут. Но я все же хочу остановиться на определенных моментах:
Заниматься администрированием этого контейнера после установки вам особо не придется (иногда обновлять контейнер и смотреть проблемные события в логах).
Все работает хорошо и есть автомасштабирование. Т.е. при предварительной настройке вы можете указать минимальное и максимальное количество экземпляров. Работает это достаточно просто, при достижении пиковой нагрузки на один экземпляр автоматически поднимается второй экземпляр контейнера, далее идет перераспределение нагрузки на контейнеры. После уменьшения нагрузки на контейнер система самостоятельно остановит ранее поднятый второй экземпляр. Для информации, при эксперименте с контейнером, где в месяц совершается более 10 млн. запросов только несколько раз запускался второй экземпляр контейнера.
Устанавливайте регион запуска контейнера рядом с вами (Финляндия, Польша и тд), это поможет уменьшить задержку с скорости передачи запросов.
Создавайте контейнер для предварительного просмотра (через него как раз и будете производить отладку событий на стороне сервера). Следует учесть, что предварительный просмотр на стороне сервера отличается от такового на веб-контейнерах. На веб-контейнерах вы при предварительном просмотре можете указать системе, какую страницу вы хотите посмотреть, после чего система направит вас на эту страницу. При использовании предварительного просмотра на стороне сервера такой возможности нет, поэтому нужно открыть новую вкладку и вписать необходимый URL адрес, который будете просматривать. При этом окно предварительного просмотра не закрывайте, в нем будут показаны HTTP запросы, которые прилетают на сервер.
Рекомендую подключить службу Logging внутри Google Cloud Platform для детального изучения ошибок и предупреждений системы. Пользуйтесь бесплатным тарифом, который позволяет сохранять определенное количество ГБ логов.
После создания сервера вы увидите что-то похожее на это:
Также рекомендуй настроить пользовательский домен для вашего сервера. Как это можно сделать указано тут. Это конечно не обязательно, но возможно для вас это актуально. Достаточно интересной реализацией будет работа в собственном контексте, когда вы будет запускать скрипты Google не с его серверов, а с собственного. Для этого нужно настроить все вышеуказанное, а также настроить пользовательский домен. После чего на вебе в коде контейнера поменять ссылку www.googletagmanager.com на ссылку домена или поддомена, где есть привязка серверного GTM к домену ресурса. Подробнее о такой реализации можно почитать тут.
Как работать с тегами на стороне сервера?
Супер, мы добрались до достаточно важного раздела, ради которого и проделали такую работу. Для работы с GA4 создаете на серверном контейнере тег Google Analytics и в качестве переменной специального триггера используйте клиент GA4, после чего и начнете получать данные с веба на сервер. Но хочу остановиться на рекламных тегах внутри серверного контейнера. Вы можете те же теги создавать и на вебе, но мы же хотим с большего перейти на сервер и снизить нагрузку на наш ресурс, поэтому посмотрим на теги рекламы внутри сервера.
Теги конверсий Google Рекламы не сильно отличаются от веба, просто ставите галочки в этом теге и в GA4 о предоставлении данных пользователей. Не забывайте создать тег связывания конверсий.
Теги Facebook Conversion API и TikTok Events API уже имеют отличия. Для работы с этими тегами предлагаю работать с поставщиком тегов от stape-io. На примере тега TikTok Events API:
На примере рекламного кабинета TikTok можем посмотреть, как настроить событие. Заходим в рекламный кабинет -> Tools -> Events -> Выбираем наш пиксель. В настройках пикселя генерируем Access Token и вставляем его вместе с ID пикселя в тег. Для проверки работоспособности тега можно в разделе Test Events сгенерировать Test ID. Совершите запуск тега (совершите событие на ресурсе) и в разделе Test Events увидите, что произошло тестовое событие. Если все работает, можно из Test ID убирать значение и запускать тег в работу.
Ранее мы говорили, что эти теги помогут лучше оптимизировать кампании и увеличат точность аналитики. Верно, внутри таких тегов есть раздел User Data. Туда можно засунуть номера телефонов, email пользователя, идентификатор клика типа ttclid, fbclid и тд. Похожие манипуляции можно сделать для VK и Яндекс Директ, но тут возможно нужно вам создать свои теги, но всегда можно это запускать с веб-контейнера. Эти данные помогут рекламным платформам находить для вас подходящую качественную аудиторию, ведь вы обогатили исходные данные. Например, вы хотите отправить номер телефона пользователя в рекламную платформу, но и тут есть определенные подводные камни, т.к. их нужно привести в необходимый для платформы формат. Давайте попробуем его преобразовать в нормальный формат для платформ. Как правило все платформы требуют отправлять номера в виде хеша SHA256, но перед тем как его захешировать номер телефона должен иметь формат E.164, т.е. номер не должен содержать пробелы, скобки. дефисы и тд. Только знак ”+” в самом начале номера. Пример номера +71901111111. Данные о номере телефона вы можете собирать из полей форм на ресурсе, после приводите в формат E.164 простым JS скриптом внутри веб-контейнера и там же можете его захешировать. Способы хеширования можете придумать сами, но для примера покажу один из них. Для начала создайте тег пользовательский HTML и засуньте в него код:
<script>
(function() {
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = "https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.0.0/crypto-js.min.js";
script.integrity = "sha256-6rXZCnFzbyZ685/fMsqoxxZz/QZwMnmwHg+SsNe+C/w=";
script.crossOrigin = "anonymous";
document.getElementsByTagName('head')[0].appendChild(script);
})();
</script>Далее создайте переменную собственный код JS и вставьте это:
function() {
var name = {{Номер телефона}};
var hash = CryptoJS.SHA256(name).toString();
return hash;
}На выходе получим хеш, который можем вместе с событие передать на сервер и далее в рекламные платформы. Также можно передавать метки ID клика типа ttclid, fbclid и тд. Забирать их можете прямо из ссылки при переходе на ресурс, как ее хранить внутри сессии придумывайте сами, решений очень много (можете засунуть в Session Storage). Далее можете передать ID клика на сервер и далее в рекламную платформу. Супер, вы отправили данные в рекламные платформы и обогатили их иными сущностями.
Конечно Server-Side GTM обладает достаточно большим функционалом, но я не хотел переписывать статьи различных авторов, поэтому моя статья скорее показывает, как его можно поднять и использовать.
