Cum să configurezi tracking-ul ecommerce GA4 pe PrestaShop (corect)

Google Analytics 4 poate fi un instrument cu adevărat puternic pentru un magazin PrestaShop — sau o sursă de cifre în care, în secret, nu ai încredere. Diferența stă aproape întotdeauna în configurare. Pune corect evenimentele ecommerce, venitul și metoda de livrare, iar GA4 devine o imagine fiabilă a pâlniei tale. Le faci greșit, și iei decizii pe date care, în tăcere, nu sunt de acord cu back office-ul tău.

Aceasta este varianta practică: ce să urmărești, cum și greșelile care îi prind aproape pe toți. Este scrisă pentru proprietari de magazine, nu pentru analiști, ca să poți spune dacă configurarea ta chiar își face treaba.

Evenimentele ecommerce care contează

GA4 are un set definit de evenimente ecommerce recomandate, iar o configurare PrestaShop corectă le declanșează pe cele care corespund pâlniei tale. Lista de bază merge de la descoperire până după achiziție: page_view, view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, și semnale post-vânzare precum refund, plus evenimente de cont precum sign_up.

Împreună, aceste aproximativ treisprezece evenimente îi permit GA4 să reconstruiască întreaga călătorie: câți oameni au văzut o categorie, au vizualizat un produs, au început checkout-ul și au finalizat. Golurile din mijloc strică rapoartele de pâlnie și fac imposibilă vederea locului unde renunță cumpărătorii.

Fiecare eveniment are nevoie și de parametrii corecți — ID-uri de articol, nume, prețuri, cantități și o monedă — altfel rapoartele ecommerce ale GA4 rămân goale, deși evenimentele se declanșează. Cel mai frecvent eșec este declanșarea lui purchase fără un array de articole sau fără valoare, ceea ce face raportarea veniturilor inutilă. Vezi pagina noastră Tracking GA4 pentru maparea completă către hook-urile PrestaShop.

measurement_id: pune instalația la punct

Fiecare flux de date GA4 are un measurement_id (valoarea G-XXXXXXX). Îi spune Google cărei proprietăți îi aparțin evenimentele. Pare banal, dar ID-urile de măsurare nepotrivite sau lipsă sunt un motiv surprinzător de frecvent pentru care datele aterizează nicăieri — sau în proprietatea greșită cu totul.

Folosește un singur measurement_id consecvent între client-side și server-side și confirmă că se potrivește cu proprietatea din care raportezi efectiv. O greșeală clasică este să ai ID-ul unei proprietăți vechi hard-codat într-o temă, în timp ce noua proprietate stă goală, lăsându-te să te holbezi la zerouri și să presupui că tracking-ul este stricat.

Dacă rulezi magazine de staging și de producție, ține-le fluxurile separate, ca să nu polueze comenzile de test datele live. Nimic nu erodează mai repede încrederea în analiză decât descoperirea că achizițiile tale de QA au umflat veniturile trimestrului trecut.

Trimite venitul cu taxe incluse

PrestaShop poate raporta venitul în mai multe feluri, iar alegerea greșită îți subevaluează în tăcere cifrele. GA4 ar trebui să primească totalul cu taxe incluse pe care l-a plătit efectiv clientul — total_paid_tax_incl — nu subtotalul fără taxe.

Dacă venitul tău din GA4 arată constant mai mic decât back office-ul cu un procent suspect de rotund, o valoare fără taxe este aproape întotdeauna vinovatul. Diferența corespunde cotei tale de TVA.

Repararea aduce venitul din GA4 din nou în linie cu banii pe care i-ai încasat efectiv, ceea ce contează în momentul în care începi să calculezi ROAS sau să alimentezi valori de conversie în Smart Bidding. Licitarea pe valori subevaluate înseamnă a licita prea puțin pe cei mai buni clienți ai tăi.

De ce majoritatea configurărilor pierd conversii în tăcere

Chiar și o configurare GA4 client-side perfect realizată pierde comenzi. Evenimentul purchase se declanșează în browser, așa că ad blocker-ele, ITP-ul Apple, conexiunile mobile lente și cumpărătorii care închid tab-ul de confirmare mănâncă toate conversii înainte ca acestea să ajungă la Google. O sub-numărare de 30-50% este frecventă și este cea mai grea pe mobil și pe audiențele atente la confidențialitate.

Există și problema dublurilor în cealaltă direcție: dacă purchase se poate declanșa de două ori — să zicem la o reîncărcare a paginii sau la un click pe butonul înapoi — cu un ID aleatoriu de fiecare dată, GA4 numără două vânzări pentru o singură comandă. Sub-numărarea și supra-numărarea suprapuse fac numărul real aproape imposibil de dedus.

Un transaction_id determinist derivat din referința comenzii previne dublurile, reducând reîncărcările și reîncercările la o singură comandă. Dar nu poate recupera evenimentele care nu s-au declanșat niciodată — doar livrarea server-side poate face asta.

Fă-o server-side

Soluția pentru scurgeri este să trimiți evenimentele ecommerce — în special purchase — din server, nu din browser. Un container sGTM auto-găzduit primește evenimente de la PrestaShop și le transmite către GA4 cu valoarea, moneda și un transaction_id stabil corecte, imun la orice face sau nu reușește să facă browserul.

Cea mai bună practică este hibridă: evenimente client-side pentru comportament, evenimente server-side ca plasă de siguranță fiabilă, ambele împărțind un event_id astfel încât GA4 să le deduplice. Asta îți oferă deodată bogăția pâlniei complete și numere de comenzi în care poți avea încredere, în loc să te forțeze să alegi între cele două.

Aici își are locul și gestionarea PII. Rutarea datelor printr-un server pe care îl controlezi îți permite să hash-uiești email și telefon înainte ca acestea să ajungă la Google, ceea ce îți menține configurarea mai curată din punct de vedere al confidențialității și îți oferă un singur loc unde să decizi ce îți părăsește magazinul. Citește cum funcționează pentru detaliile specifice PrestaShop.

Nimic din toate astea nu înseamnă să scoți ce ai. Păstrezi aceeași proprietate GA4, același measurement_id și tag-urile tale client-side existente; livrarea server-side stă pur și simplu alături de ele ca stratul fiabil care prinde ce scapă browserul.

O listă scurtă de verificare

Înainte să consideri configurarea ta GA4 terminată, confirmă câteva lucruri. Fiecare eveniment al pâlniei se declanșează cu parametri de articol și monedă corecți. Evenimentul purchase poartă valoarea cu taxe incluse și un transaction_id determinist. measurement_id se potrivește cu proprietatea ta de raportare și cu nimic altceva. Iar evenimentele critice sunt trimise server-side, deduplicate față de versiunea client-side pe un event_id comun.

Parcurge acea listă și vei prinde problemele care subminează în tăcere majoritatea analizelor PrestaShop. Sari peste ea, și riști să construiești strategie pe cifre care arată precise, dar care, în tăcere, sunt greșite.

Dacă asta pare mult de verificat manual, este exact ce configurează PrestaSignal din start. Programează o analiză și îți vom audita evenimentele GA4 actuale față de comenzile tale reale, rând cu rând.