GA4 aproape întotdeauna „funcționează” în magazin: graficele se desenează, sesiunile curg. Auditul pornește de la o altă întrebare: spun evenimentele e-commerce adevărul? Fiecare pâlnie, fiecare analiză și fiecare campanie optimizată pe conversiile GA4 este exact atât de bună cât implementarea de dedesubt. Acest ghid este o listă de verificare pentru audit: setul complet de evenimente, greșelile tipice, acoperirea față de comenzile reale și ritualul de validare.
Listă de verificare
Evenimente e-commerce GA4: setul care trebuie să funcționeze
Traseul de cumpărare în GA4 este format din evenimente standard, cu denumiri definite în documentația Google. Auditul începe cu verificarea faptului că toate sunt trimise și a ceea ce conțin în parametri:
| Eveniment | Când trebuie trimis | Ce trebuie să conțină |
|---|---|---|
| view_item_list | afișarea unei liste / categorii | items cu item_id |
| view_item | accesarea paginii de produs | items, value, currency |
| add_to_cart | adăugarea în coș | items cu cantitate și preț |
| begin_checkout | începerea procesului de comandă | items, value |
| add_payment_info | alegerea metodei de plată | items, payment_type |
| purchase | o dată per comandă plătită | transaction_id, value, currency, items |
Două reguli mai presus de orice: denumiri standard (invențiile proprii de tipul add_to_basket nu alimentează rapoartele e-commerce și nici modelele de conversie) și item_id consecvent, identic cu identificatorii din sistemul magazinului și din feedul de produse. Fără a doua regulă nu poți lega comportamentele de produse concrete, iar pe asta se sprijină întreaga analiză a pâlniei descrisă în ghidul despre combinarea statisticilor GA4 cu vânzările.
Greșeli tipice
Cinci greșeli tipice ale implementărilor GA4 în magazine
Aceleași greșeli apar din magazin în magazin, indiferent de platformă. Note din audituri:
purchase doar pe pagina de mulțumire
După plata cu redirecționare, o parte din clienți nu mai ajung niciodată pe ea. Comanda există, evenimentul nu; acoperirea scade discret și neuniform.
transaction_id lipsă sau repetat
Fără identificator nu există deduplicare: pagina de mulțumire reîmprospătată numără comanda a doua oară. Numărul de evenimente trebuie să fie egal cu numărul de tranzacții unice.
value când brut, când net
O valoare purchase care amestecă taxele și livrarea de la un șablon la altul umflă sau subestimează veniturile în GA4. Stabilește o singură definiție și verific-o pe o comandă de test.
item_id diferit de cel din magazin
GA4 trimite SKU-ul variantei, magazinul raportează ID-ul produsului, feedul încă altceva. Trei sisteme, trei dicționare și nicio analiză comună pe produs.
Denumiri proprii în loc de cele standard
Evenimentele funcționează, dar au denumiri proprii, așa că rapoartele e-commerce rămân goale, iar modelele de conversie nu au date cu care să lucreze.
Metoda principală
Acoperire: compară purchase cu comenzile magazinului
Cel mai puternic test al implementării nu necesită să te uiți în cod: pune față în față numărul și valoarea evenimentelor purchase cu comenzile plătite din sistemul magazinului, perioadă cu perioadă. Această singură cifră (acoperirea) arată dacă te poți baza pe date (date ilustrative, magazin de suplimente):
Acoperire: purchase în GA4 / comenzi plătitemagazin de suplimente · date ilustrative
În săptămâna 3 problema ține de implementare, nu de clienți: după schimbarea procesatorului de plăți, o parte dintre clienți nu mai reveneau pe pagina de mulțumire. Fără monitorizarea acoperirii, o astfel de săptămână ar fi părut „trafic mai slab” și ar fi dus la decizii de buget greșite.
O anumită diferență este normală: blocarea scripturilor, lipsa consimțământului și traseele de plată atipice vor lua mereu câteva procente. Semnalul de alarmă nu este cifra în sine, ci schimbarea de nivel: o acoperire stabilă de luni de zile care scade brusc înseamnă o defecțiune de măsurare. Aceeași logică se aplică valorii: suma value din purchase comparată cu suma veniturilor din comenzile plătite.
Sistemul magazinului îți spune cât ai vândut de fapt. GA4 îți spune cât din asta vede. Auditul are grijă ca a doua cifră să nu se îndepărteze de prima.
Rutina
Validare pas cu pas: comanda de test și DebugView
Auditul calitativ se face manual, pe magazinul live:
Activează DebugView și parcurge traseul
De la listare, prin pagina de produs și coș, până la comanda de test plătită. Fiecare pas trebuie să-și afișeze evenimentul în DebugView, în timp real.
Verifică parametrii fiecărui eveniment
Tabloul items cu item_id, preț și cantitate corecte; în purchase, în plus, transaction_id, value și currency. Compară value cu suma comenzii și cu definiția stabilită (cu sau fără TVA, cu sau fără livrare).
Testează scenariile-limită
Plata cu redirecționare, reîncărcarea paginii de mulțumire, revenirea din istoricul browserului. Aici apar lipsurile și duplicatele, nu pe traseul ideal.
Configurează monitorizarea constantă a acoperirii
Un raport săptămânal cu purchase comparat cu comenzile plătite (număr și valoare). Un audit unic își pierde valabilitatea la prima schimbare de temă, plugin sau procesator de plăți.
Risc real
O implementare defectă strică mai mult decât rapoartele. Campaniile Google Ads învață din evenimentele GA4; o lipsă în purchase înseamnă mai puține semnale de conversie, optimizare mai slabă și comenzi efectiv mai scumpe. Mecanismul diferențelor dintre platformele de reclame și magazin este explicat în ghidul despre conversii și atribuire.
DataOrganizer
Cum verifică DataOrganizer calitatea datelor GA4
DataOrganizer preia evenimentele GA4 și, în paralel, comenzile din sistemul magazinului, așa că acoperirea se calculează din date, fără exporturi manuale: numărul și valoarea purchase comparate cu comenzile plătite, zi de zi. În plus, detectarea automată a anomaliilor semnalează schimbările bruște înainte ca cineva să deschidă un raport:
Acoperirea purchase în ultimele săptămâni:
| Săptămâna | purchase GA4 | Comenzi plătite | Acoperire număr | Acoperire valoare |
|---|---|---|---|---|
| 18.08–24.08 | 418 | 446 | 94% | 95% |
| 25.08–31.08 | 289 | 401 | 72% | 70% |
| 01.09–07.09 | 437 | 459 | 95% | 96% |
În săptămâna 25.08–31.08, acoperirea a scăzut la 72% și a revenit la normal după 01.09, iar numărul comenzilor plătite din magazin s-a schimbat doar puțin (401 față de 446 și 459 în săptămânile vecine), deci pierderea ține de măsurare. Scăderea coincide cu schimbarea procesatorului de plăți; cea mai probabilă cauză este plata cu redirecționare fără revenire pe pagina de mulțumire (de confirmat printr-o comandă de test). Rapoartele GA4 din această săptămână subestimează vânzările; pentru comparații, folosește datele din magazin.
De reținut
Auditul GA4 funcționează doar ca obicei. Calitativ: o comandă de test cu DebugView după fiecare schimbare în magazin. Cantitativ: acoperirea purchase față de comenzile plătite, în fiecare săptămână. DataOrganizer face automat a doua parte, pentru că ține ambele surse una lângă alta.
Întrebări frecvente
Întrebări frecvente despre auditul GA4 în magazin
Ce evenimente e-commerce trebuie să aibă un magazin în GA4?
Traseul standard: view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info și purchase, fiecare cu tabloul items, iar purchase cu transaction_id, value și currency. Denumirile trebuie să fie cele standard din documentația Google; rapoartele de e-commerce nu recunosc denumirile inventate.
De ce arată GA4 mai puține comenzi decât magazinul?
Cel mai des pentru că purchase se declanșează doar pe pagina de mulțumire (unii clienți nu mai revin pe ea după plata cu redirecționare), din cauza blocării scripturilor și a lipsei consimțământului. O diferență de câteva până la câteva zeci de procente este normală; o scădere bruscă a acoperirii înseamnă o defecțiune de măsurare, nu o schimbare în comportamentul clienților.
Ce cauzează duplicatele purchase?
Reîncărcarea sau redeschiderea paginii de mulțumire când lipsește transaction_id. O implementare corectă trimite purchase o singură dată per comandă, cu un identificator unic; auditul compară numărul de evenimente cu numărul de identificatori unici.
Cum verifici corectitudinea implementării?
Calitativ: o comandă de test cu DebugView și verificarea parametrilor fiecărui eveniment, inclusiv în scenarii-limită (redirecționări la plată, reîncărcări). Cantitativ: acoperirea numărului și valorii purchase față de comenzile plătite din magazin, monitorizată constant, nu o singură dată.
Cum ajută DataOrganizer la auditul GA4?
Ține evenimentele GA4 și comenzile magazinului una lângă alta, așa că acoperirea se calculează automat pe totalurile zilnice (numărul și valoarea purchase față de comenzile plătite), iar detectarea anomaliilor semnalează schimbările bruște din date. Întrebarea „GA4 prinde toate comenzile?” primește un răspuns cu cifre într-un minut, împreună cu perioada în care datele nu sunt de încredere.
Rezumatul întregului ghid
Auditul GA4 în trei niveluri
1. Setul complet de evenimente cu denumiri standard. Traseul de la view_item la purchase, cu items, transaction_id, value și currency. Totul se construiește pe această bază.
2. Acoperirea ca indicator permanent de încredere. Numărul și valoarea evenimentelor purchase comparate cu comenzile plătite din magazin, săptămână de săptămână. O schimbare de nivel este o alarmă de implementare, înainte să devină o decizie de buget greșită.
3. Validare după fiecare modificare. O comandă de test cu DebugView după schimbarea temei, a unui plugin sau a procesatorului de plăți. DataOrganizer completează procesul: acoperirea și anomaliile se calculează automat, pentru că datele din GA4 și cele din magazin stau unele lângă altele.
DataOrganizer · GA4 sub supraveghere permanentă
Conectează GA4 și platforma magazinului: totalurile zilnice purchase se compară cu comenzile plătite, iar anomaliile din date sunt semnalate automat. Cont demo disponibil imediat, plătești doar pentru sursele conectate.
