<b>Хеширование PII для Meta CAPI: где ломают матчинг даже при правильной схеме полей</b>

<b>Хеширование PII для Meta CAPI: где ломают матчинг даже при правильной схеме полей</b>

Hashing сам по себе не спасает, если данные нормализованы по-разному на клиенте и на сервере. Для Meta CAPI критичны одинаковые правила до SHA-256: email в lowercase, без пробелов; phone — в E.164; имена — без лишних символов и двойных пробелов.

Базовый набор для match_keys:
— email_hash
— phone_hash
— external_id
— fbp / fbc
— IP и User-Agent как server data

Типовая ошибка: хешируют уже «грязные» строки, а потом сравнивают это с данными из Pixel или CRM. В итоге событие уходит, но EMQ проседает, потому что совпадение ищется по разным представлениям одного и того же значения.

Что делать:
— нормализовать до хеша, а не после
— использовать один и тот же пайплайн для CRM, sGTM и backend
— не смешивать raw и hashed значения в одном поле
— отдельно проверять event_id для deduplication Pixel + CAPI

Если у вас один email приходит как `John.Doe@Mail.com`, а другой как `john doe@mail.com`, это не “почти одно и то же” — для CAPI это разные строки до нормализации.

Практика простая: сначала приводите PII к канону, потом хешируете, потом тестируете матчинг на реальном payload. Именно так ловятся проблемы до того, как они превращаются в потерянные конверсии.