Server-side трекинг ломается не на коде, а на границах ответственности

Server-side трекинг ломается не на коде, а на границах ответственности

Когда клики, события и постбэки идут через несколько систем, самое частое падение — не в интеграции, а в логике: кто хранит source of truth, кто дедуплицирует, кто принимает решение по оптимизации. Если это не зафиксировано до запуска, отчёты начинают расходиться уже на первом нормальном объёме.

Базовый пайплайн обычно выглядит так: браузер или приложение отправляет событие в ваш серверный слой, он добавляет идентификаторы, проверяет consent/cookies, кладёт данные в хранилище и только потом шлёт их дальше в трекер, GA4 или CAPI. На каждом шаге можно потерять gclid, fbclid, event_id или user_id, и тогда атрибуция «плывёт» без видимой ошибки.

Проверяйте 4 вещи:
— есть ли единый event_id для дедупликации;
— сохраняются ли raw-события до отправки;
— совпадают ли окна атрибуции у всех систем;
— есть ли алерт на пустые значения ключевых параметров.

Если в цепочке есть Cloudflare Worker, sGTM или свой API-слой, полезно вести не только финальные конверсии, но и технический лог прохождения события. Тогда видно, на каком хопе пропадает идентификатор, и не приходится гадать между «не сработал пиксель» и «трекер не принял постбэк».

Начинайте не с отправки в рекламную платформу, а с контроля данных внутри своего контура: сначала целостность, потом синхронизация, потом оптимизация.