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

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

В PWA часто нет нормального reload-паттерна: пользователь открывает приложение, переходит между экранами без полной перезагрузки страницы, а client-side теги видят только часть истории. Поэтому sGTM здесь нужен не «для красоты», а чтобы собрать события в один поток и не потерять Purchase, Lead или add_to_cart.

Ключевая специфика:
— отправляйте событие не только из view, но и из app-router переходов;
— передавайте стабильный <code>event_id</code> для дедупликации Pixel + CAPI;
— храните first-party идентификатор в cookie или localStorage и поднимайте его на сервере;
— для авторизованных пользователей используйте email/phone hash, но только после нормализации.

Отдельная боль — offline/online стык. В PWA событие может родиться без сети и уйти позже. Если вы шлёте его напрямую в vendor API, атрибуция разваливается. Лучше буферизовать payload на клиенте, а серверу отдавать уже собранный пакет с временем исходного действия, IP, User-Agent и click_id, если он есть.

Ещё один частый анти-кейс: тег срабатывает только на первом открытии, а затем PWA живёт внутри одного shell. Проверка простая — сравните число route-change events и число server hits. Если разрыв растёт, проблема не в CAPI, а в том, что вы слушаете не тот источник событий.

Вывод простой: для PWA проектируйте трекинг как event stream, а не как набор pageview-ов. Тогда sGTM перестаёт быть «пожарной трубой» и начинает реально держать атрибуцию.