Server-side tracking: что это и чем отличается от обычного пикселя

Server-side tracking: что это и чем отличается от обычного пикселя

Когда говорят про серверную аналитику, чаще всего имеют в виду **server-side tracking** — передачу данных о событиях не напрямую из браузера пользователя в рекламные системы, а через промежуточный сервер. Схема выглядит так: клик или просмотр попадает на ваш бэкенд, там обогащается данными из CRM, внутренней аналитики и оффлайна, и только после этого уходит в Facebook, Google, TikTok через их Conversion API (CAPI) или аналоги.

Главное отличие от привычного пикселя — точка сбора события. У классического client-side пикселя (JavaScript в браузере) событие фиксируется в браузере посетителя. У server-side — на вашей стороне, до захода в рекламный кабинет. Браузерные ограничения, блокировщики, ITP (Intelligent Tracking Prevention — механизм Safari, ограничивающий сторонние cookies), отсутствие cookies в third-party контексте на это уже не влияют: вы отправляете событие сами, со своего домена, с авторизованным доступом к API платформы.

**Чем server-side отличается от CAPI.** Conversion API — это конкретный протокол отправки конверсий (например, у Meta). Server-side tracking — более широкая архитектура: вы можете поставить между сайтом и рекламной сетью контейнер (часто Google Tag Manager Server-Side, но не обязательно), маршрутизировать запросы, фильтровать и обогащать их. CAPI — один из способов доставки, а не синоним всей конструкции.

**Типичные ошибки применения:**

— Дублирование событий. Пиксель продолжает слать конверсию, плюс CAPI шлёт ту же — платформа видит двойное событие и завышает отчётность. Правило: либо pixel + dedup window с одинаковым event_id, либо полный переход на server-side с выключенным browser pixel.

— Отправка «сырых» событий без обогащения. Если вы просто перекладываете pageview на сервер — смысла мало. Ценность появляется, когда к событию добавляются user_id, LTV-сегмент, статус сделки, источник обращения в оффлайне.

— Игнорирование consent (согласия пользователя). Перенос сбора данных на сервер не отменяет требования GDPR/ФЗ-152: сигнал о согласии должен передаваться вместе с событием.

— Ожидание мгновенного роста ROAS. Server-side решает проблему потери данных, а не плохих креативов или слабого оффера. Без нормальной воронки эффект будет только на точность замера, но не на сам результат.

**Пример.** Интернет-магазин с чекаутом на собственном домене. Браузерный пиксель Meta фиксирует 40% реальных покупок из-за ITP и ad-block. После подключения CAPI через server-side контейнер и дедупликации по event_id доля зафиксированных покупок вырастает до 92%. Алгоритм получает полную картину конверсий, оптимизация под lookalike (похожую аудиторию) работает на неискажённых данных, и через две недели CPA (стоимость привлечения клиента) снижается на 18% — не потому что выросло качество трафика, а потому что модель перестала «слепнуть» на части аудитории.

Server-side — это не магия и не способ обойти privacy-ограничения. Это инфраструктурный сдвиг: контрольная точка сбора данных переезжает с браузера пользователя на ваш сервер. Для маркетолога-инженера это значит, что аналитика перестаёт быть зоной ответственности маркетинга отдельно от разработки — пора договариваться с backend-командой о единой схеме событий.

— @AdOpsRoom