Session stitching между client-side и server-side ломается в 3 местах: как не потерять цепочку

Session stitching между client-side и server-side ломается в 3 местах: как не потерять цепочку

Когда Pixel и sGTM живут в одном аккаунте, проблема редко в отправке события. Чаще рвётся связка между pageview → add_to_cart → purchase: у клиента один session context, у сервера — другой. Если не склеить их заранее, атрибуция начинает дробить путь на куски, а дедупликация работает только формально.

Что проверять в первую очередь:
— Один и тот же event_id у client и server события
— Единый session_id для всех хитов внутри окна сессии
— Передачу fbp/fbc, client_ip, user_agent без пересборки на сервере
— Нормализацию времени: UTC, без ручных сдвигов между фронтом и бэком

Если session_id живёт только в браузерном storage, он легко теряется на SPA-роутах, редиректах и после consent-баннера. Надёжнее: генерировать его на первом hit, прокидывать во все dataLayer events и дублировать в server payload. Тогда sGTM может склеить цепочку даже при частичной потере client-side данных.

Отдельный анти-кейс: разные таймстемпы у client и server при одном event_id. Дедупликация может сработать, но session stitching сломается — Purchase окажется в другой сессии, а отчёт по пути конверсии станет мусорным.

Итог: сначала унифицируйте event_id, session_id и timestamp, потом уже оптимизируйте match keys. Иначе вы чините не атрибуцию, а только видимость событий.