Server-side tracking для перфоманс-маркетинга: как устроен стек в 2026

Рекламные платформы требуют всё больше сигнала, а браузеры, операционные системы и правила consent отдают всё меньше. Server-side tracking - ответ индустрии: маркетинговые события собираются на инфраструктуре, которой управляете вы, и уходят напрямую в API Meta, TikTok и Google. Это концептуальная точка входа в тему: как устроен конвейер, когда без него не обойтись и какой стек выбрать под вашу воронку.

Что такое server-side tracking

Google определяет server-контейнер как промежуточный эндпоинт между устройством пользователя и эндпоинтами вендоров, находящийся под вашим управлением. Позиция посередине даёт возможность фильтровать, валидировать и менять данные событий до отправки наружу. Один server-контейнер принимает трафик с веб-страниц, мобильных приложений и из CRM, отдельный теговый конвейер под каждую платформу не нужен.

Для медиабаера важны два механических факта. Контейнер - это Node.js-приложение, распространяемое Docker-образом, поэтому живёт в любом облаке. Триггеры внутри срабатывают только по event data: click- и scroll-триггеров на сервере нет, сервер видит запросы, а не поведение на странице.

Server-side tracking против браузерного пикселя

Браузерный пиксель теряет события в предсказуемых местах: сетевые проблемы, ошибки загрузки страницы, обрывы связи на мобильном трафике, ограничения браузеров на трекинг. Meta документирует ровно этот разрыв и именно поэтому рекомендует держать Conversions API рядом с пикселем. TikTok называет ту же причину: Events API возвращает конверсии, потерянные из-за проблем со связью и браузерных лимитов.

Серверный поток несёт и то, чего страница не видит: оценку качества лида, подтверждённые оплаты, статусы возвратов, LTV из CRM. Источники не заменяют друг друга: пиксель ловит мягкие взаимодействия, о которых сервер не узнает. Полный разбор цены, сроков запуска и компромиссов - в материале server-side tracking против браузерного пикселя.

Как устроен конвейер: коллектор, теги, API платформ

Конвейер состоит из четырёх шагов. Браузер или приложение отправляет один HTTP-запрос на событие на ваш эндпоинт. Внутри server-контейнера запрос забирает client: срабатывает первый подходящий по приоритету, остальные для этого запроса не запускаются. Дальше client превращает сырой запрос в event data, данные проходят через теги, триггеры и переменные контейнера. В конце теги собирают payload вендоров и отправляют их по сети уже с сервера.

Из коробки в контейнере предустановлены client и теги для GA4 и Measurement Protocol. Любой gtag.js можно направить в контейнер через опцию server_container_url:

клик по рекламе → лендинг отправляет событие через gtag.js
your-sgtm.example/collect принимает его на first-party сабдомене
подошедший client забирает запрос и извлекает event data
теги собирают payload и отправляют его по сети с сервера
Meta CAPI, TikTok Events API и GA4 получают события

Хостинг, грабли дедупликации и честные ожидания от переезда - в материале миграция на server-side GTM.

First-party контекст: домен, cookie и контроль PII

Направьте сабдомен вашего сайта на тегинговый сервер, и появится first-party контекст. Сервер получает возможность читать и писать HttpOnly cookie, недоступные скриптам страницы, вендоры перестают получать сторонние cookie, а политика CSP может стать строже из-за сокращения внешних эндпоинтов.

Положение в цепочке даёт и рубильник для PII: email и телефоны вырезаются из потока до отправки любому партнёру. Google рекомендует настроить first-party домен и включить production mode до первого продового трафика; без этого дефолтное отладочное поведение остаётся жить на публичном эндпоинте.

Когда server-side tracking обязателен

В iOS атрибуция держится на разрешении. Начиная с iOS и iPadOS 14.5, трекинг и доступ к рекламному идентификатору требуют явного согласия пользователя через App Tracking Transparency, без него идентификатор возвращается нулями. Apple определяет трекинг как связывание данных из приложения с данными других компаний ради таргетинга или измерения рекламы. Важна граница применимости: ATT регулирует приложения, а не веб-пиксели, в воронку она попадает через in-app трафик и мобильную атрибуцию, то есть территорию MMP.

На вебе давление тише: пиксель теряет события из-за сетевых сбоев, а consent-правила оставляют часть аудитории неизмеренной до opt-in. Серверная доставка не отменяет закон о согласии: законное основание по-прежнему нужно, сломанную структуру кампаний она тоже не починит. Зато исчезает тихий недоучёт и появляются постпродажные данные. Сквозной пост-cookie стек разобран в cookieless-атрибуции для affiliate, разделение зон ответственности на апп-стороне - в сравнении MMP и affiliate-трекера.

Стек: sGTM, прямые интеграции, трекеры и MMP

Коллектором в sGTM-смысле и называют server-side tracking, но прямые интеграции работают без него: коммерческие платформы и CRM могут отправлять события в API платформ самостоятельно. TikTok перечисляет маршруты как commerce-партнёров, data-партнёров (CDP, tag manager, CRM) и прямое подключение через API.

Хостинг стартует дёшево: дефолтный деплой одного сервера на GCP почти бесплатен, апгрейд до Cloud Run обходится порядка 30-50 долларов за сервер в месяц (по состоянию на конец 2025), для резерва рекомендованы минимум три инстанса на контейнер. Где кончается трекер и начинается MMP, разобрано в сравнении MMP и affiliate-трекера, вопрос контроля трекинга на Shopify - в материале Shopify GTM против приложения Google и YouTube.

Маршрутизация событий в Meta CAPI и TikTok Events API

Meta CAPI соединяет ваши маркетинговые данные с системами Meta: веб-события, апп-события, сообщения бизнеса и офлайн-конверсии. Серверные события привязываются к dataset ID и обрабатываются как события пикселя или SDK, попадая в тот же механизм атрибуции и оптимизации.

TikTok Events API покрывает веб, апп и офлайн-каналы с настраиваемым объёмом передаваемых данных. Для сайтов TikTok рекомендует включать Events API вторым каналом рядом с существующим Pixel, подключение доступно standalone или через партнёра. Агентствам и платформам с десятками кабинетов адресован Events API Gateway: managed-хост с тенантом на каждый ad account, отдельными токенами и встроенным избеганием дублей по event_id или cookie _ttp. Обе платформы заслуживают отдельных руководств, поэтому полный гид по Meta CAPI и гид по TikTok Events API и пикселю существуют как соседние pillar-материалы.

Redundant setup и дедупликация

Официальная рекомендация Meta - redundant event setup: одни и те же события отправляются и из браузера, и с сервера. Серверная копия добирает то, что пиксель теряет из-за сети и ошибок загрузки страницы, плюс офлайн и поздние конверсии, которые пиксель не видит вообще. Двойной поток держат честным дедупликацией: дубли схлопываются по паре идентичное имя события плюс event_id либо по связке external_id + fbp, Meta просит передавать все эти параметры.

Значения fbp и fbc берутся из браузерных cookie _fbp и _fbc; fbc - это правильно отформатированный Click ID, рекомендация - слать его с каждым серверным событием. Важен и тайминг: события должны приходить в реальном времени или близко к нему, потому что в атрибуции и оптимизации доставки участвуют только сматченные события. Event Match Quality оценивается по десятибалльной шкале в Events Manager. TikTok зеркалит подход с матчингом по event_id или _ttp. Минимальный payload для Meta выглядит так:

{
  "event_name": "Purchase",
  "event_time": 1753526400,
  "event_id": "order-84512",
  "action_source": "website"
}

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

Сторонние cookie в 2026: где на самом деле Chrome

История длиной в два года закончилась тихо. В апреле 2025 Google подтвердил: отдельного промпта про сторонние cookie в Chrome не будет, выбор остаётся в настройках Privacy and Security, а Incognito уже блокирует их по умолчанию (IP Protection тогда планировался на третий квартал). 17 октября 2025 Google объявил о сворачивании большей части Privacy Sandbox из-за низкой adoption: уходят Attribution Reporting API в Chrome и Android, Topics, Protected Audience, IP Protection, Private Aggregation, Related Website Sets, SelectURL, SDK Runtime, On-Device Personalization и Protected App Signals.

Выживает то, что важно для планирования: CHIPS, FedCM и Private State Tokens продолжают жить, а ставку в измерении Google переносит на интероперабельный стандарт Attribution в рабочей группе W3C по приватным рекламным технологиям. Практический вывод для баера от этого не меняется: не закладывайтесь в бюджеты на сторонние сигналы. First-party сбор работает независимо от того, чем кончится браузерная история. Полный пост-cookie плейбук - в cookieless-атрибуции для affiliate.

Чеклист старта

1. Выпишите события, по которым реально оптимизируются кампании, обычно лид и покупка.
2. Поднимите коллектор на first-party сабдомене и включите production mode до продового трафика.
3. Направьте события со страницы через gtag.js с server_container_url или через ваш трекер.
4. Подключите сначала один API, Meta CAPI или TikTok Events API, и проверьте доставку в инструменте событий платформы.
5. Добавьте дублирующий браузерный поток с общим event_id для дедупликации.
6. Две недели следите за Event Match Quality и покрытием событий до подключения новых назначений.

Server-side tracking - это стек, а не одна кнопка. Дальше спускайтесь в материал под свою задачу: сравнение пикселя и сервера, миграция на sGTM, cookieless-стек, разделение MMP и трекера или контроль трекинга на Shopify. Соседние pillar-гайды разбирают API платформ целиком.

сравнение Keitaro, Binom, Voluum и RedTrack.

Sources