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

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

Email, phone и другие match keys можно хэшировать идеально, но Meta всё равно будет плохо матчить, если на входе мусор: пробелы, заглавные буквы, формат телефона без country code, разные варианты символов в имени. Для CAPI важно не «зашифровать», а привести данные к одному виду до хэширования.

Базовый порядок такой:
— email: trim + lowercase, без лишних пробелов
— phone: только цифры, в международном формате
— external_id: стабильный ID из CRM, без изменений между каналами
— names/город/страна: нормализация перед SHA-256, а не после

Критичная ошибка — хэшировать уже «грязную» строку на фронте и потом пытаться чинить её на сервере. Если client-side и server-side используют разные правила, вы получаете разные hashes для одного пользователя и убиваете deduplication, EMQ и матчинг. Правило простое: одна схема нормализации для всех источников, один helper, одна точка контроля.

Отдельно проверьте, чтобы в event_data уходили не только user_data, но и fbp/fbc, client_ip_address, client_user_agent, если они доступны легитимно. Для CAPI это часто важнее, чем попытка «дожать» ещё один PII-ключ.

Если hashes расходятся между GTM, backend и CRM-экспортом — сначала чините normalization layer, а уже потом смотрите на качество атрибуции.