Google Tag Manager предлагает два способа разместить теги на стороне сервера:
-
Через серверный контейнер, развернутый на платформе Google Cloud.
-
Через провайдера — эта функция появилась в сентябре 2021 года, что сделало серверное добавление тегов в Google Tag Manager еще более доступным.
Финский аналитик Симо Ахава подробно разобрал первый из этих способов. Мы перевели и адаптировали его статью для вас.
- Перед тем как прочитать руководство
- Что такое серверное добавление тегов
- Основные преимущества
- Основные проблемы
- Техническая настройка
- Полезные ссылки на блог Google для разработчиков
Введение
В этой статье ответим на вопросы: что такое cерверное добавление тегов в Google Tag Manager, какие у инструмента есть преимущества и недостатки, как он настраивается и какие возможности открывает аналитикам.
Серверное добавление тегов требует запуска контейнера Google Tag Manager в серверной среде.
Такое размещение меняет привычный подход к организации сбора и хранения данных. У вас есть полный контроль над сервером и доступ к инструментам для анализа трафика, который через него проходит.
Вы сможете развернуть полнофункциональную систему цифровой аналитики, не загружая сторонний код в браузер или на устройство пользователя. При правильной настройке вы забудете про риск утечки персональных данных, про блокировку межсайтового отслеживания и большие сторонние скрипты, которые утяжеляют клиент.
В серверном добавлении тегов используются концепции, знакомые пользователям Google Tag Manager:
-
Есть теги, которые срабатывают от триггеров и извлекают данные из переменных.
-
Перед публикацией новой версии контейнера его можно запустить в режиме предварительного просмотра.
-
Можно создавать пользовательские шаблоны.
Но есть и принципиально новые функции, которые сдвигают парадигму в сторону динамического тегирования:
-
Серверный контейнер отличается от других контейнеров (WEB, APP и AMP).
-
Вместо триггерных событий процессы запускаются входящими HTTP-запросами.
-
Запросы обрабатываются новым типом сущности GTM: клиентом.
-
Клиенты анализируют запросы, создают объекты с информацией о событии и отправляют их в виртуальные контейнеры — там теги используют информацию из этих объектов событий, чтобы определить и отправить данные в заданные эндпоинты.
У этой статьи нет цели стать исчерпывающим руководством. Мы описываем основные концепции серверного тегирования и даем ответы на основные вопросы. Но в дополнение к статье рекомендуем ознакомиться с официальной документацией по серверному добавлению тегов Google.
Перед тем как прочитать руководство
Советуем посмотреть два видео:
Введение в серверное добавление тегов. Основное внимание уделяется развертыванию и началу работы с первым клиентом и тегами.
Глубокое погружение в создание собственного шаблона клиента. Это видео более специфичное, поэтому его можно пропустить, если вас не интересует настройка контейнера.
Что такое серверное добавление тегов
Вместе с серверным добавлением тегов Google представил новый тип контейнера — серверный контейнер, который должен размещаться в Google Cloud.
Если кратко, серверный контейнер нужен для создания эндпоинта (конечной точки) на стороне вашего сервера. Он должен работать как своего рода прокси-сервер, который обрабатывает обращения из браузера или устройства пользователя в фактический эндпоинт.
Сам контейнер работает как HTTP API-эндпоинт, на который может отправлять запросы любой источник, поддерживающий протокол HTTP.
В идеале ваш эндпоинт должен находится на поддомене в той же иерархии доменов, что и веб-сайт, который отправляет запросы. Так будет считаться, что запросы выполняются в собственном контексте (first-party), что влияет, например, на запись и чтение файлов cookie.
Клиенты в серверном контейнере прослушивают входящие HTTP-запросы, которые преобразовываются в соответствии с унифицированным форматом событий. Затем клиенты запускают виртуальный контейнер, в котором находится объект с информацией о событии, где теги, триггеры и переменные формируют отправку события аналогично тому, как это происходит с WEB-контейнером.
Теги берут информацию из этих объектов с информацией о событии и преобразовывают их в HTTP-запросы к соответствующим эндпоинтам. В конце клиент отправляет HTTP-ответ обратно — в источник изначального запроса.
Браузер или приложение, которые отправляют данные, могут узнать о происходящем на сервере только одним способом — это если клиент сам добавит соответствующую информацию в HTTP-ответ. Ответ полностью настраивается.
Основные преимущества
Разберем некоторые преимущества, которые дает серверное тегирование.
Увеличение скорости загрузки сайта
Если задать логику отправки запросов к эндпоинту на своем сервере, можно уменьшить количество загружаемых в браузере пользователя скриптов JavaScript, особенно посторонних.
Вы сами можете настроить, как серверный контейнер будет преобразовывать входящие HTTP-запросы. Теоретически вы можете собрать загрузку всех сторонних пикселей и скриптов, отправленных в ваш серверный контейнер, в единый поток событий.
Клиент перехватывает этот поток и преобразует его в модель событий, которую ожидают теги, также запущенные в серверном контейнере.
Это большое достоинство серверного добавления тегов. Даже если вы не хотите сводить всё в один поток, можете создать пользовательский шаблон в WEB-контейнере, который будет отправлять HTTP-запросы к серверному контейнеру. При этом не нужно загружать сторонний JavaScript, кроме самой библиотеки GTM.
Выше безопасность
Перенеся логику обработки данных с устройства посетителя, где к ней может получить доступ любой желающий, вы сможете отправлять учетные данные и не беспокоиться об их перехвате.
Например, спам по Measurement Protocol — большая проблема для Google Analytics. Злоумышленники собирают идентификаторы счетчиков и отправляют в них спам с помощью автоматических HTTP-запросов, замаскированных под обычные обращения с сайта. Или хакеры могут отправлять спамные запросы на случайные идентификаторы: они исходят из логики, что если отправить большое количество обращений, часть из них попадет в реальные счетчики Universal Analytics.
Такой тип спама трудно выявить и заблокировать, потому что он маскируется под реальные обращения с веб-сайта.
Если у вас под рукой настроен серверный контейнер, вы можете добавить пользовательский параметр, который будет отправляться вместе с запросом в Google Analytics. В Google Analytics вам останется создать фильтр, пропускающий только запросы с этим параметром.
Спамеры не будут знать о наличии секретного параметра в контейнере. Парсинг сайта для анализа запросов, которые отправляются в Google Analytics, не поможет: в этих запросах нет ничего необычного. Есть простые запросы, которые отправляются в ваш собственный эндпоинт на стороне сервера, и было бы странно, если бы спамеры использовали его в своих алгоритмах.
Естественно, это не единственное, что можно сделать в Google Analytics. Любые сторонние сервисы, которые дают возможность аутентификации при помощи ключа API или токена для авторизации, теперь могут проксироваться через ваш серверный контейнер и не отправлять секретные ключи на устройства.
Больше контроля над данными
Поскольку ваш прокси-сервер находится между устройством пользователя и поставщиков, вы полностью контролируете, что отправлять.
Если клиент специально не переопределяет IP-адрес и User-Agent пользователя в исходящем HTTP-запросе (по умолчанию это делает встроенный клиент Universal Analytics), IP и User-Agent пользователя будут принадлежать вашему серверу, а не самому пользователю. Отличный способ обезличить эту часть протокола HTTP, проблемную с точки зрения конфиденциальности пользователей.
Серверное добавление тегов в целом дает дополнительный контроль над конфиденциальностью.
Без специального переопределения все запросы, отправленные поставщику, сопоставляются с виртуальной машиной, на которой запущен серверный контейнер, а не с браузером или устройством пользователя.
Больше никаких утечек данных со сторонними файлами cookie, никаких сюрпризов с подставными URL-параметрами. Все посторонние службы по умолчанию не взаимодействуют с браузером пользователя. Они общаются только с облачной машиной, на которой размещен ваш серверный контейнер.
Больше контроля над HTTP-трафиком
В дополнение к функциям, описанным выше, вы получаете полный контроль над HTTP-трафиком, который проходит через ваш серверный контейнер.
Обычно браузер загружает JavaScript поставщика из CDN — сети доставки контента.
Уже это действие раскрывает информацию о браузере и устройстве пользователя третьей стороне и может привести к утечке персональных данных. Например, если URL-адрес страницы содержит такую информацию:
Так как теперь у вас есть прокси-сервер между пользователем и поставщиком, подобная информация будет оставаться только в вашей облачной среде.
Конечно, даже это не идеальное решение. Любая, даже сама крохотная, возможность утечки персональных данных должна быть устранена.
Но теперь у вас есть полный контроль над данными, проходящими через серверный контейнер. А еще — все необходимые инструменты для анализа содержимого получаемого пейлоада (полезной нагрузки) и его очистки от персональных данных.
Вы также можете удалить фингерпринты из запросов от серверного контейнера. Аналогичным образом вы можете использовать API, используемые для хеширования потенциально конфиденциальных данных. Конечно, вы также можете запрашивать согласие на сбор данных (если серверный контейнер находится в контексте first-party) и действовать в соответствии с выданным разрешением.
Наконец, при помощи клиента вы можете изменить HTTP-ответ, возвращаемый из серверного контейнера в браузер или устройство пользователя. Это очень полезно, особенно если учесть блокировщики контента (например, интеллектуальную систему предотвращения отслеживания от Apple). Вы можете перезаписать файлы cookie, созданные с помощью JavaScript, установив их методом Set-Cookie. Это позволит избежать ограничением срока жизни cookie в 7 дней и продлить его до любого периода, который выберете:
Обязательно нужно установить флаг HttpOnly на созданные файлы cookie. Это запретит доступ веб-страницы к cookie с помощью JavaScript-метода document.cookie. Разрешая доступ к файлам cookie только веб-серверу, который получает запрос, вы обеспечиваете достаточные ограничения, чтобы избежать атак межсайтовых скриптов и предотвратить утечки файлов cookie в схемах межсайтового отслеживания.
В приведенном выше примере не используется флаг HttpOnly, потому что клиентский Universal Analytics все еще использует JavaScript для междоменного отслеживания.
В любом случае использование заголовка Set-Cookie, как в приведенном примере, устраняет необходимость в использовании сложных API для перезаписи файлов cookie. Вы можете просто переписать эти файлы во время сбора данных.
Повышение надежности CSP
Еще одно преимущество сокращения числа эндпоинтов, с которыми взаимодействует браузер, связано с политикой безопасности содержимого сайта (CSP). CSP — это то, что использует ваш сайт, чтобы ограничить входящий и исходящий браузерный HTTP-трафик.
Например, если вы добавите библиотеку JavaScript, которая загружает свое содержимое с Facebook на сайт с CSP, вам придется обратиться к разработчикам с просьбой скорректировать CSP — чтобы разрешить доменам Facebook отправлять и получать данные из браузера пользователя.
Уменьшая количество конечных HTTP-эндпоинтов, с которыми должен взаимодействовать браузер (так как вы заменили их своим эндпоинтом с серверным добавлением тегов), вы повышаете надежность CSP.
Валидация и очистка пейлоада
Даже если вы очистили HTTP-трафик ото всей потенциально опасной информации, все равно могут остаться URL-параметры, которые сайт требует заполнить. Часто эти параметры содержат персональные данные, и их тоже надо очищать.
Решение на базе customTask должно помочь, если вы отправляете данные из браузера непосредственно в Google Analytics.
Но с помощью серверного контейнера можно создать клиент, который будет анализировать содержимое всех запросов (не только связанных с Universal Analytics) на наличие персональных данных, а затем очищать их или шифровать.
Серверный контейнер также можно использовать для валидации и исправления запросов.
Например, если вы отправите запрос с нечисловым значением в качестве значения события (Event Value) в Universal Analytics, это событие попадет в Google Analytics, но будет удалено при обработке. В браузере никаких предупреждений не будет, и этот хит просто исчезнет.
Можно избежать этой ошибки, добавив клиент, который будет искать события с ошибками и преобразовывать их в правильные типы данных:
Полный контроль над данными, собранными контейнером
Мы уже частично раскрыли этот пункт ранее.
Важная часть настройки серверного окружения — это сопоставление поддомена с адресом вашего эндпоинта. Если эндпоинт отвечает на запросы, используя поддомен из иерархии доменов веб-сайта, отправляющего запросы, это значит, что веб-сайт и эндпоинт существуют в собственном контексте (first-party). Это сильно влияет на то, как обрабатывают трафик средства защиты от отслеживания браузера.
Кроме вопроса контекста важно и то, как работает с данными платформа с серверным контейнером.
Вот что пишет Google в своей документации:
-
Вы сами контролирует свои данные.
-
Googl не использует ваши данные в рекламных целях.
-
Google прозрачен в отношении обработки ваших данными,
-
Google не продает данные третьи лицам.
-
Безопасность и конфиденциальность — основные критерии продуктов Google.
Это важно. Вы владелец данных, собранных серверным контейнером, и вы их контролируете. Их обработка и использование попадает под действие политики конфиденциальности и других договоров, заключенных вашей организацией со своими клиентами и конечными пользователями.
Например, если произойдет утечка данных, первым местом, куда она «утечет», будет ваше собственное хранилище данных. Вы можете обезопасить себя, убедившись, что лишние данные не попадут к третьим лицам, которым вы отправляете данные из серверного контейнера.
Естественно, как только ваш серверный контейнер активирует теги, которые отправляют данные третьим лицам, вы должны активировать дополнительные процессы контроля данных. Но наличие собственного «буферного» процесса хранения и обработки данных должно помочь снизить риски в области безопасности и конфиденциальности.
Безграничные возможности
Перенося обработку данных на свой сервер, вы получаете дешевый, масштабируемый и многофункциональный прокси-сервер для обработки данных перед их упаковкой и отправкой.
Кроме описанных выше преимуществ, есть еще множество решений, которые можно реализовать с помощью серверного добавления тегов. Например:
-
Соберите из браузера важные данные: Contenty ID, Session ID и User ID. На стороне серверного контейнера запустите дополнительные API и сервисы для обогащения полученных данных.
-
Запускайте «тяжелый» код на стороне сервера и не загружайте его на устройство пользователя. Например, серверному контейнеру можно передать IP Lookup и хеширование.
С развитием платформы, расширением библиотеки доступных API и пользовательских шаблонов возможности серверного контейнера станут практически безграничными.
Основные проблемы
У переноса отслеживания с устройства на сторону сервера есть и недостатки.
Переход на серверный контейнер улучшит процесс сбора данных, но сделает его сложнее.
Обход блокировщиков контента
Одна из первых мыслей, связанная с серверным контейнером, которая приходит в голову большинству, — про обход блокировщиков контента и защиты браузерного отслеживания.
Чаще всего браузеры, чтобы обеспечить конфиденциальность, ограничивают или полностью блокируют трекеры на стороне браузера. Список трекеров обычно берется из стоп-листов, например, disconnect.me. Но блокировка может быть алгоритмической и встроенной в устройство — как в интеллектуальной системе предотвращения отслеживания в Safari.
Логично, что такие алгоритмы могут заблокировать эндпоинт вида google-analytics.com, но my-server-side.domain.com с большой вероятностью будет работать без проблем.
Можно ли использовать серверный контейнер для обхода блокировщиков отслеживания? Да! Стоит ли это делать? Если это единственная причина установки серверного контейнера, тогда нет.
И здесь возникает интересный парадокс.
Не ваша вина, что блокировщики контента не проверяют ваши домены.
Вы не обязаны проверять, все ли эндпоинты заблокированы браузером. Это затратно и непродуктивно по отношению к тому, зачем существует серверное добавление тегов: чтобы уменьшить нагрузки на пользователей.
Как только серверные прокси получат достаточное распространение (такой популярный инструмент, как Google Tag Manager, точно этому поможет), блокировщики контента адаптируют свои алгоритмы не только для просмотра доменов, на которые отправляется информация, но и что за информация передается.
Мы считаем верной позицией честность и прозрачность в том, какие данные собирает сайт. Это значит — просить согласие на сбор данных у пользователей и давать возможность отказаться.
И если вы увидите, что блокировщик контента заблокировал ваш эндпоинт или в возвращаемых данных не хватает информации, не пытайтесь искать, как обойти систему.
Всегда ошибайтесь в пользу максимальной конфиденциальности.
Исходите из того, что пользователь понимает, зачем он блокирует сбор данных о себе. Не игнорируйте его желание.
Непрозрачный сбор данных
Часто, когда в компании происходит утечка данных или находится дыра в безопасности, это обнаруживает сторона, которая не связана с компанией.
В интернете полно организаций и частных лиц, которые проводят аудит входящего и исходящего HTTP-трафика на сайтах. Именно эти люди сыграли важную роль в раскрытии атак Magecart и захвата поддоменов.
Утечки файлов cookie, внедрение межсайтовых скриптов, обход CSP и всевозможные неприятные взломы JavaScript обычно происходят в браузере пользователя, потому что там выполняются скрипты поставщиков.
Переходя на серверное тегирование, вы сокращаете количество стороннего JavaScript, который выполняется на сайте. И это шаг к решению проблем, перечисленных выше.
Также вы убираете все следы, по которым можно было бы судить, что происходит с данными, отправленными в запросах. Проверяющим будет сложно понять, что находится в потоке к вашему эндопинту, и не нарушаете ли вы права пользователя на конфиденциальность и безопасность на стороне своего сервера, куда пользовательские инструменты не могут добраться.
Это означает, что вы должны подробно описать, как они хранятся и обрабатываются. Вы обязаны сделать это в соответствии с такими правовыми нормами, как GDPR и CCPA / CPRAA, которые требуют от вас быть открытыми и прозрачными в отношении сбора, хранения и обработки персональных данных.
Вам стоит заранее принять все меры, чтобы обеспечить прозрачность и законность в отношении работы с данными, чтобы избежать судебных разбирательств и потенциального ущерба бренду, когда вас поймают с поличным.
Управление согласием
Этот пункт будет важен нескоро, но задуматься о нем нужно уже сейчас.
Управление согласием — важная тема, и это справедливо. Многие сайты реализуют инструменты управления согласием на стороне клиента. Они требуют от посетителя дать согласие в отношении того, какие данные будут собираться.
Обычно данные о согласии хранятся в виде файлов cookie или в виде записи в localStorage, и многие поставщики могут взаимодействовать с фреймворками пользовательского согласия, например, Transparency & Consent Framework 2.0 от IAB.
Перейдя на серверное добавление тегов, вы сможете отправлять все события из браузера на сервер в едином потоке. И этот единый поток можно разделить на десятки рекламных, маркетинговых и аналитических запросов в серверном контейнере.
Решения, запущенные в серверном контейнере, не смогут взаимодействовать с API фреймворков согласия на стороне клиента, например, с теми, которые предлагаются TCF. Вместо этого вы должны сами создать механизм получения и обработки согласия у пользователя в самом контейнере.
Возможно, в будущем Google представит инструменты, которые упростят этот процесс. Но до того, как это произойдет, вам нужно самостоятельно следить, чтобы согласие, отправленное на уровне браузера или устройств, было правильно учтено на уровне сервера.
Стоимость
В зависимости от того, с чем вы сравниваете, стоимость серверного контейнера может казаться высокой или низкой.
Это дорого, если сравнивать с запуском скриптов на стороне браузера, ведь он не требует затрат.
Это недорого, если учитывать все преимущества настройки серверного контейнера.
Стоимость содержания серверного контейнера зависит от количества облачных серверов, обслуживающих этот контейнер. Количество необходимых серверов рассчитывается исходя из количества поступающих запросов на сайт в секунду. Но Google рекомендует для любого сайта подключать не менее трех серверов. Стоимость одного сервера составляет около 40 долларов / мес.
Например, в справке по настройке App Engine указано: «Ориентировочно автомасштабирование до 3–6 серверов (настройка по умолчанию) позволяет обрабатывать по 50–200 запросов в секунду, однако этот показатель зависит от количества и функций тегов».
Отсутствие серверных эндпоинтов у поставщиков
Чтобы серверный контейнер смог заменить WEB-контейнер (запускаемый на стороне клиента), поставщики, которым вы хотите отправлять данные, должны уметь обрабатывать HTTP-запросы от серверного контейнера.
Такая проблема есть не всегда, так как у многих поставщиков есть эндпоинты, на которые отправляют данные их библиотеки JavaScript, и многие из них поддерживают работу с пикселями для сбора GET-параметров.
Но библиотеки некоторых поставщиков сложные и тяжелые. Поэтому, если вы хотите уменьшить количество загружаемого мусора, поставщик должен предоставить средства для самостоятельного создания набора отправляемых данных — без необходимости использовать его скрипты.
Например, у Facebook есть очень большая и сложная клиентская библиотека, которую нужно загружать при работе с их пикселем. Цель библиотеки — дать возможность общаться с серверами Facebook с помощью очереди команд fbq().
К счастью, у Facebook также есть API конверсий, в котором определен формат HTTP-запроса с информацией о конверсиях. Изучив документацию этого API, любой сможет создать собственный поток данных, отправляемый с устройства в серверный контейнер, а затем в Facebook, без необходимости загружать JavaScript.
Важно упомянуть, что существуют сервисы, которые так сильно завязаны на клиентскую сторону, что вы, скорее всего, никогда не сможете запустить их без загрузки JavaScript в библиотеку. Пример — HotJar. Очень интересно посмотреть, как такие сервисы адаптируются к среде серверного добавления тегов.
Техническая настройка
При создании серверного окружения для Google Tag Manager в соответствии с инструкцией будет автоматически создан один стандартный инстанс App Engine.
App Engine — это платформа для управления виртуальными машинами, которая работает в облаке Google. Используя стандартную среду и один экземпляр, вы сможете протестировать настройки Google Tag Manager и, скорее всего, даже не израсходуете бесплатные квоты.
Как только вы будете готовы развернуть новый серверный контейнер в полноценной рабочей среде, вы должны убедиться в максимальной производительности и стабильной работе. Для этого перейдите в настройки App Engine и увеличьте количество инстансов — как минимум, до трех. Так вы увеличите пропускную способность и производительность вашего серверного эндпоинта и гарантируете, что он выдержит входящую нагрузку. Посмотрите подробную инструкцию по настройке App Engine.
Также вы должны сопоставить пользовательский домен с эндпоинтом. Желательно это должен быть поддомен вашего основного сайта.
Серверный контейнер
Рабочая область серверного контейнера визуально похожа на остальные контейнеры Google Tag Manager.
Основное отличие заключается в новом разделе в левом меню — Clients (клиенты).
Входящий HTTP-запрос — это HTTP-запрос, который отправляется с устройства или браузера пользователя в серверный контейнер.
Исходящий HTTP-запрос — HTTP-запрос, созданный и отправленный тегом, находящимся в контейнере.
Теги
На момент подготовки перевода статьи в серверном контейнере есть восемь тегов:
- тег HTTP-запроса;
- два тега для обработки данных Floodlight;
- два тега для обработки данных Universal Analytics и Google Analytics 4;
- три тега для работы с данными Google Ads.
Также есть набор готовых пользовательских шаблонов, которые можно установить. Пользовательский шаблон тега может быть настроен практически для любого сервиса, который умеет обрабатывать HTTP-запросы.
Триггеры
Предустановленных триггеров мало: «просмотр страницы», «специальное событие» и «специальные».
Серверный контейнер не может быть привязан с произвольными триггерами, как, например, «Нажатие» или «Видео». Вместо этого любые теги, запускаемые в серверном контейнере, будут срабатывать только если клиент укажет им это сделать.
У серверного контейнера также нет событий жизненного цикла контейнера (Page View, DOM Ready и Window Loaded). Он работает все время и не перезапускается при обновлении страницы. Таким образом, нет триггеров, связанных с такими событиями, хотя это не означает, что они не появятся в дальнейшем.
Переменные
Встроенные переменные:
|
Название |
Описание |
Пример |
|
Query String |
Строка входящего HTTP-запроса |
v=1&t=pageview&tid=UA-12345-1… |
|
Request Method |
Метод HTTP-запроса |
GET |
|
Request Path |
Адрес HTTP-запроса |
/collect |
|
Client Name |
Имя клиента, который обрабатывает запрос |
Facebook Client |
|
Container ID |
ID серверного контейнера |
GTM-XXXXXX |
|
Container Version |
Версия серверного контейнера |
QUICK_PREVIEW |
|
Debug Mode |
Вернет true если контейнер находится в режиме предварительного просмотра |
true |
|
Random Number |
Случайное число |
12345 |
|
Event Name |
Значение поля event_name из событийного объекта данных, переданного в контейнер |
page_view |
Эти переменные можно использовать для получения данных о контейнере, анализа информации из входящего запроса и извлечения метаданных о событии, которое произошло.
Настраиваемые переменные:
|
Название |
Описание |
Пример |
|
Cookie Value |
Содержимое первого встреченного cookie-файла с указанным названием |
GA1.2.12345.12345 |
|
Query Parameter |
Содержимое первого встреченного параметра с указанным названием из входящего HTTP-запроса |
UA-12345-1 |
|
Query String |
Строка входящего HTTP-запроса. Аналог встроенной переменной Query String |
v=1&tid=UA-12345-1&t=pageview… |
|
Request Header |
Значение имени заголовка из входящего HTTP-запроса |
https://referrer-page.com/ |
|
Request Method |
Метод входящего HTTP-запроса. Аналог встроенной переменной Request Method |
POST |
|
Request Path |
Адрес входящего HTTP-запроса. Аналог встроенной переменной Request Path |
/j/collect |
|
Client Name |
Возвращает имя клиента, который в данный момент обрабатывает запрос. Вместо этого используйте встроенную переменную |
Universal Analytics |
|
Constant |
Любая строка, которая была указана при настройке переменной |
UA-12345-1 |
|
Event Data |
Значение указанного ключа из событийного объекта данных |
123.123.123.123 |
|
Event Name |
Значение поля event_name в событийном объекте данных, переданных в контейнер. Аналог встроенной переменной Event Name |
page_view |
|
Lookup Table |
Ищет значения, соответствующие указанному регулярному выражению, и заменяет на указанные |
|
|
Random Number |
Случайное положительное целое число. Аналог встроенной переменной Random Number |
123123 |
|
Undefined value |
’undefined’ JavaScript значение |
’undefined’ |
|
Container ID |
Идентификатор серверного контейнера. Аналог встроенной переменной Container ID |
GTM-ABCDE |
|
Container Version Number |
Текущая версия серверного контейнера. Аналог встроенной переменной Container Version Number |
13 |
|
Debug Mode |
Вернет true, если контейнер находится в режиме предварительного просмотра |
false |
Пользовательский домен
Настоятельно рекомендую сопоставить пользовательский домен с эндпоинтом серверного контейнера.
Основная причина — таким образом вы включите эндпоинт серверного контейнера в пространство имен домена первой стороны. Я, например, использую sgtm.simoahava.com как хост серверного контейнера.
Этот пункт особенно важен после появления технологий, которые блокируют отслеживание посетителей, например, интеллектуальное предотвращение отслеживания от Apple. Если вы захотите использовать файлы cookie в запросах, а серверный контейнер размещен в домене, отличном от того, с которого отправляются запросы (не ваш сайт), созданные файлы cookie будут считаться сторонними файлами cookie. Многие браузеры будут удалять такие файлы.
ВАЖНО! В связи с изменениями в ITP вам следует сопоставить домен как недавно подтвержденный поддомен. Таким образом, вам надо будет использовать DNS-записи A/AAAA вместо уязвимого псевдонима CNAME.
Нахождение эндпоинта в пространстве имен домена первого лица означает, что вы можете устанавливать файлы cookie от первого лица. Это позволит избежать сокращения срока действия в Safari (7 дней с момента установки).
Обратите внимание, что технически у вас может быть развернуто больше одного домена в одном приложении App Engine. Это полезно, если у вас есть один серверный контейнер, который обрабатывает запросы из нескольких доменов. Единственная проблема — в том, что некоторые функции серверного контейнера ограничены только одним доменом, например, для какого домена отображается режим предварительного просмотра. Это не помешает сбору данных, но может затруднить использование некоторых функций.
Запросы и ответы
Основной серверного добавления тегов определение Клиентами входящих HTTP-запросов, обработке их тегами, а затем отправке исходящих HTTP-запросов обратно поставщику. После того как сработали все положенные клиенту теги, этот клиент отправляет HTTP-ответ обратно источнику запроса, например, браузеру, устройству или какой-либо другой подключенной службе.
Понимание последовательности важно для понимания того, как работает серверное добавление тегов. «Идеальный» процесс end-to-end — тот, в котором для обработки запроса используется как можно меньше кода на стороне пользователя. Клиенты предназначены для обработки входящих запросов как конкретных, так и независимых поставщиков. Теги создаются для обработки данных о событиях от конкретных клиентов, и в конечном итоге отвечают клиенту независимо от того, был ли исходящий HTTP-запрос успешным или нет.
Самый простой способ определить клиент для входящего запроса — это отследить путь запроса. Например, встроенный клиент Universal Analytics прослушивает запросы, содержащие путь /collect или любую из его перестановок (например, /j/collect или /r/collect). Вы можете создать клиент Facebook, который будет прослушивать путь /fbook. Или создать клиент HotJar, который будет прослушивать запросы по пути /hotjar.
В качестве альтернативы вы можете использовать модель единого потока событий, в которой все запросы отправляются в единый клиент. В этом случае у запросов будет только один путь, например /events, а вы настроите клиент на анализ тела запроса и преобразования его в объект с информацией о событии, который отправится в контейнер.
Какой бы подход вы ни выбрали, всегда нужно помнить: независимо от источника, отправившего запрос, он ожидает получить ответ от серверного контейнера.
По умолчанию ответ представляет собой простой text/html-ответ, но вы можете расширить его, используя следующие API.
-
setCookie — позволяет записывать cookie в заголовке Set-Cookie HTTP-ответа.
-
setPixelResponse — автоматически настроит ответ так, чтобы он имитировал пиксель GIF 1×1 с заголовком, предотвращающим кэширование.
-
setResponseHeader — можно использовать для добавления любых пользовательские HTTP-заголовков в ответ. Пример заголовков: Access-Control-Allow-Origin или Access-Control-Allow-Credentials, которые полезны, например, для preflight-запросов.
Надеюсь, в какой-то момент мы получим больше возможностей для управления запросом. Просто представьте себе клиент, единственная цель которого — очистка входящего запроса от персональных данных, и только потом передача очищенного запроса следующему клиенту.
Клиенты и теги
Тут много говорилось о клиентах и тегах. Но не лишним будет повторить, так как концепция может быть немного непонятной. Особенно если вы привыкли к тому, как работает WEB-контейнер.
Цель клиента — прослушивать входящие HTTP-запросы, анализировать их в единой модели событий, а затем запускать виртуальный контейнер с моделью событий, чтобы теги могли использовать сведения из объекта события для создания запросов к их эндпоинтам.
Поскольку клиенты выполняют основную работу, вы можете начать оптимизировать поток событий, переходя от анализа запросов конкретного поставщика (для этого, например, может потребоваться запуск JavaScript библиотеки в браузере пользователя) к подходу, при котором один поток событий может быть распределен по нескольким несвязанным эндпоинтам.
Клиенты работают в соответствии с приоритетами. Чем выше приоритет клиента, тем быстрее он сможет проверить, соответствует ли запрос его требованиям. «Принять запрос» значит вызвать API claimRequest. Это, в свою очередь, означает, что текущий клиент сообщит всем другим клиентам, что этот запрос его, и он больше не позволяет никакому другому клиенту работать с запросом.
Как только клиент проанализирует запрос и создаст из него объект с данными события, событие отправится в API runContainer. С помощью этого API событие передается тегам для оценки и обработки.
Теги могут быть настроены для запуска множества разных вещей, но, скорее всего, вы в конечном итоге используете комбинацию Event Name или/и Client Name.
Event Name (имя события) — это то, что привнесли в мир веб-аналитики gtag.js, Firebase Analytics и Google Analytics 4.
Существует перечень предлагаемых или предустановленных имен событий, таких как page_view, search и login. Поэтому всегда есть возможность придумать и использовать пользовательское имя события, например, new_level_achieved.
Когда клиент создаст модель события, у нее должно быть имя события. Именно оно в итоге будет показано на экране предварительного просмотра, когда клиент выполнит и определит запрос:
Поэтому, если вы хотите запускать кучу тегов всякий раз, когда происходит событие page_view, независимо от клиента, просто используйте триггер, который проверяет Event Name. Исходите из того, что клиент правильно перехватил входящий HTTP-запрос, проанализировал и преобразовал в объект события, который может быть понят тегом. Чтобы проверить, вы можете использовать режим предварительного просмотра для анализа того, что содержит объект с информацией о событии.
Возможно, вы хотите, чтобы ваш тег срабатывал только тогда, когда клиент Facebook сгенерирует объект события. Это полезно, если тегу требуется пользовательская информация, недоступная в качестве стандартных параметров в объекте события.
Ссылаясь на Client Name (имя клиента), вы можете гарантировать, что тег срабатывает только в том случае, если правильный клиент принял входящий HTTP-запрос, предполагая, что клиент, выполнивший runContainer, также принял запрос (могут быть исключения).
Возможно, вам сложно разобраться в клиентах и тегах, но в галерее шаблонов постоянно появляются шаблоны для работы с разными сервисами, попробуйте поискать нужные вам решения там.
Модель события
Когда клиент анализирует принятый им входящий HTTP-запрос, ему надо определить значения в теле запроса (обычно в строке запроса) и создать объект с информацией о событии, который выглядит примерно так:
Этот объект будет передан в контейнер с помощью API runContainer. Затем теги смогут использовать содержимое его значений в триггерах, например, запускать тег только в том случае, если event_name — это page_view, и они смогут сопоставлять значения в объекте события с исходящим HTTP-запросом, который они отправляют в эндпоинт поставщика.
Чтобы упростить процесс, Google предлагает набор стандартных имен и параметров событий, которых вы должны придерживаться,чтобы объект с информацией о событии, переданный в контейнер, использовался без проблем. Если тегам требуются параметры, не определенные в списке стандартных параметров, они должны иметь префикс x-vendor-. Например, ID подписки Facebook будет x-fb-subscription_id.
Обратите также внимание, что используется snake_case, а не camelCase. Это формат, которого вы должны придерживаться при работе с серверным добавлением тегов.
Вы всегда можете воспользоваться режимом предварительного просмотра, чтобы проверить, какая информация передается в объекте с информацией о событии от любого Клиента. Например, при сборе данных Universal Analytics по Measurement Protocol вы можете увидеть следующее:
В приведенном выше примере используются многие стандартные параметры, такие как client_id, ip_override, page_location и user_agent.
Кроме того, протокол Measurement использует ряд пользовательских параметров, уникальных для Google Analytics, например, x-ga-mp1-vp (размер окна просмотра), x-ga-measurement_id (идентификатор ресурса с Universal Analytics) и x-ga-mp1-plt (время загрузки страницы).
Этот объект события будет обработан тегом Universal Analytics, который разберет все его элементы и соберет запрос, исходящий по Measurement Protocol в Google Analytics. Если объект события собран правильно, тег сможет использовать сокращенный API sendEventToGoogleAnalytics.
Пользовательские шаблоны
Серверное добавление тегов сильно зависит от пользовательских шаблонов. Кроме шаблонов тегов и переменных, пользователи могут создать шаблоны клиентов.
Доступные для этого API описаны в документации. Во многих API, например, runContainer, написано следующее: «Этот API рекомендуется использовать в шаблоне клиента».
Грубо говоря, клиенты должны использовать API, которые принимают, проверяют и анализируют входящие HTTP-запросы, запускают контейнер с объектом данных событий, прослушивают сообщения из тегов, запущенных в контейнере, и, наконец, собирают и отправляют ответ обратно источнику входящего запроса.
Примеры API, которые обычно использует только клиенты:
|
API |
Описание |
|
Принимает запрос, после чего контейнер перестает запускать дополнительные клиенты. |
|
|
Преобразует входящий запрос Measurement Protocol версии 1 в список событий в формате Unified Schema. |
|
|
Преобразует входящий запрос Measurement Protocol версии 2 в список событий в формате Unified Schema. |
|
|
Возвращает список значений всех файлов cookie с указанным названием. |
|
|
Возвращает исходный IP-адрес запроса. |
|
|
getRequest* |
Все getRequest API анализируют какую-то часть входящего HTTP-запроса. |
|
Проверяет, соответствует ли входящий HTTP-запроса v1 протокола Measurement. |
|
|
Проверяет, соответствует ли входящий HTTP-запроса v2 протокола Measurement. |
|
|
Удаляет ответ, заданный другими шаблонами с помощью API изменения ответа. По умолчанию создает пустой ответ с кодом статуса HTTP 200 и без заголовков. |
|
|
Выполняет логику контейнера в контексте события. |
|
|
Создает или удаляет файл cookie с указанными параметрами. |
|
|
Настраивает заголовки ответов так, чтобы они имитировали пиксель GIF размером 1×1. |
|
|
setResponse* |
Все setResponse API изменяют какую-то часть входящего HTTP-запроса. |
Теги обычно используют API, которые анализируют объект с информацией о событии, создают HTTP-запрос к эндпоинту тега и отправляют обратно в контейнер любые метаданные, созданные исходящим запросом, — например, код состояния или сообщение об успешном выполнении.
Примеры API, которые обычно используют только теги:
|
API |
Описание |
|
Возвращает данные о событиях |
|
|
Возвращает название текущего клиента |
|
|
Возвращает значения по указанному пути в данных о событии |
|
|
Отправляет в Google Analytics событие в формате Unified Schema |
|
|
Выполняет HTTP-запрос GET по указанному URL |
|
|
Выполняет HTTP-запрос по указанному URL |
Обратите внимание: вы можете запустить серверный контейнер без единого тега. Все API, предназначенные для использования в тегах, могут запускаться через клиенты. Но это противоречит концепции работы с серверным тегированием.
Пример клиента, запускающего некоторые API:
А вот что делает соответствующий тег:
Как видите, клиент анализирует входящий запрос и отправляет его в виде объекта с информацией о событии в контейнер. Контейнер запускает теги, которые сопоставляют объект с информацией о событии с запросом Measurement Protocol.
Тут Google Analytics немного нестандартный, потому что и анализатор входящих запросов (extractEventsFromMpv1), и диспетчер исходящих запросов (sendEventToGoogleAnalytics) имеют собственные отдельные API. Если вы используете пользовательский эндпоинт поставщика, вам нужно написать свой код, который преобразует входящий запрос в объект с информацией о событии, возьмет объект события и сопоставит его с исходящим HTTP-запросом.
API addMessageListener и SendMessage позволяют тегам и клиентам взаимодействовать друг с другом. Это очень полезно, если вы хотите, чтобы клиент вернул информацию о выполнении тегов в ответе источнику запроса.
Режим предварительного просмотра и отладки
В серверном контейнере, как и у WEB-контейнера, есть режим предварительного просмотра и отладки. Если нажать кнопку Preview («предварительный просмотр») в пользовательском интерфейсе, откроется новая вкладка с интерфейсом предварительного просмотра.
Как и в случае с WEB-контейнером, на вкладке предварительного просмотра отображаются только те хиты, которые отправляет ваш браузер. Экземпляр браузера должен быть тем же, в котором запущен режим предварительного просмотра.
В левом столбце вы видите список всех входящих HTTP-запросов, принял ли их клиент, и создал ли объект с информацией о событии на основе запроса. На скриншоте все запросы collect были сделаны клиентом и преобразованы в объекты с информацией о событии.
После выбора запроса все вкладки в режиме предварительного просмотра будут вести себя так, как если бы вы выбрали Summary. Вы будете видеть, сколько раз тег срабатывал для запроса, но не сможете просматривать переменные или данные о событиях.
По этой причине при каждой отладке следует выбирать объект с информацией о событии (например, page_view), если он доступен.
Вкладка Request (Запрос)
На вкладке Request содержится информацию о входящем HTTP-запросе и ответе, отправленном обратно серверным контейнером. Тут так же будет указано, принял ли клиент запрос.
Первая строка содержит сам HTTP-запрос.
В карточке Client указано, какой клиент принял запрос.
Если нажать на карточку Incoming HTTP Request, откроется окно с подробной информацией о запросе.
В карточке Request указывается метод (Method) запроса (например, GET или POST) и URL-адрес (Reqeust URL), на который был отправлен запрос.
В карточке Request Header перечислены все HTTP-заголовки, присутствующие в запросе, а в карточке Request Body показано, что было отправлено в теле запроса (обычно только в запросах POST).
В разделе Response содержится подробная информация о том, как ответил серверный контейнер источнику, отправившему входящий HTTP-запрос.
Карточка Status Code указывает код ответа, полученный в ответ на запрос. Если запрос выполнен успешно, будет код 200.
Карточка Response Headers содержит заголовки кэша для предотвращения кэширования запроса браузером, и заголовки Set-Cookie, которые записывают cookie для домена с серверным контейнером.
Если у ответа есть тело, оно выводится в карточке Response Body.
Вкладка Tags (Теги)
На вкладке Tags показаны все теги, которые сработали (или не сработали) с выбранным событийным объектом данных.
Как и в WEB-контейнере, можно нажать на карточку тега, чтобы раскрыть окно с его описанием. Тут можно посмотреть, какие значения он отправил, а спустившись в конец — какие триггеры активируют тег.
В карточке есть блок Outgoing HTTP Requests. Нажав на него, вы откроете новое окно с подробной информацией о HTTP-запросе, который отправил тег.
Эту информацию можно использовать для отладки ответа.
Вкладка Variables (Переменные)
На вкладке с переменными будет указано содержимое каждой добавленной в контейнер переменной во время выполнения запроса.
Это полезный список, так как вы можете использовать его для поиска и устранения причин, по которым тег, возможно, не отправил правильные значения в эндпоинт.
Вкладка Event Data (Содержимое объекта события)
На вкладке содержатся все значения, полученные из входящего HTTP-запроса. Вы можете использовать их для анализа вкладки Request, чтобы найти параметры, которые были пропущены или неправильно разобраны.
Вкладка Errors (Ошибки)
На вкладке будет информация об ошибке, если какой-то тег ее создаст.