Server-side атрибуция: что перенести в GTM Server первым

Server-side атрибуция: что перенести в GTM Server первым

Шаг 1. Аудит точек потери сигнала. Откройте GA4 → Отчёт «Источники трафика» и сравните долю Direct c Organic за последние 90 дней. Если Direct вырос больше 25% — это сигнал, что клиентские идентификаторы (client ID) теряются до загрузки скрипта. Параллельно проверьте consent rate в CMP (баннер согласия): если меньше 60% по EU-трафику, треть сеансов просто не доходит до аналитики.

Шаг 2. Запустите GTM Server. Минимально жизнеспособная конфигурация: контейнер на Cloud Run (App Engine дороже в 2–3 раза при тех же RPS), доменный CNAME типа ss.example.ru, сертификат через автоматический провижинг. Не поднимайте свой сервер — поддержка убьёт бюджет.

Шаг 3. Переведите в первую очередь Conversion API (Meta и VK Ads — раньше назывался пиксель), затем GA4. Сторонние cookie останутся, но потери от ITP и ad-blockers исчезнут. Один и тот же client_id теперь живёт в first-party контексте и совпадает между веб-приложением, CRM и рекламной платформой.

Шаг 4. Включите режим согласия (consent mode) v2 на серверном GTM. При отказе пользователя от cookies отправляйте cookieless-pings — модели конверсии Google закроют пробелы сами. Тестируйте в режиме Debug, сравнивая server vs client события: расхождение больше 5% означает ошибку в маршрутизации тегов.

Шаг 5. Подключите MMM (media mix modeling) как второй слой валидации. Server-side даёт точный сбор данных, MMM — ответ на вопрос «а каналы-то какие вклад внесли». Без второго слоя вы улучшите качество данных, но не поймёте, что с ними делать.

Что сделать на этой неделе: открыть отчёт GA4, зафиксировать baseline по Direct и consent rate, выбрать подрядчика или выделить день на запуск Cloud Run-контейнера. Не пытайтесь перенести всё сразу — Meta CAPI и GA4 закроют 80% ценности миграции.

— @AnalyticsStackRu