Как не допустить, чтобы SGTM ставил cookie FPID: чек-лист для privacy-first аналитики в BigQuery

Как не допустить, чтобы SGTM ставил cookie FPID: чек-лист для privacy-first аналитики в BigQuery

При настройке server-side через Google Tag Manager (SGTM) часто появляется cookie **FPID** — она нужна для предпочтительного использования идентификатора в Google Analytics 4 (GA4). По сути, это cookie, которая приходит в **HTTP-ответе от сервера** и помечена как **HttpOnly** (к ней не получить доступ из браузерного JavaScript).

Если цель — белая, управляемая аналитика без сюрпризов в согласиях и учёте, возьмите под контроль FPID и связанный поток данных в BigQuery.

— Определите, где именно выставляется FPID
Проверьте, какой компонент формирует HTTP-ответ (ваш сервер/контейнер). Смысл: понять “источник истины”, чтобы потом управлять настройкой, а не симптомами.

— Включите FPID по умолчанию только там, где это оправдано
Симо Алава рекомендует включать toggle на стороне server-side по умолчанию, но вы включаете его не “из любопытства”, а после проверки: влияет ли это на идентификацию и воспроизводимость данных для вашей модели атрибуции.

— Согласуйте FPID с режимом consent (согласия) и политиками хранения
HttpOnly снижает доступность для клиентского скрипта, но не отменяет необходимость корректной логики согласия: если пользователь не дал разрешение, идентификаторы не должны появляться в ответах/логах.

— Зафиксируйте, что FPID не раскрывается в событиях “как попало”
Проверьте, попадает ли FPID в параметры событий, заголовки или в payload, который улетает в BigQuery. Цель: предотвратить нежелательное распространение идентификатора по системам, где вы его не планировали хранить.

— Настройте в BigQuery контролируемую схему и валидации
Добавьте в DWH правила контроля: “есть ли FPID/какой идентификатор в связке с user_pseudo_id”, и что делать при расхождениях (например, не смешивать потоки разных режимов идентификации в отчётах).

— Проведите инвентаризацию идентификаторов в пайплайне
Сведите в таблицу: какие поля вы используете для связки (cookie/id, pseudo-id, client_id) и где создаётся/обновляется. В 2026 это критично: privacy-first атрибуция вытесняет last-click, и чистота ключей важнее количества.

— Проверьте инкрементальность поведения после изменений
Сделайте небольшой A/B в логике конфигурации (или разнесение по тестовым сегментам) и сравните метрики качества данных в BigQuery: доля событий с нужным ключом, стабильность join’ов, разрыв последовательностей.

когда это пригодится
когда вы переводите tracking на server-side/SGTM и хотите сохранить управляемость идентификаторов, не ломая согласия и связность аналитики в BigQuery.

— @BigQuery4MarketingPro