Funcționează cu adevărat tracking-ul tău PrestaShop? O auto-verificare de 5 minute

Cele mai multe tracking-uri stricate nu se anunță singure. Nu există niciun mesaj de eroare, niciun banner roșu — doar cifre care, în tăcere, sunt greșite, ducând la decizii care, în tăcere, sunt proaste. Singurul mod de a ști dacă tracking-ul tău PrestaShop este sănătos este să îl verifici deliberat.

Vestea bună este că o verificare relevantă a stării durează aproximativ cinci minute și nu are nevoie de instrumente speciale dincolo de tabloul tău de bord GA4 și de back office-ul tău PrestaShop. Fă cele cinci verificări de mai jos. Dacă le treci pe toate, configurarea ta este probabil în formă bună. Dacă pici fie și una, probabil pierzi conversii și ar trebui să sapi mai adânc.

Verificarea 1: Compară achizițiile din GA4 cu comenzile reale

Acesta este cel mai revelator test. Alege un interval de date curat — luna trecută este ideal — și extrage două cifre: numărul de evenimente purchase din GA4 și numărul de comenzi valide din back office-ul tău PrestaShop pe aceleași date.

Acum compară. O configurare sănătoasă se încadrează în câteva procente, cu diferențe mici și explicabile (comenzi anulate, comenzi de test, fraudă filtrată). Dacă GA4 este cu 20%, 30% sau mai mult sub back office-ul tău, ai o sub-numărare structurală — simptomul clasic al tracking-ului exclusiv client-side care pierde evenimente din cauza ad blocker-elor, ITP și a tab-urilor închise.

Fă același lucru cu venitul, nu doar cu numărul de comenzi. Dacă venitul din GA4 este mult sub banii pe care i-ai încasat efectiv, diferența este reală și te costă licitare și raportare corecte. Acoperim cauzele în profunzime la server-side vs client-side.

Verificarea 2: Uită-te la ponderea ta de iOS și Safari

Expunerea ta la pierderea de tracking depinde puternic de audiență. În GA4, uită-te la împărțirea sesiunilor pe sistem de operare și browser, concentrându-te pe iOS și Safari.

Cu cât ponderea ta de iOS și Safari este mai mare, cu atât Intelligent Tracking Prevention și App Tracking Transparency de la Apple îți erodează mai mult datele client-side. Un magazin în care cea mai mare parte a traficului mobil este iOS este mult mai expus decât unul dominat de Android, pentru că ITP limitează agresiv cookie-urile client-side pe dispozitivele Apple.

Această verificare nu produce singură un verdict de tip trecut/picat, dar îți spune cât de mult contează celelalte verificări. O pondere mare de iOS înseamnă că până și o diferență mică, vizibilă, ascunde probabil una reală mai mare și ridică urgența mutării evenimentelor cheie pe server-side.

Verificarea 3: Vânează traficul neatribuit și direct

Deschide raportul de achiziție a traficului și uită-te la cât trafic este clasificat ca „unassigned”, „(direct)” sau „(not set)”. O cantitate mică este normală. O pondere mare sau în creștere este un semnal de alarmă.

Când cookie-urile de tracking expiră devreme sub ITP, vizitatorii care se întorc și au sosit inițial dintr-o reclamă sau o campanie revin arătând ca sesiuni complet noi, fără sursă. Acea atribuire nu dispare în tăcere — se adună în categoriile unassigned și direct, umflându-le.

Dacă o felie suspect de mare din conversiile tale este creditată direct sau neatribuit, raportarea ta pe canale este nesigură și aproape sigur sub-creditezi campaniile plătite. Acea atribuire greșită duce direct la tăierea bugetelor care funcționau de fapt.

Verificarea 4: Testează-ți evenimentele cheie în direct

Cifrele în ansamblu pot ascunde goluri; un test în direct confirmă instalația. Deschide raportul în timp real sau DebugView din GA4, apoi parcurge-ți propriul magazin ca un client: vezi un produs, adaugă în coș, începe checkout-ul și finalizează o achiziție de test.

Urmărește apariția fiecărui eveniment: page_view, view_item, add-to-cart, begin_checkout și, în final, purchase. Confirmă că purchase poartă valoarea corectă — totalul cu taxe incluse pe care l-ai plătit efectiv — și un transaction_id rezonabil.

Acum repetă verificarea achiziției cu un ad blocker activat, sau pe un iPhone în Safari. Dacă evenimentul dispare în acele condiții, tocmai ai reprodus, cu propriii ochi, exact pierderea care se întâmplă pe o mare parte din traficul tău real. Aceasta este cea mai convingătoare dovadă care există.

Verificarea 5: Caută dubluri și valori greșite

Pierderea este un mod de eșec; inflația este celălalt. În timp ce testezi, reîncarcă pagina de confirmare sau apasă butonul înapoi și apoi înainte. Dacă apare o a doua purchase în timp real, ai o problemă de duplicare — de obicei un transaction_id aleatoriu, nu determinist.

Verifică, de asemenea, sumar cifrele de venit. Dacă GA4 arată subtotaluri fără taxe în loc de suma plătită de clienți, ROAS-ul tău și licitarea bazată pe valoare funcționează pe baza unor numere subevaluate. Atât dublurile, cât și valorile greșite corup datele din care învață Smart Bidding.

O configurare care numără dublu poate arăta de fapt mai sănătoasă decât realitatea la numărul de comenzi, fiind la fel de stricată. Soluția este o identitate deterministă din referința comenzii, același principiu pe care îl aplicăm la Tracking GA4 și Meta CAPI.

Când să faci o analiză ca lumea

Dacă ai trecut toate cele cinci verificări, bravo — tracking-ul tău este în formă mai bună decât al celor mai mulți. Reia comparația în fiecare trimestru și după orice schimbare de temă, checkout sau modul, întrucât actualizările strică în mod curent tracking-ul în tăcere.

Dacă ai picat una sau mai multe, verificările ți-au spus unde locuiește problema, dar nu întotdeauna cât de adânc merge. O diferență de 30% în GA4, o pondere mare de iOS, trafic neatribuit umflat sau evenimente care dispar sub un ad blocker indică toate același răspuns: cele mai importante conversii ale tale nu ajung fiabil la sistemele care depind de ele.

Acela este momentul în care un audit structurat se merită. Programează o analiză și îți vom măsura diferența reală față de comenzile tale PrestaShop, vom identifica fiecare scurgere și îți vom arăta cât valorează recuperarea ei. Poți citi și despre modul care o închide.