<b>Server-side трекинг для PWA: где ломается сессия и как не потерять атрибуцию</b>
PWA часто ведёт себя не как обычный сайт: кеш, service worker, быстрые навигации без полного reload и отдельная логика офлайна. Из-за этого client-side события могут приходить рваными: PageView дублируется, Purchase теряется после закрытия вкладки, а `fbp/fbc` не всегда живут так, как ожидает CAPI.
Для sGTM здесь важны 3 вещи:
— передавать стабильный `event_id` для дедупликации Pixel + CAPI;
— сохранять first-party идентификаторы в cookie с корректным `SameSite` и `Secure`;
— не полагаться на `window.onload`: в PWA нужный триггер часто `route change` или кастомное событие приложения.
Если service worker отдаёт страницу из кеша, серверу нужен контекст: `client_id`, `event_time`, `page_location`, `referrer`, `user_agent`, `ip`. Без этого ухудшается матчинг и растёт доля событий без привязки к сессии.
Отдельно проверь офлайн-очередь. События, собранные в PWA без сети, должны уходить на сервер с исходным временем события, а не временем отправки. Иначе атрибуция съедет в сторону последнего касания.
Минимальный чек-лист:
— один источник генерации `event_id`;
— логика сохранения идентификаторов вне volatile storage;
— маршрутизация server-side на уровне маршрута, а не только page load;
— тест на back/forward navigation и кеш service worker.
В PWA выигрывает не тот, кто «отправил больше событий», а тот, кто сохранил их порядок и контекст.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
<b>Server-side трекинг для PWA: где ломается сессия и как не потерять атрибуцию</b>
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.