Все о GTM Server Side для начинающих

До сих пор делаете вид, что понимаете, о чем идет речь, когда обсуждают серверное добавление тегов с помощью Google Tag Manager?

Эта статья – детальный гайд по GTM Server Side для начинающих. После прочтения вы поймете разницу веб- и серверного контейнеров, узнаете в чем их преимущества и недостатки, сколько стоит GTM Server side и почему он так необходим.

Меня зовут Александр Игнатенко, я занимаюсь маркетинговой аналитикой – консультирую по настройке и принятию решений с помощью данных в онлайн-маркетинге, а также помогаю с разработкой и внедрением кастомных моделей атрибуции и A/B-экспериментами. Кроме того, я веду телеграм-канал о маркетинговой аналитике «Модель атрибуции».

Для кого эта статья?

Что нужно знать для работы с GTM Server side?

Что такое GTM Server Side и как он работает?

Для чего нужен GTM Server Side и в чем его преимущества?

Сколько стоит GTM Server Side?

Что нужно для установки и настройки серверного GTM-контейнера?

Заключение

Если покопаться, то можно найти массу интересных материалов о server-side tagging в сети. Однако, все они как правило или максимально общи, или рассчитаны на узкий круг зрелых аналитиков и разработчиков. Менее продвинутым пользователям приходится тяжелее – часть терминов и сущностей остается непонятной, а логика работы и бенефиты не настолько очевидны. Это не совсем вяжется с идеологией GTM – «увольнять» прослойку разработчиков из системы управления тегами.

Поэтому и появилась эта статья – FAQ для начинающих о том, как (и для чего) устанавливать server-side-контейнер Google Tag Manager. Его развертывание и запуск – далеко не самая тривиальная задача и она требует от исполнителя наличия вполне конкретных core-компетенций (об этом ниже). Однако разбираться в принципах работы GTM Server Side важно не только аналитикам, но и маркетологам, продакт-менеджерам. В первую очередь – для принятия бизнес-решений, подготовки техзадания и других задач.

То есть – если вы управляете привлечением трафика или разработкой веб-продуктов – вам важно иметь хотя бы общее представление о server-side tagging. Хотя бы на уровне идеологии и логики. Все потому что на сегодняшний день это один из немногих доступных путей подготовиться к внедрению ограничений на использование cookies (об этом дальше). Так что эта статья для вас, если вы:

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

Материал включает в себя теоретическую раскладку о server-side tagging и подробные ответы на популярные вопросы о серверном GTM-контейнере. То есть этот текст для всех любопытных, но он не для тех, кто ищет подробную инструкцию.

Детали о технической тонкостях настройки и запуска серверного контейнера сознательно опущены, поскольку это тема отдельной серии публикаций. Однако те, у кого чешутся руки, в конце статьи могут найти ссылку на инструкцию от Simo Ahava.

Оговорюсь – начинать свой путь в освоении систем управления тегами с этого материала – не самая лучшая идея. И вот почему. Да, интерфейсы Google Tag Manager, Google Analytics и Google Cloud эволюционировали в достаточно комфортные среды, управление которыми интуитивно понятно. Но тем не менее, без базового понимания работы системы управления тегами окунуться в server-side tagging означает поставить себя в условия очень серьезного стресса. Я постарался упростить лексику, снабдил материал доступными комментариями и ссылками на документацию, но и этого может оказаться недостаточно. Поэтому до начала работы убедитесь, что вы или ваш разработчик/аналитик:

Минутка занудной теории – увы, без нее никак. Итак, имплементация Google Tag Manager доступна в двух возможных вариантах:

Использование GTM на стороне клиента (client-side) означает, что сам контейнер (как программный продукт) устанавливается в виде нескольких строк JavaScript непосредственно в код сайта. Что происходит после загрузки страницы? Инициализируется (запускается) и контейнер GTM. Он начинает прослушивать происходящее на этой веб-странице на предмет соответствия предварительно настроенным сущностям (триггерам). Как только он «услышит» знакомое ему условие триггера, которое было выбрано в настройках, GTM активирует так называемый тег – то есть отправит запрос с данными об этом событии на сторону – допустим в Google Analytics, Яндекс Метрику или Facebook Ads.

Например: в веб-контейнере GTM мы настроили тег Google Analytics, который должен отрабатывать при загрузке страницы, и опубликовали контейнер. После этого пользователь загружает страницу нашего веб-сайта, скрипт GTM инициализируется, детектит это событие и отправляет данные о нем непосредственно в Google Analytics. После мы идем в GA и наблюдаем изменения статистики. Так это работает в client-side.

Server-side GTM отличается тем, что данные о взаимодействии с содержимым вашего сайта отправляются не напрямую «третьим лицам» (допустим GA или Метрике), а в облачный контейнер Google Tag Manager. Там эти данные обрабатываются так называемым клиентом (об этом чуть ниже) и уже пересылаются дальше – в сервисы аналитики, рекламные кабинеты и куда бы-то ни было еще.

Иначе говоря – контейнер GTM конфигурируется не в рамках строк JavaScript-кода на вашем сайте, а на облачном сервере. Работает это так: пользователь который загружает страницу, активирует отправку так называемого HTTP-запроса в облачный контейнер GTM, там запрос обрабатывается предустановленным клиентом Google Analytics и уже потом в виде стандартизированного события уходит в ваш счётчик Google Analytics.

Клиент– ключевая сущность GTM Server Side. У нее нет аналогов в веб-контейнере и она служит для предобработки данных. В облачном контейнере может быть несколько клиентов. По умолчанию установлены клиенты Universal Analytics и GA4.

Server-side GTM не подразумевает обязательной одновременной клиентской реализации диспетчера тегов, но она выглядит крайне уместной. То есть контейнерам лучше сосуществовать вместе дабы избежать лишней головной боли с настройкой тегов.

Управление серверным контейнером GTM происходит практически также, как и веб-контейнером – с помощью тегов, триггеров и переменных, хотя есть и свои отличия.

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

У использования серверного контейнера есть несколько преимуществ.

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

Пример такой инициативы – запрет Google на использование 3rd-party cookies в браузере Google Chrome с 2023г. Более подробно последствия этого решения для владельцев сайтов и рекламодателей описаны здесь, но если в двух словах – у тех и у других пропадет возможность получать данные о посетителях с адекватной точностью, так как условные Google Analytics или Яндекс Метрика в контексте вашего продукта – сторонние сервисы, и просто так (без явного согласия юзера) делиться этими данными с кем попало нельзя.

Но если вы отправляете данные с вашего веб-сайта не напрямую в Google Analytics, а в серверный GTM-контейнер, который ассоциирован с вашим же доменом, то вы соблюдаете так называемый first-party context. Это важная разница – если ваш сайт находится на домене mysite.com, а GTM-контейнер скажем на gtm.mysite.com, то информация о посетителях:

а) становится недоступна другим JS-скриптам в браузере;

б) обрабатывается на вашем собственном сервере, а не непонятно где;

в) позволяет вам после предобработки получать статистически верные данные.

Конечно, server-side tagging – это не единственная альтернатива 3rd-party cookies. Но другие или уже в прошлом (как FLOC от Google), или ограничены платформами (SKADNetwork от Apple), или страдают в плане точности от тех же самых ограничений (браузерные localStorage, Fingerprint). Так что, серверный контейнер на текущий момент – лучшее решение для решения 3rd-party-проблемы по соотношению простоты и эффективности.

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

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

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

Происходит это по двум причинам:

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

б) их работа пока что регулируется достаточно слабо.

Используя серверный контейнер GTM, вы осуществляете предобработку данных де-факто самостоятельно и сами решаете, что отправлять в сервисы аналитики, а что нет. Кроме того, вы более свободны в использовании конфиденциальных данных – в случае если пользователь вам это доверил – и можете не бояться их утечки.

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

Стоимость использования GTM-контейнера на стороне сервера целиком и полностью привязана к ценообразованию вашего провайдера. Чаще всего прайс будет производной от загруженности веб-сайта. Посмотрим на стоимость на примере Google Cloud.

Ключевая характеристика, влияющая на использование серверного GTM на Google Cloud – это количество необходимых серверов. Googlе в своей документации рекомендует использовать от 3 до 6 серверов (является настройкой по умолчанию), что позволит обрабатывать 50-200 запросов в секунду. Этого скорее всего с лихвой хватит e-commerce- и издательским проектам средней руки. На сегодняшний стоимость одного сервера с 1 vCPU, 0.5 GB memory, 10 GB disk составляет $40 в месяц.

То есть, исходя из рекомендаций (от 3 серверов), вам необходимо $40 x 3 = $120 в месяц. Для более высоконагруженных проектов стоимость будет расти, но к сожалению калькулятора для быстрого расчета стоимости я так до сих пор и не встретил.

Ну и конечно, если вы только-только создаете проект в Google Cloud, то получите $400 велком-бонуса. Это необходимо учитывать при расчете расходов для установки и запуска серверного контейнера.

Этот раздел – своеобразный чек-лист до начала работы по установке GTM Server Side. Ниже описан необходимый минимум, достаточный для внедрения аналитики вашего ресурса с помощью Google Analytics, GA4 и Google Tag Manager в своей серверной имплементации. Итак, до начала работы вам необходимы:

Это все, что важно знать о внедрении системы управления тегами с помощью сервера. Тонкости реализации, настройки тегов, переменных, изменения DNS-записей, отладки контейнера вы можете подсмотреть в многочисленных инструкциях. Я рекомендую ту, что опубликовал Simo Ahava, однако она не является единственно верной.

Система серверного управления тегами находится в стадии бурного роста, поэтому много в этой статье будет нуждаться в скорых обновлениях. Если вы заметите неточность – напишите об этом в комментарии. Другие мои мысли на тему маркетинговой аналитики можно почитать в моем телеграм-канале «Модель атрибуции».