Server-side трекинг для PWA: где ломается атрибуция и как это чинить

Server-side трекинг для PWA: где ломается атрибуция и как это чинить

PWA часто выглядит как обычный web, но для трекинга это отдельный режим: один и тот же пользователь может открывать приложение из браузера, из installed shortcut и после офлайна. Если оставить client-side схему, события начинают теряться на стыках: session_id меняется, page_view дублируется, purchase приходит без нормального source.

Что важно передавать в sGTM:
— стабильный event_id для дедупликации Pixel + CAPI
— client_id / user_pseudo_id, если есть
— fbc, fbp и click_id, пока они доступны
— user_agent, IP и timestamp на сервере, а не в браузере
— отдельный флаг для install/open, чтобы не путать первый запуск и обычный визит

Отдельная проблема PWA — storage. В installed-режиме кэш и service worker могут переживать очистку части данных лучше, чем обычная вкладка, но это не значит, что можно полагаться только на localStorage. Нужен серверный fallback: прокидывайте идентификатор пользователя из backend-сессии или из события авторизации, а не из фронтового state.

Если PWA умеет офлайн-буфер, отправляйте в sGTM очередь событий с исходным event_time и признаками задержки. Иначе purchase, который случился без сети, легко улетает в неправильное окно атрибуции.

Практика простая: в PWA сначала проектируете identity и replay-механику, и только потом подключаете теги. Иначе server-side будет честно принимать мусор, но не сможет его склеить.