GA4 și WooCommerce: cum verifici evenimentul purchase

Magazinul înregistrează o comandă, dar veniturile din Analytics nu se potrivesc. Uneori lipsește evenimentul purchase. Alteori există două implementări care trimit același lucru. Începe cu o singură comandă de test și urmărește traseul ei, fără să modifici simultan extensia de tracking, containerul GTM și integrarea server-side.

Stabilește ce înseamnă „achiziție” în implementarea ta

Documentează momentul în care evenimentul este trimis: confirmarea comenzii, confirmarea plății sau o altă stare explicită. La plata ramburs, crearea unei comenzi nu este echivalentă cu încasarea. La plata online, pagina de confirmare și notificarea procesatorului pot ajunge în momente diferite.

Nu schimba această definiție fără să actualizezi raportarea. Dacă unele metode de plată trimit purchase la creare și altele numai după încasare, comparațiile trebuie să țină cont de diferență. Într-un diagnostic, notează definiția înainte de a interpreta un total.

Inventariază sursele care pot trimite evenimentul

Verifică extensiile WooCommerce, tagurile GTM, scripturile inserate în temă și integrarea server-side. Un eveniment poate pleca din mai mult de un loc. Fă un tabel cu sursa, condiția de declanșare, destinația GA4 și persoana care administrează configurarea.

Dezactivarea unei surse doar pentru test se face controlat, preferabil pe staging sau într-o fereastră planificată. Păstrează o copie a configurării. Nu elimina o implementare activă înainte să confirmi că cealaltă acoperă scenariile necesare.

Pregătește o comandă de test

Folosește un produs și o metodă de plată pentru care poți urmări fluxul fără confuzie cu vânzările reale. Notează identificatorul comenzii, produsele, cantitățile, reducerea, moneda, transportul și totalurile. Marchează separat testul în evidența internă și exclude-l din interpretările comerciale.

Nu introduce adrese de email, nume, telefoane sau alte date personale în parametrii evenimentului. Pentru verificarea tehnică sunt suficiente identificatoare și valori comerciale potrivite, fără expunerea datelor clientului.

Verifică structura evenimentului purchase

În ghidul oficial pentru măsurarea e-commerce în GA4, purchase folosește un identificator de tranzacție și o listă de produse, alături de valori precum value și currency. Verifică și parametrii fiecărui produs, nu doar numele evenimentului.

{
  "event": "purchase",
  "ecommerce": {
    "transaction_id": "TEST-1042",
    "value": 200,
    "currency": "RON",
    "items": [
      { "item_id": "SKU-101", "item_name": "Produs de test",
        "price": 100, "quantity": 2 }
    ]
  }
}

Exemplul este ilustrativ pentru un dataLayer; nu este un snippet gata de instalat peste orice conector. În acest exemplu simplificat, 2 × 100 = 200. Taxele, transportul și reducerile trebuie tratate consecvent cu specificația și cu integrarea aleasă, nu adăugate automat a doua oară.

Urmărește tranzacția în browser și în GA4

În modul de depanare al implementării, verifică momentul evenimentului și parametrii trimiși. Apoi urmărește evenimentul în DebugView. Prezența în DebugView confirmă un pas al traseului, nu validează automat toate rapoartele sau toate metodele de plată. Documentația DebugView explică utilizarea acestui instrument.

Verifică scenariile de consimțământ permise de configurația site-ului. Nu forța trimiterea datelor prin dezactivarea bannerului doar pentru a vedea un eveniment. Notează starea consimțământului în rezultatul testului.

Testează reîncărcarea și revenirea pe confirmare

Reîncarcă pagina de confirmare și urmărește ce se întâmplă. Revino ulterior la aceeași adresă, când scenariul este permis. Identificatorul tranzacției trebuie să rămână stabil pentru aceeași comandă, nu să fie înlocuit cu un timestamp nou la fiecare accesare.

GA4 folosește transaction_id pentru deduplicarea tranzacțiilor în condițiile descrise în documentația despre tranzacțiile duplicate. Nu te baza exclusiv pe această protecție pentru a păstra două implementări contradictorii: verifică sursa dublării și parametrii efectivi.

Construiește o matrice de test, nu o singură comandă „verde”

Un test reușit pentru un produs simplu plătit cu cardul este un început. Nu acoperă automat variantele, cupoanele și revenirile din pagina procesatorului. Pentru magazinul tău, alege întâi fluxurile care chiar există și scrie rezultatul așteptat pentru fiecare. Un magazin fără ramburs nu are nevoie de un scenariu artificial pentru ramburs; unul care acceptă transfer bancar trebuie să definească separat momentul achiziției.

Păstrează pentru fiecare rând ora, browserul, dispozitivul și starea consimțământului. Aceste detalii te ajută să repeți scenariul, nu sunt parametri pe care trebuie să îi adaugi obligatoriu în Analytics. Un rezultat util arată și ce nu ai testat. „Card și cupon validate, transfer bancar netestat” este mai precis decât „tracking complet funcțional”.

Separă datele din pagină de datele trimise efectiv

Într-o implementare cu GTM există mai multe puncte de control. Mai întâi verifici obiectul publicat în dataLayer. Apoi verifici valorile citite de variabilele containerului. După aceea verifici tagul care s-a declanșat și destinația sa. La final urmărești recepția în proprietatea de analiză corectă. Nu comprima toate aceste etape în observația „se vede purchase în consolă”.

De exemplu, pagina poate conține suma corectă, dar variabila folosită în tag poate citi altă proprietate. Sau containerul de test poate trimite către un flux diferit de cel deschis în DebugView. Pentru fiecare etapă, notează identificatorul tranzacției și valoarea observată. Astfel poți identifica exact unde se schimbă informația, în loc să reinstalezi integrarea fără diagnostic.

Folosește Tag Assistant pentru dispozitivul de test și selectează dispozitivul potrivit în DebugView. Google precizează că activarea depanării și controalele de confidențialitate influențează vizibilitatea evenimentelor. Absența într-o fereastră DebugView nu dovedește singură că site-ul nu a produs nicio solicitare. Nu activa depanarea pentru toți vizitatorii când investighezi doar o comandă. Verifică pașii oficiali pentru DebugView.

Validează calculele cu un exemplu care include reducere

Ia un exemplu demonstrativ în care două articole au prețul unitar relevant pentru eveniment de 90 lei, după o reducere deja aplicată. Valoarea produselor este 180 lei. Dacă transportul este urmărit separat cu 20 lei, nu presupune automat că value trebuie să devină 200 lei. Verifică definiția parametrului și maparea extensiei tale, inclusiv modul de separare a taxelor.

Documentația e-commerce GA4 descrie valoarea prin suma produselor și permite parametri separați pentru transport și taxe. Exemplul nostru este intenționat simplificat; nu stabilește tratamentul fiscal al magazinului. Ceea ce trebuie să demonstrezi tehnic este că suma trimisă poate fi refăcută din datele documentate și că nu ai scăzut cuponul ori adăugat transportul de două ori. Consultă structura oficială a evenimentelor e-commerce.

O listă de produse poate arăta corect vizual și totuși să aibă cantitatea lipsă sau prețuri transmise ca texte formatate pentru afișare. Compară tipurile de date, moneda și zecimalele. Păstrează în fișa de test valorile brute relevante, fără să copiezi întregul obiect al comenzii cu adresa clientului. Un export mic, anonimizat, este mai ușor de verificat și distribuit echipei.

Găsește dublarea la sursă

Presupunem că o comandă produce două solicitări: una dintr-o extensie și una din GTM. Nu decide imediat că trebuie șters GTM. Desenează responsabilitățile: care componentă generează datele, care le citește și care le expediază? Este normal ca un plugin să alimenteze dataLayer, iar un tag să trimită evenimentul. Problema apare când două componente expediază independent aceeași achiziție fără o arhitectură clară.

Pentru aceeași comandă, urmărește dacă identificatorii sunt identici sau diferiți. 1042 și ORDER-1042 sunt șiruri diferite, chiar dacă echipa le consideră aceeași tranzacție. Alege o convenție stabilă la nivelul implementării, apoi verifică toate sursele. Nu reutiliza un identificator fix pentru întregul magazin și nu trimite un șir gol.

Google documentează deduplicarea purchase prin identificator pentru fluxurile web, nu pentru fluxurile de aplicație. Aceasta este o protecție utilă, nu un înlocuitor pentru controlul surselor. Un plan de test corect verifică separat ce emite site-ul și ce apare în raportare. Vezi condițiile deduplicării tranzacțiilor.

Tratează returul ca pe un flux separat

Corectarea unei comenzi în WooCommerce nu înseamnă automat că toate platformele de marketing au primit corecția. Verifică explicit dacă integrarea acoperă evenimentul de rambursare și care este declanșatorul lui. Un retur parțial are nevoie de o explicație diferită față de anularea întregii comenzi. Nu modifica manual valoarea unei achiziții istorice în mai multe locuri fără să urmărești consecințele.

Într-un scenariu demonstrativ, un client păstrează unul dintre cele două produse identice. Fișa de reconciliere trebuie să arate achiziția inițială, produsul returnat, valoarea ajustării și momentul acesteia. Scopul nu este să obții imediat două totaluri identice, ci să poți explica diferențele pe tranzacții și perioade. Ghidul e-commerce Google include și evenimentul refund; implementarea efectivă trebuie verificată în conectorul folosit.

Ce verifici după publicarea modificării

După aprobarea configurației, repetă pe site-ul public un set mic de teste controlate. Înregistrează versiunea containerului ori a pluginului și ora publicării. Verifică faptul că evenimentele ajung în destinația de producție, nu doar în proprietatea folosită la dezvoltare. Confirmă că noile condiții de declanșare nu au blocat alte metode de plată.

Nu evalua o modificare recentă doar din totalul pe întreaga lună, care combină implementarea veche cu cea nouă. Alege intervale și tranzacții identificabile. Dacă ai schimbat și definiția achiziției, marchează această ruptură metodologică în raport: o diferență de venit poate proveni din măsurare, nu din performanța campaniei.

La predare, oferă o matrice cu rezultatele, un exemplu anonimizat de payload, lista surselor active și procedura de revenire. Acesta este un livrabil verificabil. Pentru organizarea traficului care ajunge înainte de comandă, continuă cu ghidul parametrilor UTM; pentru interpretarea economică, citește diferența dintre ROAS și contribuția rămasă.

Întrebări frecvente despre purchase în WooCommerce

Trebuie să reinstalez tracking-ul dacă lipsește o comandă?

Nu porni cu reinstalarea. Verifică întâi definiția achiziției, metoda de plată, consimțământul, destinația și fiecare etapă a traseului. Reinstalarea poate introduce o a doua sursă și poate elimina indicii utile despre problema inițială.

Un eveniment vizibil în DebugView confirmă venitul raportat?

Confirmă recepția acelui eveniment în contextul de depanare. Validează separat valoarea, identificatorul și produsele, apoi interpretarea din rapoarte. Nu extinde rezultatul unei tranzacții la întregul catalog fără scenarii suplimentare.

Pot folosi emailul cumpărătorului ca identificator?

Folosește un identificator comercial al tranzacției fără date personale, nu emailul, numele ori telefonul clientului. Identificatorul trebuie să distingă comenzile, nu să expună persoana. Pentru diagnostic sunt suficiente datele tehnice și comerciale strict necesare.

O fișă scurtă pentru predarea diagnosticului

Pentru fiecare problemă confirmată, scrie observația, dovada și intervenția propusă. „Venitul pare prea mare” este un semnal, nu un diagnostic. „Comanda de test cu identificatorul X produce două solicitări din două taguri diferite” descrie o observație pe care un coleg o poate reproduce. Maschează datele identificabile înainte de a distribui captura.

Leagă schimbarea de o singură versiune de configurare. Dacă modifici tagul și extensia în momente diferite, notează ambele momente și repetă testul între ele. În cazul unei reveniri, trebuie să știi ce parte a sistemului revine la versiunea anterioară și dacă rămâne activă o altă sursă de trimitere.

Păstrează o listă a destinațiilor: fluxul GA4 de producție, eventualul flux de test și alte platforme care folosesc aceleași date. Un obiect dataLayer corect poate alimenta mai multe taguri, dar validarea unei destinații nu le validează automat pe toate. Nu șterge datele comerciale necesare altei integrări când corectezi o mapare locală.

La încheiere, stabilește cine verifică primul interval după publicare și cum semnalează diferențele. Un test tehnic punctual și monitorizarea operațională sunt activități complementare. Prima confirmă scenariile controlate, a doua te ajută să observi cazuri pe care eșantionul inițial nu le-a acoperit.

O predare bună nu promite egalitate absolută între Analytics și evidența financiară. Oferă definiții, exemple reproductibile și limite explicite. Astfel, următoarea diferență de raportare pornește de la o bază documentată, nu de la presupunerea că toate numerele din toate sistemele trebuie să coincidă.

Compară pe aceeași bază

La reconciliere, folosește aceeași perioadă, monedă și definiție a venitului. Separă comenzile anulate, retururile și tranzacțiile de test. Nu aștepta ca un raport Analytics și contabilitatea să fie identice fără a documenta ce includ fiecare.

La final, păstrează un caz validat pentru fiecare metodă importantă de plată și un rezultat pentru reîncărcare. Pentru interpretarea unui payload poți utiliza JSON Lab, fără date personale. Pentru configurare și testarea întregului flux, vezi implementarea Google Analytics 4.