Pe scurt
- Meta arată 10 cumpărări, magazinul 7, Google Ads 6. Nu le aduni și nu scazi; fiecare numără altceva (eveniment primit, comandă confirmată, credit de atribuire). Prima întrebare: „ce numără fiecare?”.
- Urmărești o singură comandă de test până la capăt: `purchase` cu transaction_id, monedă, value = produsele fără taxe și transport (200 lei în exemplu, nu 257), trimis o singură dată la reîncărcarea paginii.
- Pixel + Conversions API trimit aceeași cumpărare din browser și de pe server; Meta le recunoaște ca pereche doar dacă `eventID` (browser) și `event_id` (server) sunt identice pentru acea comandă și diferite între comenzi.
Meta Ads arată 10 cumpărări. În lista magazinului găsești 7 comenzi confirmate. Primul lucru de făcut nu este să scazi 7 din 10 și să declari trei tranzacții dublate. Cele două rapoarte pot avea reguli diferite: când numără, pe ce perioadă, ce numesc cumpărare și cui îi dau credit pentru ea.
Pentru a afla dacă există o problemă tehnică, urmărește întâi o singură tranzacție pe care o recunoști. După ce știi că ea pleacă o dată, cu suma și moneda corecte, poți compara loturile mai mari. Mai jos ai și un exemplu complet pentru GA4, și verificarea separată pentru Meta Pixel și Conversions API.
Urmărește o comandă pe care o recunoști
Pregătește un test sigur, preferabil în mediul de test al magazinului și al plății. Notează numărul comenzii, produsele, ora, subtotalul, taxele și transportul. Dacă testul se face în producție, stabilește cum va fi anulat și cum va fi separat din analiză.
Cu instrumentele de diagnostic ale implementării, verifică evenimentul de cumpărare și datele lui. În schema recomandată GA4, transaction_id identifică tranzacția, currency moneda, iar items produsele. Valoarea value reflectă produsele, fără taxele și transportul trimise separat. Testează datele efectiv trimise, nu doar setarea bifată în plugin.
O comandă pe care o poți verifica pe hârtie
Exemplul este fictiv și folosește valori fără taxe la nivel de produs. Comanda TEST-1042 are două pungi de cafea la 80 lei și un filtru la 40 lei. Valoarea produselor este 2 × 80 + 1 × 40 = 200 lei. În documentul de test, taxele comunicate de magazin sunt 42 lei, iar transportul este 15 lei. Totalul exemplului este 257 lei. Folosește câmpurile și taxele efectiv calculate de magazinul tău; acesta este un test de măsurare, nu un model de facturare.
| Ce verifici | Valoare așteptată în exemplul GA4 |
|---|---|
| Eveniment | purchase |
| transaction_id și currency | TEST-1042 și RON |
| value | 200, valoarea articolelor, fără cele 42 taxe și 15 transport |
| items | CAF-80, preț 80, cantitate 2; FIL-40, preț 40, cantitate 1 |
| tax și shipping, dacă le trimiți | 42 și 15, în câmpurile lor separate |
În documentația GA4, value pentru purchase se raportează la suma preț × cantitate a articolelor, fără taxe și transport. Dacă prețurile din catalog includ taxe, integrarea trebuie să aplice o convenție corectă și consecventă pentru datele trimise; nu scădea sau adăuga TVA a doua oară. Cu reduceri, verifică prețul efectiv la nivel de articol și modul în care integrarea îl transmite. Etalonul este o comandă cu linii pe care le poți recalcula, nu doar totalul mare din ecran.
În modul de diagnostic al implementării urmărește evenimentul și parametrii. Nu copia un snippet nou în site doar ca să vezi un eveniment: dacă pluginul îl trimite deja, ai putea introduce tocmai dublarea pe care o cauți. Repetă pe o plată reușită și pe o încercare de plată refuzată, în condiții de test. Pentru ramburs, documentează dacă evenimentul înseamnă comandă acceptată sau bani încasați. Primirea comenzii și încasarea de la curier au loc în momente diferite.
O comandă nu ar trebui anunțată de două integrări
Verifică dacă același eveniment pleacă și din plugin, și din Google Tag Manager sau din alt cod. Reîncărcarea paginii de confirmare și revenirea din procesatorul de plată sunt situații utile pentru test. Identificatorul tranzacției ajută la recunoaștere și la deduplicare, dar nu înlocuiește o implementare coerentă.
Nu trimite nume, emailuri, telefoane sau adrese în parametrii evenimentelor. Pentru verificare poți folosi ID-ul tehnic al comenzii și date demonstrative care nu identifică o persoană.
Aceeași cumpărare trimisă din browser și de pe server la Meta
Meta Pixel poate comunica din browser, iar Conversions API poate trimite de pe server. Dacă aceeași cumpărare este trimisă prin ambele căi către aceeași sursă de date, Meta folosește numele evenimentului și identificatorul lui pentru a recunoaște perechea. În exemplul nostru, evenimentul standard este Purchase, iar identificatorul ales pentru acea acțiune poate fi purchase_TEST-1042.
În evenimentul de browser identificatorul de deduplicare se transmite în opțiunea eventID; în evenimentul corespunzător de pe server, în câmpul event_id. Valoarea trebuie să coincidă pentru aceeași acțiune, dar nu trebuie refolosită pentru toate comenzile. Un număr aleatoriu generat independent în fiecare loc produce două identificatoare diferite. Un text fix precum „purchase” pus la toate tranzacțiile ar crea o problemă opusă.
În Events Manager, zona de testare a evenimentelor și diagnosticele disponibile te pot ajuta să verifici sursele și perechea. Verifică și logurile propriei implementări pentru comanda cunoscută, fără să trimiți date personale în parametrii de analiză. Calitatea potrivirii cu utilizatorii și deduplicarea aceleiași acțiuni sunt lucruri diferite. Un scor de potrivire nu dovedește că evenimentele sunt deduplicate corect. Implementarea de server nu este o metodă de ocolire a consimțământului.
Compară totaluri care înseamnă același lucru
Aliniază perioada și fusul orar. Separă comenzi create de comenzi plătite și de comenzi confirmate. Verifică tratamentul retururilor și rambursărilor; acestea nu dispar din analiză doar fiindcă au fost operate în alt sistem. GA4 are un eveniment dedicat rambursării, care trebuie implementat dacă vrei acea informație în raport.
Consimțământul, blocarea scripturilor și felul în care sunt prelucrate rapoartele pot crea diferențe față de magazin. Notează ce se măsoară și ce rămâne necunoscut.
Cum cercetezi diferența 10 față de 7
Începe cu definițiile. „10” este totalul Purchase primite în Events Manager sau cumpărările atribuite unei campanii în Ads Manager? Prima vedere privește evenimentele primite de sursa de date; a doua răspunde unei întrebări de atribuire. „7” în magazin înseamnă comenzi create, plătite, livrate sau încă nerambursate? Scrie răspunsurile chiar lângă numere.
Un posibil exemplu: magazinul a creat 9 comenzi în perioada aleasă, dintre care 2 au fost apoi anulate și 7 sunt confirmate. Integrarea a trimis Purchase la crearea comenzii. Cele două anulări explică de ce 9 comenzi create și 7 confirmate sunt totaluri diferite. Nu demonstrează încă de ce Ads Manager raportează 10. Verifică setarea de atribuire și data alocării rezultatului, fusurile orare, sursele evenimentelor și eventualele dublări la revenirea din procesator. Faptul că ai găsit o explicație posibilă nu înseamnă că ai identificat și comanda „a zecea”.
Poți verifica tehnic evenimente de test și poți reconcilia comenzile în sistemele tale, dar nu vezi din Ads Manager identitatea fiecărei persoane atribuite. Google Ads poate acorda la rândul lui credit unora dintre aceleași comenzi. Dacă aduni 10 la Meta și 6 la Google nu rezultă automat 16 comenzi distincte.
O diferență mai poate apărea chiar la granița dintre luni. Exemplu: clickul pe Google vine pe 31 octombrie, iar plata se confirmă pe 2 noiembrie. Dacă un raport al campaniei pune conversia la data interacțiunii, o poți vedea în octombrie; magazinul o va avea în noiembrie. În Google Ads compară și coloanele care raportează după momentul conversiei. Alegerea acestei coloane ajută la compararea perioadelor, dar nu transformă atribuirea Google într-o listă completă a comenzilor magazinului.
În Google Ads verifică și dacă ai simultan o acțiune nativă de cumpărare și un purchase importat din GA4 în același obiectiv. Compară acțiunile și setările efectiv folosite pentru licitare. Deduplicarea unei tranzacții într-o integrare nu promite deduplicare între două platforme sau între două acțiuni diferite configurate de tine.
Păstrează o verificare simplă și repetabilă
După o schimbare de temă, checkout, plugin de plată sau consimțământ, repetă testul. Un tabel cu ID-ul testului, evenimentul văzut și valorile așteptate este suficient pentru început.
Fișa minimă pentru următoarea intervenție
| Probă | Ce aștepți să se întâmple |
|---|---|
| Plata reușește | Comanda de test există, evenimentul are o singură identitate, moneda și liniile sunt corecte |
| Reîncarci confirmarea | Nu apare o nouă cumpărare pentru aceeași acțiune |
| Plata este respinsă | Nu se înregistrează drept plată reușită; starea comenzii corespunde convenției documentate |
| Clientul refuză categoriile opționale de consimțământ | Comportamentul etichetelor respectă configurația și opțiunea exprimată |
| Se rambursează un articol | Dacă măsori rambursări, refund folosește ID-ul tranzacției inițiale și articolul/cantitatea rambursată |
Nu trimite în GA4 adresa de email, numărul de telefon ori câmpurile libere din formular. Pentru o agenție care măsoară solicitări, generate_lead are sens după confirmarea unei cereri valide. Clickul pe „Trimite”, începutul formularului și răspunsul de succes al serverului sunt trei momente diferite. Verifică o încercare validă și una respinsă: o eroare de validare nu trebuie să fie numărată drept solicitare reușită.
Când ceri ajutor pentru măsurarea campaniilor, trimite numele integrărilor și valorile așteptate ale unui test, fără date personale. Întrebarea bună devine „de ce acest eveniment pleacă de două ori la revenirea din plată?”, nu „care dintre cele trei platforme are dreptate?”.
Ce faci mâine dimineață
- Fă o comandă de test (ideal în mediul de test al plății) și urmărește evenimentul `purchase` în GA4 DebugView și în Meta Events Manager: valoare, monedă, ID, o singură dată.
- Reîncarcă pagina de confirmare și revino din procesator fără să plătești. Nu trebuie să apară o a doua cumpărare.
- Scrie lângă fiecare număr din raport ce înseamnă (evenimente primite, comenzi create, comenzi confirmate, credit de atribuire) înainte să le compari.
Sumele și situațiile din acest ghid sunt exemple ipotetice, fără TVA. Nu sunt rezultate ale unor clienți G-Smart și nu sunt ținte ale platformelor. Refă calculul cu cifrele afacerii tale.
Surse
- Google Analytics · Definițiile evenimentelor recomandate — Parametrii GA4 pentru purchase, refund și generate_lead.
- Meta for Developers · Același eveniment din browser și server — Ghidul Meta pentru același eveniment primit din browser și server.
- Google Ads · Acțiuni principale, secundare și obiective personalizate — Rolul acțiunilor native sau importate în obiectivele Google Ads.
- Google Ads API · Conversii repartizate la data conversiei — Cum diferă indicatorii raportați după data conversiei.


