Server-side трекинг ломается не на коде, а на схеме: 5 точек, где теряются события

Server-side трекинг ломается не на коде, а на схеме: 5 точек, где теряются события

Первый провал — нет понятного source-of-truth. Если GA4, трекер и CAPI считают одно и то же по-разному, сначала фиксируйте, кто главный для оптимизации, а кто — для сверки.

Второй — слабая связка идентификаторов. Нужны как минимум click_id, client_id и server_event_id; без них дедупликация превращается в угадайку. Третий — тайминг: если событие уходит на сервер позже клика слишком далеко, окно атрибуции начинает «плыть» и источники расходятся.

Четвёртый — cookie/consent-логика. Когда consent не передан в серверный пайплайн, часть событий уходит в серую зону: в одном месте они есть, в другом — нет. Пятый — отсутствие тестового контура: без ретраев, логов и контроля статусов вы не понимаете, где пропало событие — в браузере, на воркере или у конечного API.

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