Meta Event Match Quality: hogyan javíthatod a pontszámodat

Az Event Match Quality (EMQ) egy 10-es skálájú pontszám, amelyet a Meta a Conversions API-n keresztül küldött minden weboldal-eseménynek ad. Megmutatja, mennyire jól tudja az eseményen szereplő ügyféladat egy Meta-fiókhoz párosítani az eseményt. Úgy növeled, hogy több megfelelő azonosítót küldesz, úgy formázva és hashelve, ahogyan a Meta elvárja.

Ez az útmutató elmagyarázza, mit mér a pontszám, mely ügyféladat-paraméterek számítanak a legtöbbet, milyen hashelési és normalizálási szabályok vannak, miért hordoznak a rendelési adatokból származó vásárlások több azonosítót, mint az oldalmegtekintések, milyen pontszámot érdemes célozni, és hol ellenőrizheted.

Mit mér az Event Match Quality?

A Meta a pontszámot két dologból számolja: a szerveresemény mellett küldött ügyféladatok minőségéből, és abból, hogy ezeknek az eseményeknek mekkora részét párosítja a Meta egy fiókhoz. Egy párosított esemény megmondja a Metának, melyik személy vásárolt. A Meta ekkor jóváírhatja a vásárlást annak a hirdetésnek, amelyet az illető látott vagy amelyre kattintott, és megmutathatja a hirdetéseidet azoknak, akik nagyobb valószínűséggel vásárolnak.

A Meta dokumentációjából néhány tény meghatározza, hogyan érdemes olvasni a pontszámot:

• Eseményenkénti. A Purchase, az AddToCart és a PageView külön-külön kap pontszámot, a standard és az egyéni események egyaránt.
• Csak a szervereseményekre vonatkozik. A pontszám a Conversions API-n keresztül küldött weboldal-eseményekre érhető el, ha az action_source értéke website. Azoknak az eseményeknek, amelyeket csak a böngészőpixel küld, nincs pontszámuk.
• Az elmúlt 48 órát használja. Küldj egyenletesen eseményeket, különben a pontszám elavul.

A Meta azt is megjegyzi, hogy a jobb párosítás növelheti a Conversions API-beállításodhoz jelentett további konverziók számát. Egy vásárlás, amelyet a Meta nem tud párosítani, olyan vásárlás, amelyért a hirdetéseid nem kapnak jóváírást.

Mely ügyféladat-paraméterek javítják a pontszámot?

A Meta minden ügyféladat-típushoz közzétesz egy prioritást. Egy eseményhez minden meglévő paramétert küldj el, és a magas prioritásúakkal kezdd.

Az IP-cím és a user agent nincs a Meta prioritási listáján, de a Meta fejlesztői dokumentációja szerint a client_ip_address és a client_user_agent küldése segíthet a párosításban. A user agent a weboldal-eseményekhez egyébként kötelező. Mindkettőnek a vásárló értékeinek kell lennie, nem a szervered értékeinek.

Hogyan hasheled és normalizálod az ügyféladatokat?

A Meta megköveteli, hogy az elérhetőségi adatokat SHA-256-tal hashelve küldd el. A hashelés csak akkor működik, ha minden rendszer ugyanazt az értéket ugyanúgy írja le, ezért a Meta minden mezőhöz megad egy normál alakot. Előbb normalizálj, aztán hasheld.

Kódban a lépések sorrendje a lényeg:

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

Vigyázz a belföldi előhívó nullát tartalmazó telefonszámokra. A +31 (0)6 1234 5678 alakban írt holland szám 310612345678 lesz, ha csak a jeleket távolítod el. A helyes alak 31612345678. A helyőrző értékek is csapdát jelentenek: egy olyan e-mail-cím, mint a noemail@example.com, amelyet a webáruház a vendégrendeléseknél tölt ki, sok vásárlónál közös, ezért nem azonosít egyetlen embert sem. Inkább hagyd ki a mezőt.

Miért hordoznak több azonosítót a rendelési adatokból származó szerveresemények?

Az oldalmegtekintés azelőtt történik, hogy a látogató bármit megadott volna magáról. A böngésző ismer egy süti-azonosítót, esetleg egy kattintásazonosítót, egy IP-címet és egy user agentet. A kifizetett rendelés más: a vásárló beírt egy e-mail-címet, gyakran egy telefonszámot, egy nevet és egy címet.

Ezért érhet el a szerverről küldött Purchase esemény magasabb pontszámot, mint a PageView vagy a ViewContent. Az az esemény, amely csak a köszönőoldalról érkezik, tartalmazza a böngészőazonosítókat, de nem mindig a rendelésből származó e-mailt és telefonszámot.

Nem minden paraméter érheti el az események 100%-át, és ez normális. Az alábbi példában a kattintásazonosító a vásárlások 38%-án szerepel, mert csak azoknak a vásárlóknak van ilyen, akik Meta-hirdetésre kattintva érkeztek.

Mi a reális Event Match Quality célérték?

A Meta fejlesztői dokumentációja szerint általában 6.0 vagy magasabb pontszámot ajánl, ahol lehetséges. Tekintsd ezt célnak azokra az eseményekre, amelyek elérhetőségi adatot hordoznak, mindenekelőtt a Purchase-re. A rendelési adatokból épített Purchase tartalmazza az e-mailt, vagyis a két magas prioritású paraméter egyikét, és a közepes prioritásúak többségét, ezért ennél az eseménynél a legreálisabb a cél. Mérd meg, ne feltételezd: a pontszám a vásárlóidtól is függ.

Ne várd el ugyanazt a pontszámot minden eseménytől. A PageView, a ViewContent és az AddToCart gyakran nem hordoz elérhetőségi adatot, mert a legtöbb látogató a pénztárig névtelen. Itt az alacsonyabb pontszám várható, és nem ok arra, hogy korábban kérj e-mail-címet, mint ahogy a látogatók megadnák.

A 10-es pontszámot sem érdemes hajszolni. A pontszám attól is függ, hogy a Meta az események mekkora részét párosítja, és ennek egy része nem a te kezedben van: néhány vásárlódnak nincs Meta-fiókja, vagy más e-mail-címet használt ott. A hozzájárulás is számít. A ROASaurusban, ha a Respect visitor consent be van kapcsolva, az a látogató, aki elutasítja a marketingsütiket, nem kap tárolt kattintásazonosítót vagy látogatóazonosítót, így a kifizetett rendelés hashelt rendelési adatokkal, valamint a rendelés IP-címével és user agentjével megy ki, de fbc és fbp nélkül. Minél több az elutasítás, annál kevesebb azonosító jut egy eseményre. A beállítást a hozzájárulásról szóló súgóoldalunk magyarázza el.

A hasznos kérdés nem az, hogy magas-e a pontszámod, hanem az, hogy változott-e. Minden sablon-, pénztár- vagy követésmódosítás után hasonlítsd össze az egyes eseményeket a saját korábbi értékeikkel.

Hogyan ellenőrizheted az Event Match Quality-t az Events Managerben?

1. Nyisd meg az adatkészletedet

   Lépj be az Events Managerbe, és válaszd ki a pixeled vagy adatkészleted nevét és azonosítóját.

2. Nyisd meg az esemény részleteit

   Keresd meg az eseményt, például a Purchase-t, és kattints a View details gombra.

3. Olvasd el az Event matching fület

   Megmutatja a pontszámot, az ügyféladatot hordozó események arányát és a párosítás javítására szolgáló tippeket.

4. Nézd meg a Diagnostics fület

   Az Events Manager Diagnostics füle felsorolja az eseményeiddel kapcsolatos problémákat, és javaslatokat ad a javításukra.

5. Ellenőrizd újra két nap múlva

   A pontszám az utolsó 48 óra eseményeiből számolódik, ezért egy javítás hatása nagyjából két nap múlva jelenik meg teljesen.

Ugyanazon az oldalon a többi fül is segít. Az Event coverage összeveti a szervereseményeidet a pixeleseményeiddel, az Event deduplication megmutatja, az események mekkora része hordoz deduplikációs kulcsot, például eseményazonosítót, a Data freshness pedig azt, milyen gyorsan érkeznek meg a szervereseményeid. Ha a szerveroldalt még csak állítod be, kezdd a Meta Conversions API útmutatónkkal.

Miért alacsony az Event Match Quality-m?

Ha egy esemény az elvártnál alacsonyabb pontszámot kap, ezek a szokásos okok:

• A szerver a saját IP-címét küldi. Ha az események a szervereden vagy egy címkeszerveren mennek át, annak a vásárlótól rögzített IP-címet és user agentet kell továbbítania, nem a sajátját.
• Elvész az fbclid. A kattintásazonosító csak a landing oldal URL-jében szerepel. Ha ott semmi nem menti el, a pénztárig már nincs meg. Pontosan úgy őrizd meg, ahogy megérkezik, mert megkülönbözteti a kis- és nagybetűket.
• Az elérhetőségi adatok normalizálás nélkül vannak hashelve, vagy hash nélkül mennek el.
• A böngészőazonosítók hashelve vannak. A hashelt fbp vagy fbc nem párosítható.
• A vásárlások csak a böngészőből jönnek. Egy köszönőoldal-esemény gyakran nem tartalmazza a rendelésben meglévő e-mailt és telefonszámot. Ha a vásárlást a rendelésből küldöd, ez megoldódik.

Hogyan küldi el a ROASaurus az ügyféladatokat

A ROASaurus a Purchase eseményt a webáruházad rendeléséből építi fel, így az a rendelés elérhetőségi adatait hordozza. Az e-mail, a telefonszám, a kereszt- és vezetéknév, a város, az állam, az irányítószám és az ország normalizálva és SHA-256-tal hashelve kerül bele. A webáruház vásárlóazonosítója és a ROASaurus látogatóazonosítója hashelve, external_id-ként kerül be. Az IP-cím, a user agent, az oldal URL-je és az fbp a vásárló látogatásából van csatolva, az fbc pedig abból az fbclid-ből épül, amelyet a webáruház scriptje elment, amikor a látogató megérkezik.

Az fbc, fbp, e-mail-cím, telefonszám és IP-cím nélküli eseményt kihagyjuk, mert a Meta nem tudja párosítani. A Meta-integráció oldala felsorol minden elküldött mezőt, a szerveroldali követés pedig elmagyarázza, hogyan párosítjuk a rendeléseket a hirdetési kattintással. A pontszám követéséhez a Tracking health oldal naponta kiolvassa minden Meta-pixel Event Match Quality értékét, és riasztást küld, ha a Purchase pontszám a beállított minimum (alapértelmezés szerint 6,0) alá esik.

Források

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

A ROASaurusban

• Meta integráció
• Szerveroldali követés
• Súgó: a Meta csatlakoztatása

Olvass tovább