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

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

Когда данные идут через браузер, сервер, трекер и рекламную сеть, теряется не только cookie, но и логика сверки. Главная ошибка — считать server-side «магической кнопкой»: он не восстанавливает всё, он просто переносит точку сбора ближе к источнику события.

Перед внедрением проверьте 4 вещи:
— кто формирует event_id и где он живёт;
— чем матчится клик: click_id, fbp/fbc, hashed data, собственный uid;
— где стоит дедупликация: на вашем сервере, в трекере или на стороне платформы;
— какой канал является source of truth для каждого события.

Если эти роли не разделить, начнутся типовые баги: дубли конверсий, потеря части лидов, разные суммы в трекере и в кабинете, «пустые» события без привязки к кампании. Чаще всего проблема не в транспортировке, а в том, что один и тот же сигнал пытаются использовать для атрибуции, дедупа и аналитики одновременно.

Хорошая схема server-side — это не максимум интеграций, а минимум неопределённости. Сначала опишите пайплайн на бумаге: от клика до postback, с точкой генерации идентификаторов и правилами отказа. Потом уже подключайте передачи событий и сверяйте логи на каждом шаге.