Введение в тегирование на стороне сервера

Использование серверной теговой маркировки — это новый способ применения Google Tag Manager для мониторинга вашего приложения на разных устройствах. Серверные контейнеры используют ту же модель тегов, триггеров и переменных, к которой вы привыкли, а также предоставляют новые инструменты, позволяющие измерять активность пользователей независимо от места её возникновения.

Типичная конфигурация тегирования без серверного тегирования основана на использовании контейнера на странице для отправки данных измерений на различные серверы сбора данных. На рисунке 1 показан пример того, как веб-контейнер Tag Manager, работающий в веб-браузере, отправляет данные на несколько серверов.

Схема сайта, оснащенного веб-контейнером Google Tag Manager.

Рисунок 1: Схема сайта, оснащенного веб-контейнером Google Tag Manager.

В отличие от этого, серверный контейнер не работает в браузере пользователя или на его телефоне. Вместо этого он работает на сервере, который вы контролируете.

Схема сайта, оснащенного контейнером для тегирования на стороне сервера.

Рисунок 2: Пример конфигурации тегирования с использованием серверного контейнера.

Сервер работает в вашем собственном проекте Google Cloud Platform — или в другой среде по вашему выбору — и только вы имеете доступ к данным на сервере, пока не решите отправить их куда-либо ещё. Вы полностью контролируете, как эти данные обрабатываются и куда они направляются с сервера. Теги создаются с использованием технологии изолированного JavaScript . Разрешения позволяют вам видеть, что может делать тег, а политики позволяют устанавливать границы вокруг контейнера.

Сервер получает веб-запросы с устройства пользователя и преобразует эти запросы в события . Каждое событие обрабатывается тегами, триггерами и переменными контейнера. Теги, триггеры и переменные в серверном контейнере работают точно так же, как и в других типах контейнеров: триггеры проверяют каждое событие на наличие определенных условий и, при необходимости, запускают теги, которые отправляют данные события для обработки.

Данная модель ставит два важных вопроса для серверных контейнеров:

  • Как данные измерений передаются с устройства пользователя в контейнер на сервере?
  • Как данные измерений, отправленные в контейнер сервера, преобразуются в событие?

Ответом на оба вопроса является новый тип сущности для использования в серверных контейнерах: клиент .

Как работают клиенты

Клиенты представляют собой адаптеры между программным обеспечением, работающим на устройстве пользователя, и вашим серверным контейнером. Клиент получает данные измерений с устройства, преобразует эти данные в одно или несколько событий, направляет данные для обработки в контейнере и упаковывает результаты для отправки обратно запрашивающей стороне.

Это очень много всего! Давайте рассмотрим каждую часть по отдельности. На рисунке 3 показан поток данных в серверный контейнер из веб-браузера пользователя и от вашего веб-сервера к серверному контейнеру.

Схема сайта, оснащенного контейнером для тегирования на стороне сервера.

Рисунок 3: Каждый поток данных обрабатывается отдельным клиентом.

Клиенты получают данные измерений с устройства. Допустим, вы хотите измерить активность пользователей в трех местах: на веб-сайте, в мобильном приложении и на умном тостере. Ваш веб-сайт использует Google Analytics, ваше мобильное приложение — Firebase Analytics, а ваш тостер — проприетарный протокол под названием «ToastMeasure».

Обычно для мониторинга этих трех устройств с помощью Google Tag Manager требуется отдельный контейнер для каждой платформы. Поскольку серверный контейнер не работает на устройстве, один и тот же контейнер может обрабатывать аналитические данные для всех трех платформ устройств. Однако есть проблема. Эти устройства взаимодействуют по-разному. Протокол Google Analytics отличается от протокола ToastMeasure. Вот тут-то и вступают в игру клиенты.

Вместо этих трех контейнеров ваш серверный контейнер имеет три клиента. Каждый запрос, поступающий в контейнер, будет обрабатываться каждым клиентом в порядке приоритета, начиная с клиента с наивысшим приоритетом. Первое, что делает каждый клиент, — это решает, знает ли он, как обработать запрос такого типа. Если может, клиент «забирает» запрос и переходит к следующему этапу обработки. Забор запроса предотвращает запуск последующих клиентов. Если клиент не может обработать запрос, он ничего не делает и позволяет другим клиентам решать, обрабатывать запрос или нет.

Клиенты преобразуют данные запроса в одно или несколько событий. После того, как клиент ToastMeasure подтвердил запрос, ему необходимо преобразовать его в нечто, понятное остальной части контейнера. Этим чем-то является набор событий .

События — это происходящие события, которые вы хотите измерить. Это могут быть любые события: start_toasting , finish_toasting или buy_bread . Существуют некоторые рекомендации относительно структуры событий, генерируемых клиентом, но единственное требование — остальная часть контейнера должна их понимать.

Клиенты запускают контейнер. Клиент подтвердил запрос и преобразовал его в события. Теперь настало время для тегов, триггеров и переменных. Клиент передает каждое событие остальной части контейнера для дальнейшей обработки.

Клиенты упаковывают результаты для отправки обратно на устройство. После завершения работы контейнера настает время ответить тостеру. Ответ может принимать различные формы. Возможно, клиент просто скажет «ОК, готово». Возможно, один из тегов хочет перенаправить запрос на другой сервер сбора данных. Или, возможно, один из тегов дает команду индикаторам на тостере изменить цвет. Что бы ни должно было произойти, задача клиента — упаковать результаты и отправить их обратно запрашивающему устройству.

К счастью, Tag Manager берет на себя большую часть этой работы. В состав серверных контейнеров входят 2 клиента: Google Analytics и Measurement Protocol. Эти клиенты предоставляют инструменты, необходимые для начала мониторинга вашего приложения сразу после создания контейнера.

Краткий пример

Давайте рассмотрим простой пример, чтобы увидеть, как все части взаимодействуют друг с другом. В этом примере вы создадите следующее:

  1. Простой веб-сайт, использующий gtag.js для отправки события click в контейнер сервера.
  2. Клиент Google Analytics, получающий это событие.
  3. Триггер, срабатывающий по click .
  4. Тег Google Analytics, который отправляет данные о событии в Google Analytics для обработки.

В этом примере мы будем исходить из того, что вы уже создали и развернули контейнер сервера.

Настройте gtag.js

Сначала настройте gtag.js для отправки данных в контейнер вашего сервера. С gtag.js отправка данных в контейнер вашего сервера работает так же, как и отправка данных в Google Analytics, с одним изменением. Как показано на примере ниже, установите параметр конфигурации server_container_url так, чтобы он указывал на контейнер сервера.

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'TAG_ID', {
    server_container_url: 'https://analytics.example.com',
  });
</script>

Замените TAG_ID на идентификатор вашего тега . Замените https://analytics.example.com на URL-адрес вашего серверного контейнера.

Далее добавьте функцию sendEvent() для обработки событий click :

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'TAG_ID', {
    server_container_url: 'https://analytics.example.com',
  });

  function sendEvent() {
    gtag('event', 'click');
  }
</script>

<button onclick="javascript:sendEvent()">Send Event</button>

Замените TAG_ID на идентификатор вашего тега . Замените https://analytics.example.com на URL-адрес вашего серверного контейнера.

При такой конфигурации обработчики событий, такие как функция sendEvent() включенная в этот пример, будут отправлять событие click в контейнер вашего сервера.

Клиент Google Analytics

Вашему контейнеру потребуется клиент для получения события после того, как оно достигнет сервера. К счастью, в серверных контейнерах уже предустановлен клиент Google Analytics, так что этот шаг уже выполнен.

Триггер клика

Далее создайте триггер, который срабатывает при click . Создайте пользовательский триггер , который срабатывает, когда встроенная переменная Event Name равна "click".

конфигурация триггера

Тег Google Analytics

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

Предварительный просмотр контейнера

Теперь, когда контейнер настроен, нажмите «Предварительный просмотр» . Откройте свой веб-сайт в другом окне браузера. По мере отправки запросов и событий на ваш серверный контейнер вы будете видеть список запросов и событий в левой части страницы предварительного просмотра.

Когда вы будете удовлетворены внесенными изменениями, опубликуйте контейнер сервера.

Настройте сервер для производственного режима с использованием собственных серверов.

Прежде чем направлять какой-либо производственный трафик на ваш серверный контейнер, мы настоятельно рекомендуем установить сервер на вашем собственном домене и обновить сервер до производственного режима .