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 безопаснее проектировать поток так, будто любой тег и любой лог прочитают лишнее.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
PII в sGTM: как не слить email, phone и IP в логи, теги и DebugView
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.