<b>Server-side трекинг ломается не в коде, а в логике: 6 мест, где теряются конверсии</b>

<b>Server-side трекинг ломается не в коде, а в логике: 6 мест, где теряются конверсии</b>

Первое слабое место — источник клика. Если вы не сохраняете gclid/fbclid/click_id сразу, потом их уже не восстановить: часть сессий уйдёт в «direct», часть — в чужой канал. Второе — редиректы и промежуточные домены: каждый лишний хоп увеличивает шанс потерять query-параметры или реферер.

Третье — согласие и cookies. Даже при server-side часть сигналов всё равно приходит с браузера, и если их не прокинуть в бэкенд, атрибуция режется по швам. Четвёртое — дедупликация: без общего event_id трекер, CAPI и analytics легко считают одну и ту же покупку как три разные.

Пятое — таймауты и очереди. Если postback идёт с задержкой, окно оптимизации у рекламной системы уже могло закрыться, и вы начинаете обучать алгоритм по запоздалым данным. Шестое — source of truth: пока не решено, кто главный по конверсиям, спор между GA4, MMP и трекером будет вечным.

Проверьте цепочку до запуска: capture → storage → transfer → match → dedupe. Если на любом шаге нет понятного ключа, server-side превращается не в спасение, а в дорогой способ красиво терять атрибуцию.