Почему хэширование Meta CAPI зависит от нормализации
Хэширование в Meta CAPI позволяет связать конверсию с человеком, не отправляя исходные персональные данные: вы нормализуете идентификатор и рассчитываете для него SHA-256, а Meta сравнивает дайджест со своими хэшированными записями. Сравнение точное: SHA-256 от [email protected] и от [email protected] дают разные значения. Если нормализация отличается хотя бы пробелом или регистром, хэши не совпадут. Ошибки не будет, но событие потеряет самый сильный сигнал для сопоставления.
Поэтому правила нормализации задокументированы по каждому полю с точными примерами на странице Customer Information Parameters. Режим сбоя невидим в логах ошибок: события доставляются, но Event Match Quality падает, и оптимизация деградирует. Сам скор разобран в Event Match Quality; этот гайд собирает правила по полям и межплатформенные различия, на которых ломаются мульти-сети.
Официальные правила нормализации Meta CAPI
Meta документирует рецепт нормализации для каждого хэшируемого поля. То, что кусается в ежедневной доставке:
| Поле | Нормализация перед SHA-256 | Официальный пример |
|---|---|---|
em email | Обрезать пробелы, lowercase. Пунктуация внутри адреса остаётся | [email protected] → [email protected] |
ph телефон | Убрать символы, буквы и ведущие нули; код страны обязателен | (650)555-1212 → 16505551212 |
fn / ln имена | Lowercase, без пунктуации; рекомендуется Roman a-z; не-латиница в UTF-8, акценты сохраняются | Mary → mary; Valéry → valéry |
ct город | Lowercase, без пунктуации, спецсимволов и пробелов | New York → newyork |
st штат | Двухсимвольный ANSI-код в lowercase; вне США - lowercase без пунктуации и пробелов | az, ca |
zp индекс | Lowercase, без пробелов и дефисов; США - первые 5 цифр; UK - формат area/district/sector | 94035; m11ae |
country | Двухбуквенный ISO 3166-1 alpha-2 в lowercase | United States → us |
Три детали из официальных примеров заслуживают внимания. Email приводят к нижнему регистру, но подчёркивания и точки внутри адреса сохраняют: [email protected] остаётся без изменений. Для телефона всегда нужен код страны, даже если данные собраны в одной стране; ведущие нули удаляют. Имена сохраняют акцентированные символы: Valéry нормализуется в valéry, а не valery, потому что транслитерация меняет хэш.
После нормализации каждое значение хэшируется SHA-256 и уезжает hex-строкой в 64 символа в нижнем регистре - или отдается инструменту, который делает это сам. Business SDK от Meta хэшируют автоматически, убирая весь класс ошибок ценой запуска SDK.
Где платформы расходятся: Meta vs TikTok vs OpenAI
Команды, которые отправляют события в несколько сетей из одного трекера, часто копируют правила нормализации между платформами. Здесь и возникает ошибка сопоставления. SHA-256 везде один и тот же, но списки полей и правила для геоданных различаются:
| Правило | Meta | OpenAI | TikTok |
|---|---|---|---|
| Trim, lowercase | Trim, lowercase | Хэширование обязательного ключа сопоставления | |
| Телефон | Код страны обязателен, без символов и ведущих нулей | Та же схема, 8-15 цифр | Хэширование обязательного ключа |
| Гео (город/штат/индекс/страна) | Хэшируется, строгие форматы | Сырые строки, не хэшируется | По документации ключей сопоставления |
| Имена | Lowercase, без пунктуации, UTF-8-акценты сохраняются | Lowercase, без ASCII-пунктуации, не-ASCII сохраняется | Не ключ сопоставления TikTok: платформа использует только email, телефон и external_id |
Особенно важно не перепутать геоданные: Meta хэширует город, штат, индекс и страну по строгим правилам, а Conversions API OpenAI ожидает их в исходном виде и хэширует только идентификаторы. Если передать в OpenAI геоданные, уже хэшированные для Meta, поле будет потеряно; если отправить в хэшируемые поля Meta исходные значения, сопоставление не сработает. Advanced matching TikTok тоже требует хэшировать email, телефон и external_id; подробнее читайте в гайде о расширенном сопоставлении TikTok. Отдельно проверьте external_id: это click ID или подписочный ID из трекера. Meta принимает его без хэширования, но значение должно совпадать в пикселе и серверном событии. Если хэшировать ID только на одной стороне, это совпадение нарушится. Повторное хэширование тоже меняет значение и не позволит его сопоставить. Такое часто случается, когда поверх своей цепочки ставят tag manager, который хэширует данные ещё раз.
Проверка нормализации без лога ошибок
Поскольку плохо захэшированные значения доставляются без жалоб, проверка живёт в измерительных инструментах. Meta Test Events показывает полевую диагностику серверных событий, включая то, какие user-data поля приехали и прошли. Обзор Events Manager показывает счётчики raw против matched - большой разрыв raw→matched без ошибок и есть подпись проблемы нормализации.
Цикл фикса механический: нормализовать по таблице, захэшировать, переотправить одно тестовое событие, убедиться, что поле валидно. Если направлять постбеки трекеров через MOST, сервис автоматически нормализует и хэширует данные для каждой сети; бесплатный ручной путь для одиночного лендинга - Pixel Activator. Сторона дедупликации того же payload - стабильный event_id на ретраях - в дедупликации по event ID, полный контекст доставки - в полном гайде по Meta Conversions API.
Frequently asked questions
См. также: конструкция fbc и fbp. См. также: ограниченная обработка данных.