Client-Side vs Server-Side Tracking

30 октября, 2022

Слышали ли вы когда-нибудь об отслеживании на стороне клиента (Client-Side Tracking) и на стороне сервера (Server-Side Tracking). А про контейнер Google Tag Manager типа Server? Если еще нет, то самое время приступить к изучению новой перспективной технологии и попробовать использовать в своем проекте серверный контейнер диспетчера тегов Google.

Примечание: 28 октября 2022 года  на моем YouTube-канале прошел открытый урок по серверному отслеживанию (Server-Side Tracking) и контейнеру Google Tag Manager типа Server. Посмотреть лекцию можно здесь:

Введение

В Google Tag Manager при создании аккаунта вы можете выбрать один из вариантов платформы:

  • Веб-сайт (для сайтов);
  • iOS (для мобильных приложений на iOS);
  • Android (для мобильных приложений на Android);
  • AMP (для AMP-страниц);
  • Server (для серверных инструментов и измерений).

Целевая платформа

Благодаря описанию контейнеров сразу становится понятно, за что отвечает каждый из них и когда следует применять ту или иную платформу. Кроме одного. Server – самый последний из добавленных в этом списке. Что означает «для серверных инструментов и измерений»? Зачем Google добавил его в диспетчер тегов? В каких случаях его следует использовать? Какие у него преимущества и недостатки? Как он настраивается? И так далее.

Для того, чтобы понять, зачем Google внедрил новый контейнер в Google Tag Manager, необходимо обратиться к фундаментальным процессам и принципам работы счетчиков аналитики.

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

Теги (англ. Tags, иногда пиксель или маячок) — это средства для сбора данных и их обмена между вашим веб-сайтом, мобильным приложением и различными сервисами (например, рекламными инструментами, аналитическими платформами), которые вы используете в повседневной работе. Как правило, тег представляет из себя небольшой фрагмент кода на языке JavaScript, который добавляется на отслеживаемые страницы сайта.

Пример кода Google Analytics

Теги используются для различных целей:

  • сбора данных из веб-браузеров;
  • взаимодействия между различными сайтами (например, для передачи демографических данных об аудитории);
  • интеграции стороннего контента (виджеты социальных сетей, чаты, формы обратного звонка и т.д.);
  • настройки файлов cookie и т.д.

В Google Tag Manager можно поместить разное количество тегов с разным функционалом - Google Analytics, Google Ads, Google Optimize, Яндекс.Метрику, ВКонтакте, myTarget, код от коллтрекинга, онлайн-чата, консультанта и т.д.

Когда вы создаете любой тег через GTM, то устанавливаете прямую связь между веб-браузером пользователя, его устройством (телефоном, компьютером, планшетом) и платформой стороннего поставщика, которую используете в проекте. Например, Google Analytics 4. Используя встроенный тег Google Аналитика: конфигурация GA4, вы даете возможность счетчику аналитики отслеживать действия пользователей на вашем сайте, и отправлять данные о просмотре страницы, когда этот тег загружается.

Тег "Google Аналитика: конфигурация GA4"

Если пользователь на ваш сайт заходит впервые, для него в браузере будут созданы следующие файлы cookie:

  • _ga - позволяет различать пользователей (срок жизни - 2 года);
  • _gid - позволяет различать пользователей (срок жизни - 24 часа);
  • _ga_<container-id> (с идентификатором потока данных) - позволяет сохранять состояние сеанса, включая идентификатор и номер сеанса (срок жизни - 2 года);
  • _gac_gb_<container-id> (с идентификатором потока данных) - содержит данные, связанные с кампанией (срок жизни - 90 дней). После установления связи между аккаунтами Google Analytics и Google Ads размещенные на сайте теги конверсии Google Рекламы будут получать данные из файла cookie, если вы не отключите эту возможность.

Другими словами, с помощью файлов cookie можно идентифицировать конкретных пользователей вашего сайта.

Файлы cookie в gtag.js

Как вы уже знаете, ключевым файлом cookie Google Analytics для интернет-маркетолога является именно _ga, который содержит уникальный идентификатор пользователя.

Уникальный идентификатор пользователя (Client ID, идентификатор устройства) - это метка, состоящая из случайного числа и даты первого посещения пользователем сайта в Unix формате (количество секунд с 1 января 1970 года 00:00:00 UTC), которая сохраняется в основном файле cookie (first-party) в течение 2 лет (по умолчанию).

Пример основного файла cookie (_ga) для сайта osipenkov.ru

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

Если вы используете представление Все данные по веб-сайту (по умолчанию), или же любое новое, которое вы создали для работы (не User ID!), тогда основным параметром в отчете Статистика пользователей в Universal Analytics (GA3) будет являться Идентификатор клиента (на английском он называется Client Id):

Отчет "Статистика пользователей" - Идентификатор клиента (Universal Analytics)

Для ознакомления с информацией по конкретному пользователю необходимо выбрать в списке нужный идентификатор клиента и нажать на него. После этого откроется новая страница с отчетом по конкретному посетителю.

В нем находится более подробная информация о пользователе, которая включает:

  • дату и источник первого посещения (Канал, Источник/канал и Кампания);
  • тип устройства, с которого был осуществлен первый переход;
  • дату последнего посещения;
  • список всех хитов (просмотры страниц, различные события, достижение целей, транзакции), который совершал пользователь на сайте во время сеансов.

Данные по отдельно взятому идентификатору клиента (пользователю)

Вы можете открывать отдельные сеансы, чтобы просмотреть действия внутри них. Хиты также можно разворачивать, чтобы узнать про них подробную информацию.

Пример взаимодействий (хиты) пользователя в рамках одного сеанса (Universal Analytics)

С Google Analytics 4 все точно так же. Перейдя в раздел Исследования и выбрав шаблон отчета Статистика пользователей, вы увидите идентификаторы пользователей/устройств:

Идентификатор экземпляра приложения (Client ID) в методике "Статистика пользователей" (Google Analytics 4)

Выбрав один из них, вы можете «провалиться» внутрь и посмотреть все действия, которые совершал на вашем сайте конкретный пользователь:

Пример взаимодействий (хиты) пользователя в рамках одного сеанса (Google Analytics 4)

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

Таким образом, теги в Google Tag Manager выполняют следующие функции:

  1. они помещают файлы cookie в веб-браузер пользователя, и тем самым позволяют отличать одних посетителей сайта от других;
  2. они позволяют идентифицировать пользователя, который перешел на ваш сайт сегодня, а конверсию совершил спустя неделю после последнего захода, а также увидеть все его действия до покупки и после нее (сеансы + хиты);
  3. они сообщают нам о взаимодействиях, происходящих на веб-странице. Например, пользователь загрузил страницу, прокрутил ее, добавил товар в корзину, оформил заказ и позже совершил транзакцию.

Другими словами, при загрузке страницы сайта одновременно загружается контейнер, срабатывают коды отслеживания, и все данные о взаимодействии отправляются в виде HTTP-запросов в Google Analytics, Google Ads и другие сторонние аналитические системы.

Как выглядят HTTP-запросы?

Когда пользователь переходит на сайт, на котором установлен тег Google Analytics, в его браузере регистрируются различные события. Чаще всего – просмотр страницы (по умолчанию). И каждый раз, когда оно запускается, соответствующий HTTP-запрос отправляется на сервера Google Analytics. Это технология в Google называется Measurement Protocol.

Чтобы своими глазами увидеть HTTP-запрос(ы), который отправляет данные в Google Analytics 4, вы можете выполнить следующие шаги:

  • перейдите на сайт, где установлен GA4;
  • в браузере откройте панель разработчика - вкладка Network (клавиша F12 для Google Chrome). Либо используйте вызов контекстного меню правой кнопкой мыши и команду Просмотреть код:

Просмотреть код в браузере

  • установите две галочки рядом с Preserve log и Disable cache:

Preserve log и Disable cache

Обновите страницу. В таблице начнут появляться строчки с различными запросами и временем их выполнения. Игнорируйте это. В поле Filter введите идентификатор вашего потока данных Google Analytics 4. Он начинается на G-:

Идентификатор Google Analytics 4 в поле Filter

Все сетевые запросы, начинающиеся с collect?v, являются запросами протокола измерений Google. У вас их может быть 1, 2 или больше. Все они передают информацию в Google Analytics через Measurement Protocol. Кликнув по любому запросу из списка, вы должны увидеть полную информацию о нем:

Пример HTTP-запроса

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

Процесс отправки данных в Google Analytics с помощью Measurement Protocol состоит из:

  • строки отправки (transport);
  • строки набора данных с параметрами (payload data). Еще ее называют полезной нагрузкой.

Cтрока отправки (transport) указывает куда и как отправлять данные. Пример:

Она состоит из нескольких частей:

  • метод POST - определяет, как будут отправляться данные на сервер Google Analytics (/mp/collect);
  • google-analytics.com - расположение сервера (HOST), куда будут отправляться данные;
  • адрес конечной точки - URL-адрес, на который вам необходимо отправить итоговый запрос или несколько обращений в запросе (https://www.google-analytics.com/mp/collect).

URL-адрес конечной точки может содержать /collect (одно обращение), /batch (несколько обращений в одном запросе) или /debug (проверка запроса).

URL-адрес конечной точки с collect

Строка набора данных (payload data) содержит набор параметров, передаваемых в запросе. Пример:

Она очень напоминает url-адрес, в ссылке которого после символа ? передаются utm_метки. Только вместо привычных пяти переменных (utm_source, utm_medium, utm_campaign, utm_campaign и utm_term), разделенных между собой символом &, здесь используются другие параметры, которые точно так же отделяются друг от друга амперсандом.

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

Чтобы посмотреть, из каких параметров состоит запрос, перейдите на вкладку Payload:

Вкладка Payload

Вы увидите ваш запрос, разделенный на отдельные строки:

Query String Parameters

Чтобы посмотреть запрос в декодированном (понятном) виде, нажмите на view decoded:

view decoded

Тогда часть значений, содержащая специальные символы (%D0%A1....), будет отображаться в удобочитаемом виде:

Декодированные значения

Каждая строка в запросе — это пара ключ=значение. Например:

То, что идет до знака равно — это ключ, после — значение. Например, ключами могут быть:

  • v - версия Measurement Protocol (для Google Analytics 4 - 2, для Universal Analytics - 1);
  • tid - идентификатор потока данных;
  • cid - уникальный идентификатор пользователя (Client ID);
  • ul - язык браузера пользователя;
  • sr - разрешение экрана.

А их значения:

  • v = 2
  • tid = G-BMPB32GC7T
  • cid = 1623097982 // уникальный идентификатор, Client ID
  • ul = ru-ru
  • sr = 1536x864

Полный список параметров, которые могут передаваться для Google Analytics 4, доступен в официальной документации Google.

Именно в таком виде и передается каждый хит из браузера вашего пользователя (и вашего) в Google Analytics и любой другой аналитический сервис/инструмент. Причем не имеет значения, добавлен тег через Google Tag Manager напрямую или через исходный код страницы без использования GTM. По определенной конструкции HTTP-запрос все равно будет отправлен в стороннюю систему после взаимодействия пользователя с вашим сайтом.

Client-Side Tracking (отслеживание на стороне браузера)

Вся аналитика последние годы была построена на методе сбора данных, который отслеживает данные из веб-браузера пользователя (Client-Side Tracking), то есть на стороне клиента.

Вы могли получать из файлов cookie:

  • URL параметры;
  • источник перехода пользователя (первый и для каждого сеанса);
  • данные об устройстве пользователя (разрешение экрана, язык браузера, User-Agent и т.д.);
  • геолокационные данные (страна, регион, город и т.д.);
  • другие параметры.

На сайте устанавливается контейнер Google Tag Manager. Внутри него интернет-маркетолог размещает различные теги рекламных и аналитических систем (например, Google Analytics, Google Ads, Яндекс.Метрику, ВКонтакте, Meta и т.д.). Когда происходит взаимодействие, браузер отправляет запрос напрямую в сервис (например, в Google Analytics), и если надо, получает от него ответ. Таким образом, взаимодействие происходит между двумя сторонами – браузером пользователя и сторонним сервисом (например, в Google Analytics).

Схематично такое отслеживание выглядит следующим образом:

Традиционное отслеживание без серверного контейнера Google Tag Manager

С конца 2019 года браузеры начали активно блокировать сторонние файлы cookie (third-party, 3rd party). Используя свой внутренний алгоритм интеллектуального отслеживания (ITP), Mozilla первой начала блокировать cookie-файлы для отслеживания действий пользователей в браузере Firefox. В марте 2020 года браузер Safari стал блокировать все сторонние файлы cookie по умолчанию. Google Chrome пока отложил блокировку сторонних файлов cookie до конца 2023 года. Пока они блокируются только в режиме инкогнито.

Настройки файлов cookie в браузере Google Chrome по умолчанию

Помимо блокировки сторонних файлов cookie, некоторые браузеры (Safari) стали устанавливать ограничения на срок жизни основных файлов cookie (first-party) или вовсе блокировать работу самих трекеров (Google Analytics, Яндекс.Метрики, Meta и т.д.).

Часть европейских стран даже внесли изменения в своих законодательствах по защите персональных данных пользователей в интернете, требуя от владельца сайта запрашивать у пользователя перед его посещением разрешение на сбор, хранение и использование полученной информации в рекламных и аналитических целях. Так на свет появились GDPR и TCF v 2.0.

25 мая 2018 года в Евросоюзе вступил в силу общий регламент защиты персональных данных (General Data Protection Regulation, сокр. GDPR), который предоставляет резидентам Евросоюза (ЕС) возможность управлять своими персональными данными - спрашивать у компаний цель сбора и обработки информации, месте хранения, а в случае необходимости, сделать запрос на ее удаление. Под такие данные попадают IP-адреса, идентификаторы устройств, данные о местоположении и файлы cookie.

В результате, все компании, которые обрабатывают личные данные пользователей, находящихся на территории ЕС, обязаны соблюдать GDPR. И это вовсе не значит, что соблюдение регламента не распространяется на российские компании. Напротив, требования GDPR имеют отношения к компаниям в любой стране, деятельность которых направлена на физических лиц в ЕС.

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

Примерно за месяц до GDPR Европейское бюро интерактивной рекламы (IAB Europe) с целью единообразия в процессе сбора данных разработало стандарт Transparency and Consent Framework (сокр. TCF), позволяющий получать согласие от пользователей и делиться им с остальным партнерами - издателями (publishers), поставщиками технологий (vendors, такие, как DSP, SSP, DMP, рекламные серверы и т.д), агентствами и рекламодателями.

Эти нововведения привели к тому, что стали появляться так называемые CMP-провадейры (Consent Management Platform) - специальные сервисы, которые мы как владельцы сайтов, можем использовать для:

  • запроса, получения и хранения согласия пользователей (благодаря всплывающему окну);
  • настройки конфиденциальности пользователей (пользователь сам выбирает, какими данными он разрешает поделиться);
  • хранения списка поставщиков технологий из глобального списка поставщиков (Global Vendor List);
  • обновления информации о согласии (если пользователь вдруг решил изменить свой выбор).

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

Окно согласия (пример Cookiebot)

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

Примечание: в сентябре 2020 года Google анонсировал свой режим согласия – Google Consent Mode.

Не стоит забывать про одну из самых и не менее актуальных проблем – блокировщики рекламы. Расширения для браузеров типа AdBlock или Ghostery позволяют на уровне браузера блокировать различные трекеры (Google Analytics, Яндекс.Метрики, Meta и т.д.).

Пример заблокированных трекеров (расширение Ghostery)

Это означает, что HTTP-запрос не будет отправлен на сервер стороннего сервиса и данные в него не передадутся и не отобразятся. Самый простой способ проверить это – использовать консоль разработчика и уже известную вам вкладку Network, на которой в поле Filter введите collect?v или google-analytics (для Google Analytics):

Пример заблокированного запроса Google Analytics 3 (Google Chrome)

Если он был заблокирован блокировщиком рекламы, то либо он вовсе не отобразится, либо запрос должен подсвечиваться красным цветом, как на рисунке выше. В некоторых браузерах на вкладке Console можно увидеть дополнительную информацию по блокировке.

Например, вот так это может выглядеть если в качестве блокировщика используется расширение Ghostery:

Консоль разработчика - Console (Ghostery заблокировал все счетчики)

Блокировка основных файлов cookie (first-party) приведет к тому, что:

  • данные в разных аналитических системах буду различны. Один браузер заблокирует счетчик Google Analytics, но не заблокирует Яндекс.Метрику. В результате пользователь в Метрике засчитается, а в Analytics не попадет;
  • увеличится количество «новых пользователей», станет больше direct / none трафика, уменьшится цепочка касаний;
  • рекламные кампании будут оцениваться по последнему клику (Last Click);
  • когортный анализ будет ограничен;
  • вектор работы маркетолога будет направлен на сбор телефонов, e-mail адресов для ретаргетинга и текущей базой клиентов (CRM-маркетинг);
  • аналитика в компании будет строиться вокруг идентификации пользователей по User ID (на авторизации и личном кабинете), а не по Client ID.

Блокировка сторонних файлов cookie (first-party) в ближайшем будущем может привести к тому, что:

  • рекламным площадкам будет сложнее таргетировать рекламу, а стоимость привлечения клиента для рекламодателя будет расти;
  • уменьшится охват ретаргетинговых кампаний и look-alike аудиторий;
  • сократиться количество рекламных платформ и их возможности (аудитории, интересы);
  • крупные компании (Apple, Meta, Google, Яндекс) пострадают в меньшей степени, поскольку у них есть целые экосистемы (десятки и сотни сервисов, платформ) с которых они собирают first-party данные.

Еще одна скрытая проблема, о которой задумается небольшое количество интернет-маркетологов – это безопасность собственных данных. Устанавливая различные скрипты к себе на сайт через Google Tag Manager, можете ли вы быть на 100% уверены в том, что ваши данные не передаются третьим лицам? Что эти скрипты передают только ту информацию, о которой было заявлено в пользовательском соглашении, и они работают именно так, как изначально заявлено в документации разработчика? Ваши данные не защищены, а это значит, что вы не можете передавать этим способом конфиденциальную информацию с сайта, например, e-mail, телефон, адрес пользователя и т.д., поскольку существует вероятность ее перехвата.

Несмотря на все недостатки, Client-Side Tracking (браузер пользователя <-> сторонний сервис) на данный момент является самым распространенным способом сбора данных на вашем сайте, поскольку такое отслеживание легче настроить (нужно просто скопировать и разместить на страницах сайта готовые фрагменты кодов рекламных и аналитических систем), не требует дополнительных затрат, привлечение сторонних специалистов, а также его проще протестировать и отладить с помощью стандартных инструментов.

Например, вот так выглядит стандартный запрос на отправку события page_view (просмотр страницы) вместе со всеми необходимыми параметрами для тега Google Analytics 4 в режиме предварительного просмотра обычного контейнера Google Tag Manager Веб-сайт:

Пример запроса для Google Analytics (режим отладки GTM)

Несколько лет назад появился новый способ отслеживания данных – Server-Side Tagging, а Google Tag Manager анонсировал новый контейнер – Server.

На зарубежных сайтах и порталах уже достаточно много написано про такое отслеживание и про сам серверный контейнер GTM. Появились даже отдельные проекты (стартапы и SaaS-платформы), позволяющие упростить процесс настройки серверного отслеживания благодаря готовым решениям. А вот русскоязычные ресурсы, к сожалению, пока не могут похвастаться даже материалами про sGTM. Определенный отпечаток накладывают и текущие события в мире, где каждый день все меняется по несколько раз, и неизвестно, будут ли продукты Google в обозримом будущем востребованы и использоваться в проектах на территории Российской Федерации.

Server-Side Tracking (отслеживание на стороне сервера)

При отслеживании данных на стороне сервера (Server-Side Tracking) между браузером пользователя и сторонним сервисом добавляется промежуточная точка – сервер. Таким образом, сначала со стороны клиента идет запрос на этот сервер, затем этот сервер обрабатывает текущий запрос от клиента и определенным образом отправляет информацию в сторонние системы (например, в Google Analytics, Google Ads и т.д.). То есть вместо браузера пользователя запрос выполняет сам сервер.

В качестве такого сервера Google предлагает использовать облачные решения Google Cloud Platform (не является обязательным условием, могут быть и другие) и целевую платформу Google Tag Manager типа Server, что позволяет настроить один поток данных от клиента и сократить количество прямых обращений к разным сторонним сервисам.

Server-Side Tracking - альтернатива привычному методу отслеживания на стороне клиента, которая позволяет решить проблему с блокировщиками рекламы, передачей конфиденциальных данных и скоростью загрузки страниц.

Схематично такое отслеживание выглядит следующим образом:

Отслеживание с серверным контейнером Google Tag Manager

Ключевыми особенностями новой технологии является то, что запросы обрабатываются на стороне сервера, поэтому блокировщики рекламы, ITP, ETP или прерванное соединение никак не влияют на качество ваших данных. Server-Side Tracking является более защищенным методом, чем Client-Side Tracking. Вы можете не переживать за конфиденциальность данных ваших пользователей и передавать с сайта, например в Google Analytics, такую важную информацию, которую не хотели бы отправлять на стороне клиента (например, хешировать e-mail адреса, редактировать IP-адреса и при необходимости удалять строку User Agent из обращения). Пользователи вообще не будут видеть запросы, которые будут отправляться, как это было в случае с HTTP-запросами, где все данные видны в консоли разработчика и могут быть легко перехвачены.

Перенеся обработку запросов с клиентского браузера на сервер (облако), вы самостоятельно осуществляете предобработку данных и сами решаете, что отправлять в сервисы аналитики и рекламы, а что нет. Server-Side Tracking ускоряет работу вашего сайта за счет меньшего количества установленных на сайте или в приложении тегов. Меньше кода выполняется на стороне клиента – быстрее все загружается.

Server-Side Tracking – это не новый продукт и технология Google. Другие компании тоже имеют решения такого типа. Meta (Facebook) в 2020 году  стал  предлагать использовать своим пользователям отслеживание на стороне браузера Facebook API Conversions (CAPI) примерно в то же время, когда Google выпустил свой контейнер GTM - Server. Все эти изменения произошли после обновлений Apple в iOS 14 версии и выше.

Настройка API Conversions может происходить тремя способами:

  1. с помощью готовой интеграции партнеров (Zapier, WordPress, WooCommerce, Shopify, Makeshop, Magento, Google Tag Manager);
  2. с помощью шлюза API Conversions (требуется Amazon Web Services, Google Tag Manager не нужен);
  3. ручная настройка (самостоятельная реализация API).

Принцип работы Facebook API Conversions (API Gateway)

Как и любая другая технология, отслеживание на стороне сервера имеет свои недостатки. Во-первых, для внедрения Server-Side Tracking в общем случае и контейнера Server (GTM) в частности необходимо привлекать сторонних разработчиков для настройки самого сервера. Это дополнительные затраты. Во-вторых, вероятнее всего, вы не будете «поднимать» свой собственный сервер с нуля, а воспользуетесь готовыми решениями. Google предлагает использовать их инфраструктуру Google Cloud Platform (GCP). Поскольку с арендованного сервера будут отсылаться запросы с определенной периодичности, то за них вам так же нужно будет платить. Это еще одни расходы. Хоть в официальной документации Google и написано, что развертывание проекта в GCP с одним сервером в большинстве случаев бесплатно, сама компания рекомендует использовать для каждого контейнера как минимум по три сервера, чтобы сократить риск потери данных в случае сбоя одного из них.  Таким образом, количество серверов может составлять от 3 до 6 (настройка по умолчанию). Один сервер стоит 40$ / месяц. Исходя из рекомендаций, вам необходимо $40 x 3 = $120 в месяц. Для высоконагруженных проектов стоимость будет выше. Каждый такой сервер - экземпляр App Engine в гибкой среде с конфигурацией 1 vCPU, 0.5 GB memory, 10 GB disk.

Примечание: с приходом Server-Side Tracking и контейнера Server на рынке появились различные сервисы, предоставляющие как и аренду собственных мощностей, так и помощь в настройке и развертывании отслеживания на стороне браузера. Подробнее о таких инструментах будет написано далее.

В-третьих, для тестирования и отправляемых с сервера данных для интернет-маркетологов пока нет привычных инструментов отладки, а сам процесс занимает больше времени. Ну и наконец, одна из самых ключевых проблем (если не главная) – это отсутствие у некоторых систем использования тегов, доступных для отслеживания на стороне сервера.

Именно поэтому Server-Side Tracking, хоть и является новой и перспективной технологией, он по-прежнему не так популярен и востребован на массовом рынке. Только крупные компании, имеющие соответствующие компетенции, штат сотрудников, финансовые ресурсы, возможности реализации, желающие более высокую точность данных и понимающие экономическую эффективность перехода с Client-Side на Server-Side, уже осуществили внедрение или находятся на этапе принятия такого решения.

Если вы не уделяете конфиденциальности должного внимания (или по крайней мере еще не задумывались об этом), для вас не так важна точность данных в силу их небольшого количества, вы не гонитесь за нововведениями (трендами) в аналитике, не желаете иметь дополнительную статью расходов по аренде облачного решения, и вы только-только начали осваивать работу с обычным контейнером Google Tag Manager и отслеживание на стороне клиента, то в усложнении и так не самых простых процессов нет никакой необходимости.

Контейнер Server

В 2020 году в Google Tag Manager появился новый тип контейнера – Server. Он предназначен для отслеживания взаимодействия пользователей на стороне сервера, а не браузера.

Контейнер Google Tag Manager типа "Server"

Его управление происходит практически так же, как и в обычном контейнере типа Веб-сайт - с помощью переменных, триггеров и тегов. Хотя в них есть и свои различия. Какие? Разберем в отдельном материале.

Получайте бесплатные уроки и фишки

По контекстной, таргетированной рекламе и аналитике