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

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

Если собрать пайплайн «клик → лендинг → сервер → трекер → postback», уязвимы обычно не интеграции, а точки передачи идентификаторов. Потерялся click_id — и дальше события живут как будто в разных мирах.

Проверьте три вещи:
— где именно создаётся источник истины: на клиенте, на сервере или в трекере;
— какие поля уходят дальше вместе с событием: click_id, gclid, fbclid, fbp, fbc, order_id;
— есть ли у каждого события стабильный ключ для дедупликации.

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

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