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

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

Если собрать server-side «на скорую руку», данные начинают расходиться уже на первом шаге. Чаще всего ломаются не отправка события как таковая, а идентификатор пользователя, порядок обработки и дедупликация между источниками.

1. Клиент не передал стабильный ключ: click_id, fbp/fbc, email_hash или собственный user_id. Тогда серверу нечем связать клик, сессию и конверсию.
2. Событие уходит без idempotency key или event_id. В итоге ретраи, повторы и дубль-конверсии.
3. Не зафиксированы таймзоны и задержки. Один источник пишет по времени сервера, другой — по времени браузера, и атрибуция «плывёт».
4. Нет единого правила приоритета: трекер, GA4, CAPI и CRM считают одну и ту же заявку по-разному.

Проверьте пайплайн так: сначала источник клика, потом серверный лог, затем постбек и только потом отчёт в трекере. Если где-то нет сквозного id, поиск проблемы начинается не в рекламе, а в передаче данных ⚙️

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