Session stitching ломается не из-за пикселя, а из-за разъезда идентификаторов между клиентом и сервером

Session stitching ломается не из-за пикселя, а из-за разъезда идентификаторов между клиентом и сервером

Когда browser-событие и server-событие живут в разных сессиях, вы получаете дубли, провалы в атрибуции и странные расхождения между GA4, CAPI и BI. Обычно проблема не в «потере данных», а в том, что не совпали ключи: event_id, session_id, client_id, fbp/fbc.

Что должно совпадать:
— event_id: один и тот же для Pixel и CAPI, иначе дедупликация не сработает
— session_id: прокиньте его из client-side в sGTM и дальше в backend
— client_id / user_pseudo_id: нужен как стабильный мост для аналитики
— timestamp: сервер не должен «уезжать» сильно дальше окна сессии

Практика простая: client-side генерирует event_id и session_id, кладёт их в first-party cookie или dataLayer, а сервер забирает и ретранслирует без пересборки. Если на сервере вы создаёте новые идентификаторы, stitching превращается в угадайку. Для GA4 отдельно проверьте, что session_start не плодится повторно при server hit.

Финальный чек: одно событие — один event_id, одна сессия — один session_id, и одинаковая логика на всех точках отправки. Если это соблюдено, дедупликация и отчёты перестают спорить между собой.