De ce numărul de comenzi din GA4 și PrestaShop nu se potrivește (și cum repari asta)

Aproape fiecare comerciant PrestaShop care se uită cu atenție descoperă același lucru: numărul de comenzi din GA4 este mai mic decât numărul de comenzi din back office. Uneori diferența este de câteva procente. Adesea este de 30-50%. Oricum ar fi, asta strică în tăcere fiecare decizie pe care o iei pe baza acelor date — atribuire, bugete de publicitate, rate de conversie și veniturile pe care ți le raportezi singur.

Back office-ul este sursa de adevăr. Înregistrează fiecare comandă care a fost efectiv plătită. GA4, în schimb, depinde de un tag care se declanșează în browserul clientului exact la momentul potrivit. Când acel tag nu se declanșează, comanda tot are loc — doar că GA4 nu află niciodată de ea.

Odată ce înțelegi cele câteva mecanisme din spatele diferenței, soluția devine simplă. Hai să le parcurgem pe rând, apoi să vedem cum o închizi definitiv.

Browserul este un loc ostil pentru a număra bani

Tracking-ul GA4 clasic este client-side: un fragment de JavaScript rulează în browserul cumpărătorului și trimite evenimentul purchase către Google. Sună fiabil până îți amintești tot ce poate merge prost între pagina de confirmare a comenzii și serverele Google.

Cumpărătorul închide tab-ul înainte ca pagina să se încarce complet. Conexiunea îi cade pe mobil în mijlocul unei redirecționări. O eroare de script în altă parte a paginii oprește execuția înainte să ruleze tag-ul tău. Pagina de confirmare redirecționează prea repede pentru ca beacon-ul să apuce să plece. Fiecare dintre acestea îți este invizibilă, și fiecare înseamnă un eveniment purchase pierdut.

Pe paginile de checkout — cea mai importantă pagină din magazinul tău — aceste eșecuri se aglomerează, pentru că exact acolo se întâlnesc redirecționările de plată ale terților, rețelele lente și cumpărătorii nerăbdători. Evenimentele care îți pasă cel mai mult sunt exact cele pe care browserul are cele mai mici șanse să le livreze.

Ad blocker-ele și ITP îți mănâncă conversiile

O mare parte dintre cumpărători folosesc ad blocker-e sau extensii de confidențialitate care blochează complet Google Analytics. Pentru acești vizitatori, achiziția pur și simplu nu se înregistrează niciodată — cererea către Google este anulată înainte să părăsească browserul. Estimările variază în funcție de audiență, dar rate de blocare de ~30% sunt frecvente și semnificativ mai mari în segmentele pasionate de tehnologie sau mai tinere.

Intelligent Tracking Prevention (ITP) de la Apple adaugă un nou strat. Pe Safari și iOS, ITP limitează durata de viață a cookie-urilor setate de JavaScript-ul client-side — adesea la doar 24 de ore sau 7 zile. Un vizitator care dă click pe o reclamă azi și cumpără săptămâna viitoare arată ca o sesiune complet nouă, neatribuită. Comanda poate ajunge totuși în GA4, dar lipsită de campania care a generat-o.

Pentru că Safari și iOS domină traficul mobil pe multe piețe, acesta nu este un caz marginal — pentru multe magazine reprezintă majoritatea cumpărătorilor de pe mobil. Glosarul nostru explică ITP și termenii înrudiți pe înțelesul tuturor.

Inflația sesiunilor face ca diferența să pară și mai mare

În timp ce ad blocker-ele și ITP îți micșorează conversiile, o problemă separată îți umflă sesiunile. Când cookie-urile expiră devreme, o singură persoană pe parcursul mai multor vizite este numărată ca mai mulți utilizatori diferiți în mai multe sesiuni diferite. Numitorul tău (sesiunile) crește, în timp ce numărătorul (achizițiile) scade.

Rezultatul este o rată de conversie care arată mult mai prost decât realitatea. Un magazin care convertește la un sănătos 2,5% ar putea afișa 1,4% în GA4 — nu pentru că s-a schimbat ceva pe site, ci pentru că aceiași cumpărători sunt împărțiți în mai multe sesiuni, în timp ce achizițiile lor dispar în tăcere.

Comercianții apoi „optimizează” față de un număr care nu a fost niciodată corect, taie campanii care erau de fapt profitabile și pun la îndoială un flux de checkout care funcționează bine. Problema de date devine o problemă de business.

Taxa și ID-urile de tranzacție distorsionează și partea de venituri

Chiar și atunci când o comandă este urmărită, cifra de venit poate fi greșită. Multe configurări trimit subtotalul fără taxe în loc de suma plătită efectiv de client. PrestaSignal trimite venitul cu taxe incluse (adevăratul total_paid_tax_incl) astfel încât GA4 să corespundă banilor care au intrat în contul tău, ceea ce contează în momentul în care calculezi ROAS sau alimentezi valorile de conversie în licitare.

Celălalt ucigaș tăcut sunt ID-urile de tranzacție duplicate sau aleatorii. Dacă evenimentul purchase se poate declanșa de două ori — o dată la confirmare, o dată la o reîncărcare a paginii sau un click pe butonul înapoi — și fiecare declanșare folosește un ID aleatoriu nou, GA4 numără două comenzi pentru o singură vânzare. Acum ai sub-numărare din evenimente pierdute și supra-numărare din dubluri, suprapuse una peste alta, ceea ce face ca numărul real să fie aproape imposibil de dedus.

Soluția este un transaction_id determinist derivat din referința comenzii, astfel încât reîncărcările și reîncercările să se reducă la o singură comandă, de fiecare dată.

Soluția server-side

Tracking-ul server-side mută evenimentul purchase din browserul fragil în back end-ul magazinului tău. Când PrestaShop confirmă o comandă, evenimentul este trimis server-to-server — printr-un container sGTM auto-găzduit — unde ad blocker-ele, ITP și tab-urile închise nu pot ajunge la el.

Pentru că evenimentul își are originea în comanda însăși, poartă suma reală plătită și un transaction_id stabil. Nu există nicio cursă contra unei redirecționări, nicio dependență de faptul că cumpărătorul ține tab-ul deschis, nicio extensie care să anuleze cererea.

Cele mai bune configurări rulează un model hibrid: un eveniment client-side deduplicat pentru bogăția comportamentală plus un eveniment server-side ca plasă de siguranță fiabilă, ambele împărțind un singur event_id, astfel încât nimic să nu fie numărat de două ori. Vezi server-side vs client-side pentru comparația completă, sau citește cum funcționează specific pe PrestaShop.

La ce să te aștepți după rezolvare

Odată ce tracking-ul server-side al achizițiilor este implementat, diferența se micșorează de obicei dramatic. Nu vei atinge întotdeauna o potrivire perfectă de 1:1 — câteva diferențe sunt legitime, precum comenzile anulate sau frauduloase filtrate, ori comenzile de test excluse din analiză — dar sub-numărarea structurală de 30-50% dispare.

Efectele secundare sunt cele pe care comercianții le observă cel mai mult. Rata de conversie revine la un număr credibil. ROAS-ul campaniilor încetează să mai pară artificial slab, așa că nu mai tai câștigătorii. Veniturile din GA4 se aliniază cu veniturile din bancă, ceea ce face ca fiecare raport ulterior — și fiecare conversație cu o agenție sau un marketplace — să fie mult mai ușor de încredere.

Dacă vrei să îți vezi propria diferență măsurată față de comenzile tale reale din PrestaShop, programează o analiză și vom cuantifica exact cât pierde GA4 în prezent.