Meta Event Match Quality: как повысить оценку

Event Match Quality (EMQ) — это оценка из 10, которую Meta присваивает каждому событию сайта, отправленному вами через Conversions API. Она показывает, насколько хорошо информация о клиенте в этом событии позволяет сопоставить его с аккаунтом Meta. Вы повышаете её, отправляя больше нужных идентификаторов в том формате и с тем хешированием, которых ждёт Meta.

В этом руководстве объясняется, что измеряет оценка, какие параметры информации о клиенте важнее всего, правила хеширования и нормализации, почему покупки из данных заказа несут больше идентификаторов, чем просмотры страниц, к какой оценке стремиться и где её проверять.

Что измеряет Event Match Quality?

Meta рассчитывает оценку по двум показателям: качеству информации о клиенте, которую вы отправляете с серверным событием, и доле таких событий, которые Meta сопоставляет с аккаунтом. Сопоставленное событие сообщает Meta, какой именно человек купил. Тогда Meta может засчитать покупку объявлению, которое этот человек видел или по которому кликал, и показывать вашу рекламу людям, которые с большей вероятностью купят.

Несколько фактов из документации Meta определяют, как читать оценку:

• Она считается по каждому событию. Purchase, AddToCart и PageView получают каждый свою оценку, как стандартные, так и пользовательские события.
• Она охватывает только серверные события. Оценка доступна для событий сайта, отправленных через Conversions API с action_source, равным website. У событий, отправленных только браузерным пикселем, оценки нет.
• Она использует последние 48 часов. Отправляйте события равномерно, иначе оценка устареет.

Meta также отмечает, что лучшее сопоставление может увеличить число дополнительных конверсий, о которых она сообщает по вашей настройке Conversions API. Покупка, которую Meta не может сопоставить, — это покупка, за которую ваша реклама не получает заслуги.

Какие параметры информации о клиенте повышают оценку?

Meta публикует приоритет для каждого типа информации о клиенте. Отправляйте каждый параметр, который у вас есть для события, и начинайте с параметров высокого приоритета.

IP-адреса и user agent нет в списке приоритетов Meta, но документация Meta для разработчиков говорит, что отправка client_ip_address и client_user_agent может помочь сопоставлению. Для событий сайта user agent в любом случае обязателен. Оба значения должны принадлежать покупателю, а не вашему серверу.

Как хешировать и нормализовать данные клиента?

Meta требует хешировать контактную информацию по SHA-256 перед отправкой. Хеширование работает, только если все системы записывают одно и то же значение одинаково, поэтому Meta определяет нормальную форму для каждого поля. Сначала нормализуйте, потом хешируйте.

В коде важен порядок шагов:

import { createHash } from 'node:crypto';
const sha256 = (s) => createHash('sha256').update(s).digest('hex');

// Normalize first, then hash.
const em = sha256(' Anna.Berg@Example.com '.trim().toLowerCase());
// hashes "anna.berg@example.com"

const ph = sha256('+1 (415) 555-0134'.replace(/\D/g, ''));
// hashes "14155550134"

const ct = sha256('San Francisco'.toLowerCase().replace(/[^a-z]/g, ''));
// hashes "sanfrancisco"

// Sent as they are, never hashed:
// fbp, fbc, client_ip_address, client_user_agent

Остерегайтесь телефонных номеров с нулём в начале (национальный префикс). Нидерландский номер, записанный как +31 (0)6 1234 5678, превратится в 310612345678, если просто убрать символы. Правильный вид — 31612345678. Ещё одна ловушка — значения-заглушки: email вроде noemail@example.com, который магазин подставляет для гостевых заказов, общий у многих покупателей, поэтому он не позволяет определить конкретного человека. Лучше не передавать это поле совсем.

Почему серверные события из данных заказа несут больше идентификаторов?

Просмотр страницы происходит до того, как посетитель что-либо о себе сообщил. Браузер знает id из cookie, возможно click id, IP-адрес и user agent. С оплаченным заказом всё иначе: покупатель ввёл адрес электронной почты, часто номер телефона, имя и адрес.

Поэтому событие Purchase, отправленное с вашего сервера, может получить оценку выше, чем PageView или ViewContent. Событие покупки, которое приходит только со страницы благодарности, содержит идентификаторы браузера, но не всегда email и телефон из заказа.

Не каждый параметр может достичь 100% событий, и это нормально. В примере ниже click id есть у 38% покупок, потому что он бывает только у покупателей, которые пришли по клику на рекламу Meta.

Какая цель по Event Match Quality реалистична?

В документации Meta для разработчиков сказано, что обычно рекомендуется оценка 6.0 или выше, где это возможно. Считайте это целью для событий, которые несут контактные данные, прежде всего Purchase. Purchase, построенный из данных заказа, содержит email — один из двух параметров с высоким приоритетом — и большинство параметров со средним приоритетом, поэтому именно для этого события цель наиболее реалистична. Измеряйте, а не предполагайте: оценка зависит и от ваших клиентов.

Не ждите одинаковой оценки для каждого события. У PageView, ViewContent и AddToCart часто нет контактных данных, потому что большинство посетителей анонимны до чекаута. Более низкая оценка здесь ожидаема, и это не повод собирать адреса электронной почты раньше, чем посетители готовы их оставить.

Не гонитесь и за оценкой 10. Она зависит ещё и от доли событий, которые Meta удаётся сопоставить, а часть этого от вас не зависит: у некоторых ваших покупателей нет аккаунта Meta или они использовали там другой email. Важно и согласие. В ROASaurus при включённой настройке Respect visitor consent у посетителя, отклонившего маркетинговые cookie, нет сохранённых click id и id посетителя, поэтому оплаченный заказ уходит с хешированными данными заказа, а также с IP-адресом и user agent из заказа, но без fbc и fbp. Чем больше отказов, тем меньше идентификаторов в каждом событии. Настройка описана на нашей справочной странице о согласии.

Полезный вопрос не в том, высока ли ваша оценка, а в том, изменилась ли она. Сравнивайте каждое событие с его собственной историей после каждого изменения темы, чекаута или трекинга.

Как проверить Event Match Quality в Events Manager?

1. Откройте ваш датасет

   Перейдите в Events Manager и выберите название и id вашего пикселя или датасета.

2. Откройте сведения о событии

   Найдите событие, например Purchase, и нажмите View details.

3. Изучите вкладку Event matching

   Она показывает оценку, долю событий с информацией о клиенте и советы по улучшению сопоставления.

4. Проверьте вкладку Diagnostics

   На вкладке Diagnostics в Events Manager перечислены проблемы с вашими событиями и рекомендации по их исправлению.

5. Перепроверьте через два дня

   Оценка использует события за последние 48 часов, поэтому исправление полностью проявится примерно через два дня.

Полезны и другие вкладки на той же странице. Event coverage сравнивает ваши серверные события с событиями пикселя, Event deduplication показывает долю событий с ключом дедупликации, например event id, а Data freshness показывает, как быстро приходят ваши серверные события. Если вы ещё настраиваете серверную часть, начните с нашего руководства по Meta Conversions API.

Почему у меня низкий Event Match Quality?

Если одно событие получает оценку ниже ожидаемой, обычно причины такие:

• Сервер отправляет собственный IP-адрес. Если события проходят через ваш сервер или сервер тегов, он должен передавать IP-адрес и user agent, записанные у покупателя, а не свои собственные.
• fbclid теряется. Click id есть только в URL лендинга. Если там его никто не сохраняет, к чекауту он уже потерян. Сохраняйте его в точности так, как он пришёл, потому что он чувствителен к регистру.
• Контактные данные хешируются без нормализации или отправляются нехешированными.
• Идентификаторы браузера хешируются. Захешированные fbp или fbc сопоставить нельзя.
• Покупки приходят только из браузера. В событии со страницы благодарности часто нет email и телефона, которые есть в заказе. Отправка покупки из заказа решает эту проблему.

Как ROASaurus отправляет информацию о клиенте

ROASaurus формирует событие Purchase из заказа в вашем магазине, поэтому оно содержит контактные данные заказа. Email, телефон, имя и фамилия, город, штат, индекс и страна нормализуются и хешируются с помощью SHA-256. Id клиента в магазине и id посетителя ROASaurus передаются в хешированном виде как external_id. IP-адрес, user agent, URL страницы и fbp добавляются из визита покупателя, а fbc собирается из fbclid, который скрипт витрины сохраняет, когда посетитель попадает на сайт.

Событие, в котором нет ни fbc, ни fbp, ни email, ни телефона, ни IP-адреса, пропускается, потому что Meta не сможет его сопоставить. На странице интеграции с Meta перечислены все отправляемые поля, а материал о серверном трекинге объясняет, как заказы сопоставляются с кликом по рекламе. Чтобы следить за оценкой, страница Tracking health ежедневно считывает Event Match Quality каждого пикселя Meta и отправляет оповещение, когда оценка Purchase опускается ниже заданного вами минимума (по умолчанию 6,0).

Источники

1. Meta Business Help Center: About Event Match Quality
2. Meta for Developers: Customer Information Parameters
3. Meta for Developers: Verifying Your Setup
4. Meta Business Help Center: View server event details in Meta Events Manager
5. Meta for Developers: Best Practices - Conversions API

В ROASaurus

• Интеграция с Meta
• Серверный трекинг
• Справка: подключение Meta

Читайте дальше