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ă declanșează pâlnia PrestaShop completă: călătoria de la descoperire până după achiziție — navigare și pagini de produs, fiecare mișcare din coș, fiecare pas de checkout, vânzarea însăși și semnalele post-vânzare și de cont care urmează. Grila pas-cu-pas de pe pagina modulului listează fiecare eveniment după nume. GA4 înregistrează și evenimente automate — session_start, first_visit, user_engagement — de unul singur; o configurare sănătoasă le păstrează în loc să se lupte cu ele, așa că numerele tale de sesiuni și de utilizatori noi rămân corecte.

Împreună, aceste 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 imaginea completă.

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. Sub-numărarea 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 construit din comanda însăși 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ă — pentru asta, trebuie să se schimbe livrarea însăși.

Repară livrarea, nu doar tag-urile

Cea mai importantă schimbare este să nu mai ceri deloc browserului să îți raporteze vânzările. Când PrestaShop confirmă o comandă, PrestaSignal raportează vânzarea din back office-ul tău către un server de tracking administrat de noi pentru tine, care o transmite către GA4 cu suma reală plătită, moneda și un transaction_id construit din comanda însăși. Vânzarea este înregistrată exact o singură dată — o reîncărcare nu poate număra niciodată dublu — iar retururile urmează cu transaction_id-ul corespunzător, așa că GA4 stornează venitul corect.

Evenimentele de zi cu zi rămân în browser, unde le este locul datelor comportamentale — dar nu mai călătoresc către domeniile Google. Modulul plasează un mic conector pe adresa propriului tău site, iar vizualizările de pagină, vizualizările de produs și evenimentele de coș se înregistrează prin el; chiar și bibliotecile de tag-uri Google se încarcă de pe domeniul tău. Listele de filtrare ale ad blocker-elor de azi țintesc googletagmanager.com și google-analytics.com, așa că, având totul servit de pe propria ta adresă, pe pagină nu există niciun domeniu de analiză terț cu care să se potrivească.

Este un singur design integrat, nu un mod pe care să-l alegi: evenimentele de browser pe un drum, vânzările tale pe un al doilea drum fără browser, ambele împărțind un event_id, astfel încât GA4 să le deduplice. Și datele personale sunt gestionate acolo unde trebuie — modulul normalizează și hashuiește cu SHA-256 emailul, telefonul și numele în interiorul magazinului tău, înainte ca orice să îl părăsească. Citește cum funcționează pentru detaliile specifice PrestaShop.

Nimic din toate astea nu înseamnă să o iei de la capăt. Păstrezi aceeași proprietate GA4, același measurement_id și tot istoricul tău; ce se schimbă este drumul pe care circulă evenimentele tale, nu locul unde ajung.

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 construit din comanda însăși. measurement_id se potrivește cu proprietatea ta de raportare și cu nimic altceva. Iar vânzarea este raportată din back office-ul tău, nu din browser, împărțind un singur event_id cu partea de browser, așa că nimic nu se numără de două ori.

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.