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. Друг капан са стойностите-заместители: имейл като noemail@example.com, който магазинът попълва при поръчки като гост, се споделя от много клиенти, така че не може да идентифицира един човек. Вместо това не изпращайте полето.

Защо събитията от сървъра, изградени от данните за поръчките, носят повече идентификатори?

Прегледът на страница се случва, преди посетителят да ви е казал нещо. Браузърът знае ID на бисквитка, може би click ID, IP адрес и user agent. Платената поръчка е различна: купувачът е въвел имейл адрес, често телефонен номер, име и адрес.

Затова събитие Purchase, изпратено от вашия сървър, може да получи по-висока оценка от PageView или ViewContent. Събитие за покупка, което идва само от страницата за благодарност, има идентификаторите на браузъра, но не винаги имейла и телефона от поръчката.

Не всеки параметър може да достигне 100% от събитията и това е нормално. В примера по-долу click ID е при 38% от покупките, защото само купувачите, дошли от кликване върху реклама в Meta, имат такъв.

Каква е реалистична цел за Event Match Quality?

Документацията на Meta за разработчици казва, че обикновено препоръчва оценка от 6.0 или повече, където е възможно. Приемете това за цел при събитията, които носят данни за контакт, най-вече Purchase. Purchase, изграден от данните на поръчката, носи имейл, един от двата параметъра с висок приоритет, и повечето от параметрите със среден приоритет, затова при него целта е най-реалистична. Измерете го, вместо да го приемате за даденост: оценката зависи и от вашите клиенти.

Не очаквайте една и съща оценка при всяко събитие. PageView, ViewContent и AddToCart често нямат данни за контакт, защото повечето посетители са анонимни до страницата за плащане. По-ниската оценка там е очаквана и не е причина да събирате имейл адреси по-рано, отколкото посетителите ви искат да ги дадат.

Не гонете и 10. Оценката зависи и от дела на събитията, които Meta съпоставя, а част от това е извън вашия контрол: някои от купувачите ви нямат акаунт в Meta или са използвали там друг имейл адрес. Значение има и съгласието. В ROASaurus, при включена опция Respect visitor consent, посетител, който откаже маркетинговите бисквитки, няма запазен 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 показва дела на събитията, които носят ключ за дедупликация, като ID на събитието, а Data freshness показва колко бързо пристигат вашите събития от сървъра. Ако все още настройвате страната на сървъра, започнете с нашето ръководство за Meta Conversions API.

Защо моят Event Match Quality е нисък?

Когато едно събитие получава по-ниска оценка от очакваното, обичайните причини са следните:

• Сървърът изпраща собствения си IP адрес. Ако събитията минават през вашия сървър или сървър за тагове, той трябва да препраща IP адреса и user agent, които е записал от купувача, а не собствените си.
• fbclid се губи. Click ID е само в URL адреса на целевата страница. Ако нищо не го запише там, до страницата за плащане той вече го няма. Запазете го точно както пристига, защото различава главните и малките букви.
• Данните за контакт се хешират без нормализиране или се изпращат нехеширани.
• Идентификаторите на браузъра се хешират. Хеширан fbp или fbc не може да бъде съпоставен.
• Покупките идват само от браузъра. Събитие от страницата за благодарност често няма имейла и телефона, които има поръчката. Изпращането на покупката от поръчката решава това.

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

ROASaurus изгражда събитието Purchase от поръчката във вашия магазин, така че то носи данните за контакт от поръчката. Имейлът, телефонът, собственото и фамилното име, градът, областта, пощенският код и държавата се нормализират и хешират със SHA-256. ID на клиента в магазина и ID на посетителя в ROASaurus се подават хеширани като external_id. IP адресът, user agent, URL адресът на страницата и fbp се свързват от посещението на купувача, а fbc се изгражда от fbclid, който скриптът във витрината на магазина запазва, когато посетителят пристигне.

Събитие без fbc, fbp, имейл, телефон или 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

Продължете да четете