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

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

Если смотреть только на пиксель, кажется, что всё просто: клик есть, конверсия есть, событие улетело. Но в server-side пайплайне решение принимает не один скрипт, а связка: источник трафика, ваш сервер и трекер. И любая дырка между ними превращается в расхождение по лидам, ROI и оптимизации.

Сначала проверьте вход: какие параметры реально доходят до сервера, не теряются ли gclid, fbclid, utm, click_id, user_agent и IP. Затем — правила матчинга: по какому ключу событие связывается с кликом, есть ли fallback-логика, что происходит при дубле или пустом идентификаторе. Если матчинг строится только на одном поле, потери неизбежны.

Дальше смотрите на отправку: не режет ли прокси заголовки, не ломает ли очередь повторную доставку, не уходит ли событие раньше, чем сформирован окончательный статус. Отдельная ошибка — считать server-side «истиной», не сверяя его с логами источника и трекера. У них могут быть разные окна атрибуции и разный момент фиксации конверсии.

Схема рабочая только тогда, когда у вас есть лог входа, лог матчинга и лог отправки на каждом этапе. Без них server-side быстро превращается в чёрный ящик, где все уверены, что «событие ушло», но никто не знает, где оно потерялось.