Server-side трекинг ломается не на сервере, а в трёх точках пайплайна

Server-side трекинг ломается не на сервере, а в трёх точках пайплайна

Схема выглядит просто: браузер шлёт событие, сервер его принимает, дальше уходит postback или в рекламную платформу. На практике всё разваливается, если не зафиксированы три вещи: идентификатор, момент события и правила дедупликации.

Первое — идентификатор. Если вы не храните click ID, fp/hashed email или свой internal lead ID в одном формате, склейка между источниками начнёт плыть. Второе — время. Сервер может принять конверсию позже, чем она случилась, и тогда окна атрибуции у трекера, MMP и рекламной системы разъедутся.

Третье — дедупликация. Один и тот же лид может прилететь из браузера и с сервера, и если нет единого ключа события, вы получите двойной учёт. Отдельно проверьте, где живёт source of truth: в CRM, в трекере или в логике отправки. Если это не определено, спор о «правильных» цифрах будет бесконечным.

Базовый чек-лист простой: хранить исходный click ID, логировать timestamp на входе и выходе, использовать один event_id для всех каналов, отдельно тестировать re-fire, retry и late conversion. Server-side не отменяет потери данных — он лишь убирает часть шума. Чем раньше вы зададите правила маршрутизации, тем меньше сюрпризов в отчётах.