Server-side трекинг ломается не на коде, а на стыке пяти точек

Server-side трекинг ломается не на коде, а на стыке пяти точек

Классическая ошибка — считать, что сервер сам «дособерёт» атрибуцию. Нет: он только переносит часть логики с браузера в ваш пайплайн. Если не задать, откуда брать клики, как матчить лид и куда слать postback, данные начнут расходиться между трекером, CRM и рекламным кабинетом.

Проверьте базовую схему:
— единый click_id на входе и в конверсии;
— явное правило дедупликации событий;
— сохранение времени клика и времени лида;
— отдельный лог для потерь: нет cookie, нет consent, нет match;
— fallback, если браузерный идентификатор не пришёл.

Дальше смотрите на транспорт. Server-side не спасает, если запросы теряются на CDN, режутся WAF или уходят с неверным таймаутом. Частая проблема — событие ушло в API, но не дошло до трекера, потому что не было ретрая и контроля ответа. Нужны очереди, idempotency key и алерт на пустые/дублирующиеся отправки.

Последний слой — сверка. Сравнивайте не «все конверсии», а цепочку: клик → лид → подтверждение → postback. Если на одном шаге провал, ищите причину там, а не в отчёте. Иначе команда лечит не источник ошибки, а только красивую цифру в дашборде.

Server-side работает, когда у него есть строгая схема данных, контроль доставки и понятный источник правды.