Хэширование Meta CAPI: нормализация данных для матчинга
Почему хэширование Meta CAPI зависит от нормализации
Хэширование Meta CAPI существует, чтобы доказать принадлежность конверсии человеку без отправки сырых персональных данных: вы нормализуете идентификатор, хэшируете SHA-256, а Meta сравнивает дайджест со своими хэшированными записями. Сравнение точное: SHA-256 от [email protected] и от [email protected] - две unrelated-строки без пересечений. Если ваша нормализация отличается от меташной на один пробел или регистр, хэши никогда не совпадут, ошибки не вернётся, а событие потеряет самый сильный сигнал матчинга.
Поэтому правила нормализации задокументированы по каждому полю с точными примерами на странице 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 - порвать матч. Advanced matching TikTok ждёт хэшированные ключи - email, телефон, external_id - и питает TikTok enhanced matching: та же дисциплина со своим списком полей. Одно поле должно быть в каждом трекерном сетапе: external_id - клик- или подписочный ID из вашего трекера. Meta принимает его сырым значением без хэширования, но одно и то же значение обязано доехать и до пикселя, и до серверного события; захэшируете на одной стороне - порвёте матч. Хэшируйте один раз и ровно там, где поле определено: дважды захэшированное значение (нормализовали, захэшировали, потом второй инструмент хэшанул ещё раз) не сматчится никогда - это самая частая самостийная рана, когда поверх своего пайплайна ставят ещё и 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. ограниченная обработка данных.