Server-side трекинг ломается не в коде, а в схеме: 5 узких мест пайплайна

Server-side трекинг ломается не в коде, а в схеме: 5 узких мест пайплайна

Если у вас server-side стоит, а расхождения между трекером, GA4 и рекламным кабинетом не сходятся, проблема обычно в одном из пяти мест: идентификаторы, дедупликация, тайминг, consent и роутинг событий.

— Идентификаторы не переживают переходы между доменом, приложением и редиректами: без stable click_id и event_id атрибуция распадается на куски.
— Дедупликация часто настроена формально: одно событие уходит и как client-side, и как server-side, а система считает оба.
— Тайминг важен не меньше логики: если postback приходит позже окна оптимизации, источник конверсии выглядит «пустым».
— Consent и cookie loss режут часть сигналов, поэтому server-side не магия, а способ вернуть контроль над тем, что вы сами отправляете.

Проверьте цепочку целиком: от клика до postback, от postback до хранилища, от хранилища до кабинета. Сравнивайте не только количество конверсий, но и набор полей в каждом событии: source, timestamp, click_id, event_id, order_id.

Практика простая: сначала рисуете схему событий, потом тестируете дубли и задержки, и только после этого масштабируете трафик. Иначе серверный трекинг превращается в дорогую трубу, которая лишь быстрее переносит ошибки.