PII в sGTM нельзя «просто хешировать»: сначала надо решить, где и зачем она живёт

PII в sGTM нельзя «просто хешировать»: сначала надо решить, где и зачем она живёт

Если в server-side контейнер прилетает email, phone или external_id, ошибка обычно не в SHA-256. Ошибка в том, что PII начинает гулять между тегами, логами и debug-панелью без границ.

Базовый паттерн:
— принимаете сырые поля только на входе;
— сразу нормализуете: trim, lowercase, E.164 для телефона;
— хешируете в отдельном шаге и дальше работаете только с hash;
— исходные значения не пишете в request log, console, preview payload.

Полезное правило для sGTM: один event object — два слоя данных. В первом слое живут только технические поля для маршрутизации: event_name, client_id, consent, IP, UA. Во втором — PII, но только как transient input для тега, который её потребляет. Не кладите email в shared data store контейнера: потом его случайно подхватит другой тег.

Для дебага используйте маскирование: показывайте первые 2-3 символа хеша и длину поля, а не исходную строку. Если нужен deduplication между Pixel и CAPI, связывайте события через event_id, а не через PII. Так меньше риск утечки и проще чистить контур.

Итог простой: в server-side контейнере PII должна жить минуту, а не весь жизненный цикл запроса. Чем короче её путь до хеша или удаления, тем стабильнее атрибуция и дешевле разбор инцидентов.