Meta Conversions API: cum folosești event_id pentru deduplicarea conversiilor browser–server

Dacă trimiți aceeași conversie și prin Meta Pixel, din browser, și prin Meta Conversions API, de pe server, ai nevoie de o regulă clară ca Meta să înțeleagă că este vorba despre aceeași acțiune, nu despre două conversii diferite. Aici intră în joc event_id: un identificator comun, trimis în ambele variante ale evenimentului.

Pentru magazine online, formulare de lead, funneluri de campanii și landing page-uri de social media, deduplicarea corectă contează direct în raportare. Fără ea, poți vedea conversii umflate, optimizare mai slabă și decizii greșite în campanii. Cu ea, browserul și serverul spun aceeași poveste.

Ce face event_id în Meta Conversions API

Meta explică în documentația pentru deduplicarea Pixel–Conversions API că metoda recomandată este combinația dintre event_id și numele evenimentului. Cu alte cuvinte, Meta compară două lucruri:

eventID trimis de Meta Pixel din browser;
event_id trimis de server prin Conversions API;
event din browser și event_name din server.

Pentru aceeași acțiune, aceste valori trebuie să se potrivească. Dacă în browser trimiți Purchase, pe server trebuie să trimiți tot Purchase. Dacă în browser trimiți eventID: "order-123", pe server trebuie să trimiți event_id: "order-123".

Documentația Meta spune că event_id poate fi orice string unic ales de advertiser. Pentru evenimente de tip Purchase, un număr de comandă sau un ID de tranzacție poate fi o alegere bună, pentru că separă natural comenzile între ele.

Exemplu simplu: același ID în browser și pe server

În browser, eventID este al patrulea argument în apelul fbq('track'). Un exemplu simplificat arată așa:

fbq('track', 'Purchase', {
  value: 149.00,
  currency: 'RON'
}, {
  eventID: 'order-12345'
});

Pe server, evenimentul trimis prin Conversions API trebuie să folosească același event_name și același event_id:

{
  "event_name": "Purchase",
  "event_time": 1790412000,
  "event_id": "order-12345",
  "action_source": "website",
  "user_data": {
    "em": ["<email_hash>"]
  },
  "custom_data": {
    "currency": "RON",
    "value": 149.00
  }
}

Exemplul de mai sus este orientativ. În implementarea reală, event_time trebuie să fie un timestamp Unix în secunde, iar datele din user_data trebuie tratate conform cerințelor Meta și regulilor de protecție a datelor. Tokenul de acces nu trebuie expus în browser; el rămâne pe server. Pentru partea operațională, merită citit și ghidul despre gestionarea tokenurilor Meta în producție, mai ales dacă lucrezi cu rotație, expirare și permisiuni minime.

Regula practică: generează ID-ul o singură dată

Cea mai sigură abordare este să generezi event_id o singură dată, în momentul acțiunii, apoi să îl refolosești în ambele direcții.

Pentru o comandă online, sursa bună este ID-ul comenzii. Pentru un formular de lead, poate fi un ID generat la salvarea leadului în baza de date. Pentru un eveniment de checkout, poate fi un identificator intern al sesiunii de conversie, dacă este stabil și unic.

Ce nu vrei să faci: să generezi un ID separat în browser și altul pe server. Dacă browserul trimite lead-abc, iar serverul trimite lead-xyz, Meta nu are aceeași cheie de potrivire. Rezultatul poate fi o conversie dublată sau o deduplicare ratată.

Un flux sănătos arată așa:

utilizatorul finalizează acțiunea;
aplicația stabilește ID-ul conversiei;
Pixelul primește acel ID ca eventID;
serverul trimite același ID ca event_id;
numele evenimentului rămâne identic în ambele locuri.

Dacă folosești conținut vizual și reclame pentru campanii, partea de creație rămâne separată de partea de măsurare. Poți lucra materialele în instrumente precum Canva, inclusiv cu AI, dar conversia trebuie urmărită consecvent; vezi și ghidul despre Canva AI pentru postări social media dacă vrei să legi mai bine creația de campaniile urmărite.

Ce se întâmplă când evenimentele ajung la Meta

În documentația pentru parametrii de server event, Meta precizează că event_name este obligatoriu, event_time este obligatoriu, iar event_id este opțional, dar recomandat pentru deduplicare.

Meta mai spune că, pentru aceeași acțiune a clientului, dacă găsește o potrivire între evenimente trimise în 48 de ore unul de altul, ia în calcul doar primul. Dacă evenimentul din browser și cel de pe server ajung aproximativ în același timp, adică într-un interval de 5 minute, Meta favorizează evenimentul browser/app.

Asta nu înseamnă că poți trimite evenimente haotic. Înseamnă că trebuie să păstrezi perechile curate: același nume, același ID, același sens al evenimentului. Nu trimite Lead în browser și CompleteRegistration pe server pentru aceeași acțiune doar pentru că par asemănătoare. Pentru deduplicare, numele trebuie să se potrivească.

Greșeli frecvente care strică deduplicarea

Prima greșeală este folosirea unui event_id static, de tipul purchase sau test123, pentru mai multe conversii. ID-ul trebuie să distingă evenimente similare, nu să le amestece.

A doua greșeală este schimbarea numelui evenimentului între browser și server. Purchase trebuie să rămână Purchase, Lead trebuie să rămână Lead.

A treia greșeală este trimiterea doar pe server a ID-ului, fără eventID în Pixel. Meta recomandă ca identificatorul să fie prezent în ambele părți când folosești metoda event_id plus event name.

A patra greșeală este expunerea logicii sensibile în browser. Browserul poate primi ID-ul evenimentului, dar tokenul Conversions API și apelurile server-side trebuie ținute în backend.

Cum verifici implementarea

Înainte să te bazezi pe datele din campanii, verifică trei lucruri simple:

Pixelul trimite eventID ca al patrulea parametru în fbq('track');
serverul trimite același event_id;
event și event_name au aceeași valoare pentru aceeași acțiune.

După aceea, testează cu evenimente reale, dar controlate: o comandă de test, un formular de test sau un eveniment intern marcat clar. Nu folosi date personale reale în exemple publice, capturi de ecran sau documentație internă. Păstrează ID-urile de test neutre și verifică în instrumentele Meta dacă evenimentele sunt primite așa cum te aștepți.

event_id nu repară o implementare dezordonată, dar oferă o ancoră clară între browser și server. Dacă îl generezi corect, îl transmiți în ambele locuri și păstrezi același nume de eveniment, deduplicarea devine mult mai previzibilă.

Întrebări frecvente

event_id este obligatoriu în Meta Conversions API?

În documentația Meta, event_id este marcat ca opțional, dar recomandat pentru deduplicarea evenimentelor trimise și prin browser, și prin server.

Pot folosi numărul comenzii ca event_id?

Da, pentru evenimente de tip Purchase, Meta menționează numărul de comandă sau ID-ul de tranzacție ca exemple de identificatori care pot separa comenzile între ele.

eventID din Pixel trebuie să fie identic cu event_id din server?

Da. Pentru deduplicarea prin metoda recomandată, eventID din Meta Pixel trebuie să se potrivească cu event_id din Conversions API, iar numele evenimentului trebuie să fie același.