Server-side трекинг

Что такое server-side трекинг

Server-side трекинг это схема, при которой браузер посетителя отправляет данные не напрямую в Google Analytics, Google Ads и Meta, а сначала на ваш собственный сервер. Там события обрабатываются и уже оттуда уходят в нужные системы. Обычно для этого используется серверный контейнер Google Tag Manager, развёрнутый в облаке и подключённый к поддомену вашего сайта, например data.вашсайт.pl.

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

Какие проблемы это решает

Первая проблема: потеря данных. Блокировщики, ограничения Safari и Firefox, особенности iOS приводят к тому, что часть заявок и покупок не доходит до рекламных систем. Для небольшого бизнеса с парой заявок в день это почти незаметно. Для магазина с сотнями заказов и большим бюджетом это означает, что алгоритмы Google и Meta учатся на неполной картине и тратят деньги хуже.

Вторая проблема: контроль. Когда на сайте десять сторонних скриптов, каждый может собирать больше, чем нужно. На сервере видно каждое поле, которое уходит наружу, и лишнее можно удалить. Для бизнеса в ЕС это удобно и с точки зрения RODO: проще показать, какие данные куда передаются.

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

Когда server-side окупается

Честно: большинству малых бизнесов, с которыми я работаю, server-side на старте не нужен. Сначала нужна нормальная базовая настройка GA4 и GTM с правильными событиями и согласием. Сервер имеет смысл, когда:

• рекламные бюджеты заметные и растут;
• продаж много, и алгоритму нужны точные данные для оптимизации, особенно в кампаниях вроде Performance Max;
• в Meta нужен Conversions API, и проще отправлять его с того же сервера;
• вы хотите точно контролировать, какие данные покидают сайт.

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

Согласие и RODO

Важно понимать, чего server-side не делает. Он не отменяет согласие на cookies. Если посетитель отказался от рекламного отслеживания, серверная схема должна это учитывать так же, как браузерная. Я передаю статус согласия из баннера и Consent Mode v2 на сервер, и теги там срабатывают по тем же правилам. Использовать сервер, чтобы «обойти» выбор человека, нарушение, которое может дорого стоить. Подробнее на странице Consent Mode v2.

Что нужно для запуска

Облачный аккаунт на ваше имя, где будет работать сервер, доступ к DNS вашего домена для подключения поддомена, доступ к Tag Manager и рекламным кабинетам. Хостинг сервера оплачивается отдельно провайдеру, сумма зависит от трафика. Всё, что я настраиваю, принадлежит вам, и при смене подрядчика ничего не теряется.

Сервер и CRM

Серверная схема хорошо сочетается со связкой с CRM. Когда сделка в CRM переходит в статус «оплачено», это событие можно отправить через тот же сервер в Google Ads и Meta. Рекламные системы узнают о реальных продажах, а не только о заявках. Это уже уровень сквозной аналитики, и для бизнеса, где продажа происходит после звонка, именно он даёт самую большую отдачу.

Частые заблуждения

Server-side часто продают как волшебную кнопку, которая «вернёт все потерянные конверсии». Это не так. Часть данных теряется не из-за браузеров, а из-за отказа от cookies, и это правильно. Часть потерь вызвана плохой базовой настройкой: неправильные события, задвоенные теги, отсутствие Consent Mode. Сервер не исправит ошибки в логике, он только надёжнее доставит то, что вы ему дадите. Поэтому перед запуском я всегда проверяю основу, а иногда начинаю с аудита аналитики.

Сверка до и после

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