Session stitching ломается не в sGTM, а на границе client-side и server-side

Session stitching ломается не в sGTM, а на границе client-side и server-side

Если Pixel и CAPI живут раздельно, у вас появляются дубли, дырки и «чужие» сессии. Базовая ошибка — передавать только event_name и timestamp. Для stitching нужен стабильный ключ, который доживает до сервера и обратно:
— event_id для дедупликации Pixel + CAPI
— client_id / ga_session_id для связки сессии
— fbp / fbc, если есть click_id и landing context
— user data: email_hash, phone_hash, external_id

На клиенте генерируйте event_id один раз на событие и прокидывайте его в dataLayer, чтобы и Pixel, и server tag получили одинаковое значение. Если событие собирается через SPA, не пересоздавайте идентификатор при каждом virtual pageview — иначе одна покупка превращается в три разных сессии.

На сервере не пытайтесь «угадать» сессию по IP и User-Agent. Эти поля полезны для enrichment, но не для склейки. Лучше хранить mapping: event_id → client_id → session_id. Тогда можно безопасно объединять Purchase, Lead и AddToCart даже при частичном потере client-side куки. 🔧

Итог простой: stitching строится на общих идентификаторах, а не на магии контейнера. Если у вас есть один event_id на обеих сторонах и понятная схема передачи fbp/fbc, процент дублей падает, а отчёты перестают расходиться между GA4, Meta и внутренней аналитикой.