Hashing PII для Meta CAPI ломается не на SHA-256, а на нормализации полей

Hashing PII для Meta CAPI ломается не на SHA-256, а на нормализации полей

Email, phone, first_name, last_name, city, state, zip, country можно хешировать заранее, но Meta сравнивает не «строку в вакууме», а нормализованное значение. Если на клиенте у вас `Ivanov@Gmail.com`, а на сервере `ivanov@gmail.com `, матч уже деградирует.

Базовые правила:
— email: trim, lowercase, без пробелов;
— phone: только цифры, в формате E.164 до хеша;
— имена и город: lowercase, trim, без диакритики, если источник это поддерживает;
— страна: ISO-2, zip — без лишних символов;
— хеш: SHA-256 от нормализованной строки, не от JSON-объекта.

Для CAPI лучше передавать не один идентификатор, а набор: email_hash + phone_hash + external_id + fbp/fbc, если они есть. Чем больше валидных match_keys, тем выше шанс на Event Match Quality и тем стабильнее дедупликация между Pixel и CAPI.

Частая ошибка — хешировать «как есть» в GTM template и потом ещё раз на backend. Вторая проблема — разные правила на разных источниках: CRM отправляет телефон с `+7`, веб-сайт без префикса, а сервер склеивает их в разные хеши. Ещё хуже, когда PII уходит в логах до хеширования.

Финальное правило простое: сначала приводите PII к одному каноническому виду, потом хешируйте, потом тестируйте match rate на одном и том же event_id. Тогда CAPI перестаёт быть «чёрным ящиком» и начинает давать предсказуемый сигнал.