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 diferența este mult mai mare. 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. Aproximativ 3 din 10 utilizatori de internet folosesc un ad blocker (GWI, 2025), iar adopția este semnificativ mai mare în segmentele pasionate de tehnologie sau mai tinere.

Intelligent Tracking Prevention (ITP) de la Apple adaugă un nou strat. Pe Safari și iOS, cookie-urile setate de JavaScript-ul client-side sunt șterse după 7 zile fără o vizită de revenire — și limitate la 24 de ore când vizitatorul aterizează de pe un link decorat cu parametri de tracking (propria politică WebKit a Apple). 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.

Safari duce o parte mare din navigarea pe mobil — StatCounter o urmărește lună de lună — așa că acesta nu este un caz marginal; pentru multe magazine descrie o felie mare din cumpărătorii 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 — 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 construit din comanda însăși — niciodată aleatoriu — 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 scoate evenimentul purchase complet din browserul fragil. Când PrestaShop confirmă o comandă, back office-ul tău raportează vânzarea server-to-server — printr-un server de tracking administrat de noi pentru tine — pe un drum care nu trece deloc prin browser. Vânzarea este înregistrată exact o singură dată, iar retururile urmează cu transaction_id-ul corespunzător, așa că GA4 stornează venitul corect.

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.

Evenimentele de zi cu zi își primesc propria rezolvare. PrestaSignal înregistrează vizualizările de pagină, vizualizările de produs și evenimentele de coș printr-un mic conector pe adresa propriului tău site și servește tot de pe domeniul tău și bibliotecile de tag-uri Google. Listele de filtrare ale ad blocker-elor de azi țintesc domeniile Google — fără niciun domeniu de analiză terț pe pagină, nu mai rămâne nimic pe acele liste care să se potrivească. Iar pentru partea de ITP a diferenței, un cookie first-party setat corespunzător de server (păstrat doi ani) păstrează identitatea unui cumpărător Safari care revine: ștergerea la 7 zile a Apple se aplică cookie-urilor setate de JavaScript, nu celor setate de server. 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ă 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.