Server-side трекинг ломается не на коде, а на границах ответственности между сервисами
Если идти без схемы, данные начинают «плыть» в трёх местах: браузер не отправил событие, сервер не дождался id-связки, трекер не нашёл совпадение по click_id. В итоге один источник видит конверсию, второй — сессию, третий — только клик.
Рабочая схема всегда строится вокруг трёх вопросов:
— где рождается источник истины;
— чем связываются клик, сессия и конверсия;
— что считается дублем и кто его режет.
Самая частая ошибка — отправлять всё подряд в один endpoint и надеяться на магию. Нужны отдельные правила для вебхуков, postback и событий из браузера: таймауты, повторная отправка, дедупликация, резервный ключ. Иначе любой сбой в очереди превращается в «потерянный» лид.
Проверка пайплайна простая: сначала рисуем путь события от клика до отчёта, потом искусственно рвём один участок и смотрим, где появляется расхождение. Если без разрыва всё красиво, это ещё не трекинг, а иллюзия.
Лучше один раз описать контракт между системами, чем потом лечить разъехавшиеся отчёты ручной сверкой.
Attribution Deep
@attribution_deep
Server-side трекинг ломается не на коде, а на границах ответственности между сервисами
Этот пост опубликован в Telegram-канале Attribution Deep. Подписаться можно по ссылке: @attribution_deep.