Server Attribution — sGTM, CAPI, Privacy Sandbox

PII в sGTM: как не слить email, phone и IP в логи, теги и DebugView

PII в sGTM: как не слить email, phone и IP в логи, теги и DebugView

В server-side контейнере PII чаще всего утекает не в сеть, а в три места: request logging, переменные, которые прокидывают дальше без фильтра, и debug-события, где в payload случайно лежит raw email или phone.

Правило №1: на входе отделяйте идентификаторы от служебных полей. Raw PII используйте только для хеширования, дальше удаляйте из объекта. Для email/phone — normalize → SHA-256 → передача уже только hash. Никаких concat в query string и никаких “на всякий случай сохраним”.

Правило №2: режьте данные по маршруту. В контейнере заведите allowlist полей для каждого тега: CAPI получает user_data и event_data, аналитический тег — только агрегаты, логгер — минимум без PII. Если нужен debug, логируйте event_name, event_id, status, но не payload целиком.

Правило №3: проверяйте, что не осталось в preview. Ищите raw values в request body, response body, headers, cookies, URL params и custom parameters. Отдельно смотрите на fbp/fbc: это не PII, но их тоже нельзя раздавать всем подряд без причины.

Если у вас нет списка допустимых полей и точки удаления PII после хеширования, утечка — вопрос времени. В sGTM безопаснее проектировать поток так, будто любой тег и любой лог прочитают лишнее.
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.
tech

Свежие посты в категории «Tech Infrastructure»

Все каналы категории →

start

Готовы запустить рекламу через сеть public.tg?

Новый оффер, продукт, GEO, кейс, событие или партнёрский запуск — соберём маршрут под задачу и отдадим медиаплан.

Telegram для медиаплана: @AFFtop_connect. Быстрый тест: $20 за канал, $1000 за пакет по сети.