Pot renunța la pixel dacă am CAPI?

Meta recomandă să le păstrezi pe amândouă. Pixelul aduce semnale de browser (fbp, fbc) care ridică potrivirea și acoperă evenimentele pe care serverul nu le vede bine, cum sunt vizualizările de conținut.

De ce Events Manager arată mai multe Purchase-uri decât comenzile reale?

Aproape sigur deduplicare eșuată: event_id diferit sau lipsă între browser și server. Verifică în tool-ul de test că fiecare comandă generează exact o pereche cu același ID.

Meta Conversions API: de ce pixelul singur nu mai ajunge și

Situația

Platforma magazinului spune 212 comenzi din Meta luna asta. Ads Manager spune 131. Diferența nu e doar „atribuire” în sens abstract — o parte din comenzi nu au ajuns niciodată la Meta. Pixelul din browser a fost blocat, consimțământul a fost refuzat sau utilizatorul a fost pe un iPhone cu tracking limitat. Sistemul de livrare a optimizat cu o bucată mare din date lipsă și a plătit mai mult pentru fiecare comandă pe care a văzut-o.

Pixel vs Conversions API

Pixelul Meta e un script în browser. Când cineva vede un produs sau finalizează o comandă, scriptul trimite evenimentul la Meta direct din browserul utilizatorului. Simplu, dar la mila browserului.

Conversions API (CAPI) trimite același eveniment de pe serverul tău (sau dintr-un server intermediar) către Meta. Nu depinde de browser, de ad blocker sau de setările iOS. Are acces la date pe care le știi tu — email-ul clientului, telefonul, ID-ul de client — și le poate trimite hash-uite, ca Meta să potrivească evenimentul cu un cont real.

Nu e „ori una, ori alta”. Configurarea recomandată de Meta e redundantă: pixelul și CAPI trimit aceleași evenimente, iar Meta le deduplică.

De ce browserul singur pierde evenimente

Consimțământ — în UE, fără acceptul pentru marketing, pixelul nu se încarcă. Atenție: CAPI nu e o scurtătură pe lângă consimțământ. Evenimentul de pe server se trimite tot doar cu acordul utilizatorului; avantajul e că, atunci când acordul există, evenimentul nu se mai pierde din motive tehnice.
Ad blocker-e și browsere cu protecție — blochează scriptul sau scurtează durata cookie-urilor.
iOS — de la App Tracking Transparency, aplicațiile Facebook și Instagram primesc mult mai puține semnale despre ce face utilizatorul după click.
Pagini care nu se încarcă complet — utilizatorul închide tab-ul înainte ca scriptul să tragă evenimentul. Pe server, comanda există oricum.

Event Match Quality

În Events Manager, fiecare eveniment are un scor Event Match Quality (EMQ), de la 1 la 10. Măsoară câte date de identificare trimiți și cât de bine se potrivesc cu conturile Meta. Ce ridică scorul:

email și telefon (hash-uite SHA-256, în format normalizat);
cookie-urile de browser _fbp și _fbc (ID-ul click-ului din reclamă);
IP-ul clientului și user agent-ul;
un external_id — ID-ul tău de client, consistent între browser și server;
nume, oraș, cod poștal, țară, acolo unde le ai legitim.

Scorul mic pe Purchase e cel mai scump: sunt exact conversiile pe care sistemul trebuie să le vadă ca să găsească alți cumpărători.

Deduplicarea cu event_id

Când același eveniment vine și din browser și de pe server, Meta îl numără o singură dată numai dacă ambele au același event_name și același event_id. Dacă ID-urile diferă sau lipsesc, numeri fiecare comandă de două ori: ROAS-ul din Ads Manager se dublează pe hârtie, iar optimizarea învață din date false.

În practică: generezi ID-ul o dată (de exemplu, numărul comenzii sau un identificator unic creat la încărcarea paginii), îl pui în evenimentul pixelului și îl trimiți cu același nume de eveniment de pe server. În Events Manager, la fiecare eveniment, vezi câte au fost deduplicate.

Cum arată o configurare corectă

Pixel în browser prin GTM (sau nativ pe platformă), doar după consimțământul de marketing, cu evenimentele standard: ViewContent, AddToCart, InitiateCheckout, Purchase, Lead.
CAPI de pe server — prin integrarea platformei (Shopify, WooCommerce și altele au conectori oficiali), prin GTM server-side cu template-ul Meta, sau direct din codul tău.
Aceleași evenimente, aceleași ID-uri pe ambele canale.
Date de potrivire trimise de pe server: email, telefon, external_id, fbp, fbc, IP, user agent.
Consimțământul respectat pe ambele căi — semnalul de consimțământ ajunge și la server, nu doar în browser.
Verificare — vezi mai jos.

Cum verifici în Events Manager

Test Events — pui codul de test în cererea de pe server și parcurgi fluxul real pe site. Trebuie să vezi fiecare eveniment venind o dată din browser și o dată de pe server, aproape în timp real.
Prezentarea pe eveniment — coloanele pentru browser și server și numărul de evenimente deduplicate. Un Purchase cu evenimente de pe server, dar zero deduplicate, înseamnă că ID-urile nu se potrivesc.
Event Match Quality — deschide detaliile evenimentului și vezi ce parametri lipsesc; Meta îți spune ce ai putea adăuga.
Diagnostics — avertizările despre parametri invalizi, hash greșit sau evenimente întârziate.
Compară cu sursa adevărului — comenzile din platformă versus Purchase-urile din Events Manager, pe același interval. Nu vor fi egale (atribuire, consimțământ refuzat), dar diferența trebuie să fie explicabilă și stabilă.