Session stitching в sGTM: как не раздробить один визит на 3 разных user journey

Session stitching в sGTM: как не раздробить один визит на 3 разных user journey

Главная ошибка: client-side GA4/Pixel живёт на своих cookie, server-side endpoint — на своих. В итоге Purchase уходит с одним client_id, Lead — с другим, а CAPI получает только external_id. Атрибуция выглядит «грязной», хотя события технически дошли.

Минимальный набор для stitching:
— прокидывать client_id / session_id из browser tag в sGTM;
— хранить first-party cookie на домене сайта, не на домене контейнера;
— передавать один event_id в Pixel + CAPI для deduplication;
— не генерировать новый ID на сервере, если browser уже прислал валидный.

Проверка в дебаге: один PageView → один session_id → тот же ID в AddToCart/Purchase → тот же event_id в browser и server copies. Если на редиректах, оплате или SPA-роутинге ID меняется — stitching сломан.

Практический совет: заведите таблицу соответствий browser_id → server_id → user_id и логируйте причину перезаписи. Session stitching чинится не «магией sGTM», а дисциплиной ID на каждом шаге воронки.