Session stitching ломается не в GTM, а в том, как вы связываете client-side и server-side

Session stitching ломается не в GTM, а в том, как вы связываете client-side и server-side

Когда Pixel и sGTM отправляют одно и то же событие, проблема не в дубле как таковом, а в идентификаторе сессии. Если у client-side есть свой session_id, а у server-side — свой, дальше начинается «разъезд»: отчёты сходятся по событиям, но расходятся по источникам, времени и конверсии.

Рабочая схема простая:
— генерируйте один event_id на клиенте и прокидывайте его в server event;
— храните session_id в first-party cookie с одинаковым TTL;
— передавайте fbp/fbc, если они есть, но не делайте их единственным ключом;
— на сервере нормализуйте timestamp до одной временной зоны и формата;
— deduplication делайте по связке event_name + event_id, а не по времени.

Отдельно проверьте edge cases: SPA-роутинг, повторную отправку при refresh и back button, delayed events после consent update. Именно там чаще всего появляется «двойная» сессия: клиент уже начал новый визит, а сервер ещё доотправляет старый.

Если нужен стабильный stitching, думайте не о «склейке пикселя и сервера», а о едином наборе ключей: event_id, session_id, user_id, fbp/fbc. Чем раньше они появляются в цепочке, тем меньше ручной чистки в аналитике.