Meta Event Match Quality: cum îți crești scorul

Event Match Quality (EMQ) este un scor din 10 pe care Meta îl dă fiecărui eveniment de pe site pe care îl trimiți prin Conversions API. Arată cât de bine pot asocia informațiile despre client din acel eveniment evenimentul cu un cont Meta. Îl crești trimițând mai mulți dintre identificatorii potriviți, formatați și transformați în hash așa cum se așteaptă Meta.

Acest ghid explică ce măsoară scorul, ce parametri de informații despre client contează cel mai mult, regulile de normalizare și de transformare în hash, de ce achizițiile din datele comenzii conțin mai mulți identificatori decât vizualizările de pagină, ce scor să urmărești și unde îl verifici.

Ce măsoară Event Match Quality?

Meta calculează scorul pornind de la două lucruri: calitatea informațiilor despre client pe care le trimiți cu un eveniment de pe server și ponderea acelor evenimente pe care Meta le potrivește cu un cont. Un eveniment potrivit îi spune Meta care persoană a cumpărat. Meta poate atunci atribui achiziția reclamei pe care a văzut-o sau pe care a dat click acea persoană și poate arăta reclamele tale unor oameni cu șanse mai mari să cumpere.

Câteva fapte din documentația Meta influențează modul în care citești scorul:

• Este pe eveniment. Purchase, AddToCart și PageView primesc fiecare propriul scor, atât pentru evenimentele standard, cât și pentru cele personalizate.
• Acoperă doar evenimentele de pe server. Scorul este disponibil pentru evenimentele de pe site trimise prin Conversions API cu action_source setat pe website. Evenimentele trimise doar de pixelul din browser nu au scor.
• Folosește ultimele 48 de ore. Trimite evenimente constant, altfel scorul devine depășit.

Meta menționează și că o potrivire mai bună poate crește conversiile suplimentare pe care le raportează pentru configurarea ta Conversions API. O achiziție pe care Meta nu o poate potrivi este o achiziție pentru care reclamele tale nu primesc credit.

Ce parametri de informații despre client cresc scorul?

Meta publică o prioritate pentru fiecare tip de informații despre client. Trimite fiecare parametru pe care îl ai pentru un eveniment și începe cu cei cu prioritate mare.

Adresa IP și user agent-ul nu se află în lista de priorități Meta, dar documentația Meta pentru dezvoltatori spune că trimiterea client_ip_address și client_user_agent poate ajuta potrivirea. User agent-ul este oricum obligatoriu pentru evenimentele de pe site. Ambele trebuie să fie valorile cumpărătorului, nu cele ale serverului tău.

Cum transformi în hash și normalizezi datele clientului?

Meta cere ca informațiile de contact să fie transformate în hash cu SHA-256 înainte să le trimiți. Transformarea în hash funcționează doar dacă fiecare sistem scrie aceeași valoare în același mod, așa că Meta definește o formă normală pentru fiecare câmp. Normalizează mai întâi, apoi transformă în hash.

În cod, contează ordinea pașilor:

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

Atenție la numerele de telefon cu zero de prefix. Un număr olandez scris ca +31 (0)6 1234 5678 devine 310612345678 dacă elimini doar simbolurile. Forma corectă este 31612345678. Valorile de umplere sunt o altă capcană: un email precum noemail@example.com, pe care un magazin îl completează pentru comenzile fără cont, este folosit de mulți clienți, deci nu poate identifica o singură persoană. Lasă în schimb câmpul gol.

De ce conțin evenimentele de pe server din datele comenzii mai mulți identificatori?

O vizualizare de pagină are loc înainte ca vizitatorul să-ți fi spus ceva. Browserul cunoaște un id de cookie, poate un click id, o adresă IP și un user agent. O comandă plătită este altfel: cumpărătorul a introdus o adresă de email, adesea un număr de telefon, un nume și o adresă.

De aceea un eveniment Purchase trimis de pe serverul tău poate obține un scor mai mare decât PageView sau ViewContent. Un eveniment de achiziție care provine doar de pe pagina de mulțumire are identificatorii din browser, dar nu întotdeauna emailul și telefonul din comandă.

Nu orice parametru poate ajunge la 100% din evenimente, iar asta este normal. În exemplul de mai jos, click id-ul apare la 38% dintre achiziții, pentru că îl au doar cumpărătorii care au venit dintr-un click pe o reclamă Meta.

Care este o țintă realistă pentru Event Match Quality?

Documentația pentru dezvoltatori Meta spune că recomandă, de regulă, un scor de 6.0 sau mai mare, acolo unde este posibil. Consideră-l ținta pentru evenimentele care conțin date de contact, mai ales Purchase. Un Purchase construit din datele comenzii conține emailul, unul dintre cei doi parametri cu prioritate mare, și majoritatea celor cu prioritate medie, deci este evenimentul pentru care ținta este cea mai realistă. Măsoară în loc să presupui: scorul depinde și de clienții tăi.

Nu te aștepta la același scor pentru fiecare eveniment. PageView, ViewContent și AddToCart nu au adesea date de contact, pentru că majoritatea vizitatorilor sunt anonimi până la checkout. Un scor mai mic aici este de așteptat și nu este un motiv să colectezi adrese de email mai devreme decât vor vizitatorii tăi să le dea.

Nu alerga nici după un 10. Scorul depinde și de ponderea evenimentelor pe care Meta le potrivește, iar o parte din ea nu depinde de tine: unii dintre cumpărătorii tăi nu au cont Meta sau au folosit acolo o altă adresă de email. Contează și consimțământul. În ROASaurus, cu Respect visitor consent activat, un vizitator care refuză cookie-urile de marketing nu are un click id sau un id de vizitator stocat, așa că achiziția plătită pleacă cu datele comenzii cu hash, cu adresa IP și user agent-ul comenzii, dar fără fbc și fbp. Cu cât sunt mai multe refuzuri, cu atât sunt mai puțini identificatori per eveniment. Pagina noastră de ajutor despre consimțământ explică setarea.

Întrebarea utilă nu este dacă scorul tău este mare, ci dacă s-a schimbat. Compară fiecare eveniment cu propriul istoric după fiecare modificare a temei, a checkoutului sau a trackingului.

Cum verifici Event Match Quality în Events Manager?

1. Deschide setul tău de date

   Mergi la Events Manager și selectează numele și id-ul pixelului sau al setului tău de date.

2. Deschide detaliile evenimentului

   Găsește evenimentul, de exemplu Purchase, și fă click pe View details.

3. Citește fila Event matching

   Arată scorul, ponderea evenimentelor care conțin informații despre client și sfaturi pentru îmbunătățirea potrivirii.

4. Verifică Diagnostics

   Fila Diagnostics din Events Manager listează problemele evenimentelor tale și recomandări pentru remedierea lor.

5. Verifică din nou după două zile

   Scorul folosește ultimele 48 de ore de evenimente, așa că o remediere apare complet abia după aproximativ două zile.

Și celelalte file de pe aceeași pagină sunt utile. Event coverage compară evenimentele tale de pe server cu cele din pixel, Event deduplication arată ponderea evenimentelor care au o cheie de deduplicare, precum event id, iar Data freshness arată cât de repede ajung evenimentele tale de pe server. Dacă încă configurezi partea de server, începe cu ghidul Meta Conversions API.

De ce este scăzut scorul meu Event Match Quality?

Când un eveniment are un scor mai mic decât te aștepți, acestea sunt cauzele obișnuite:

• Serverul trimite propria adresă IP. Dacă evenimentele trec prin serverul tău sau printr-un server de taguri, acesta trebuie să transmită adresa IP și user agent-ul înregistrate de la cumpărător, nu pe ale lui.
• fbclid se pierde. Click id-ul se află doar în URL-ul paginii de destinație. Dacă nimic nu îl salvează acolo, până la checkout s-a pierdut. Păstrează-l exact așa cum sosește, pentru că ține cont de majuscule și minuscule.
• Datele de contact primesc hash fără normalizare sau sunt trimise fără hash.
• Identificatorii din browser primesc hash. Un fbp sau un fbc cu hash nu poate fi potrivit.
• Achizițiile vin doar din browser. Un eveniment de pe pagina de mulțumire nu are adesea emailul și telefonul pe care le are comanda. Trimiterea achiziției din comandă rezolvă asta.

Cum trimite ROASaurus informațiile despre client

ROASaurus construiește evenimentul Purchase din comanda din magazinul tău, așa că acesta conține datele de contact ale comenzii. Emailul, telefonul, prenumele și numele, orașul, statul, codul poștal și țara sunt normalizate și primesc hash SHA-256. Id-ul clientului din magazin și id-ul de vizitator ROASaurus intră cu hash ca external_id. Adresa IP, user agent-ul, URL-ul paginii și fbp sunt preluate din vizita cumpărătorului, iar fbc este construit din fbclid, pe care scriptul vitrinei îl salvează când vizitatorul ajunge pe site.

Un eveniment fără fbc, fbp, email, telefon sau adresă IP este omis, pentru că Meta nu îl poate potrivi. Pagina integrării Meta listează fiecare câmp trimis, iar tracking-ul server-side explică cum sunt asociate comenzile cu click-ul pe reclamă. Ca să urmărești scorul, pagina Tracking health citește zilnic Event Match Quality pentru fiecare pixel Meta și declanșează o alertă când scorul pentru Purchase scade sub minimul tău, implicit 6,0.

Surse

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

În ROASaurus

• Integrare Meta
• Tracking server-side
• Ajutor: conectează Meta

Continuă lectura