Cum să recuperezi conversiile pe care le ascund ad blocker-ele

O parte din conversiile tale nu ajung niciodată în analiza ta — nu pentru că vânzările nu au avut loc, ci pentru că browserul clientului a refuzat să le raporteze. Ad blocker-ele, extensiile de confidențialitate și restricțiile de tracking ale Apple anulează în tăcere cererile care îți poartă evenimentele de tracking. Nimeni nu îți poate spune exact cât pierzi — nu există nicio medie de industrie verificabilă — și tocmai asta e problema: din interior, pierderea este invizibilă.

Comanda aterizează în back office-ul tău PrestaShop, banii intră în cont, dar GA4, Google Ads și Meta nu află niciodată de ea. Îți optimizezi campaniile și îți judeci magazinul față de cifre cărora le lipsește o bucată mare și înclinată din realitate. Iată exact cum se produce pierderea — și cum o aduce înapoi un design first-party, server-side.

Cum îți anulează blocker-ele evenimentele

Tracking-ul clasic este client-side: un script din browserul cumpărătorului declanșează evenimente precum page_view și purchase către Google sau Meta. Ad blocker-ele și extensiile de confidențialitate mențin liste de blocare cu domenii de analiză și publicitate — googletagmanager.com și google-analytics.com stau aproape de vârf — și anulează orice cerere care se îndreaptă spre unul dintre ele înainte să părăsească browserul.

Din partea ta, asta este complet tăcut. Nu există nicio eroare, niciun avertisment, nicio înregistrare nicăieri — evenimentul pur și simplu nu a existat niciodată din perspectiva analizei tale. Aproximativ 3 din 10 utilizatori de internet folosesc un ad blocker (GWI, 2025), iar adopția urcă mai sus printre cumpărătorii mai tineri, mai tehnici și mai conștienți de confidențialitate.

Pentru că adopția înclină exact către audiențele pe care multe magazine le vor cel mai mult, pierderea nu este zgomot aleatoriu de care poți face abstracție. Este o gaură sistematică, înclinată, în datele tale, care distorsionează care campanii și segmente par profitabile.

ITP și problema expirării cookie-urilor

Ad blocker-ele sunt doar jumătate din poveste. Intelligent Tracking Prevention (ITP) de la Apple, integrat în Safari și iOS, atacă cookie-urile de care depinde tracking-ul. Conform propriei politici WebKit a Apple, 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 (webkit.org).

Efectul este subtil, dar coroziv. Un cumpărător care dă click pe o reclamă azi și cumpără săptămâna viitoare se întoarce cu cookie-ul de tracking deja expirat, așa că arată ca un vizitator complet nou, neatribuit. Vânzarea poate fi totuși înregistrată, dar lipsită de campania care a generat-o. Înmulțește asta pe o bază de clienți preponderent mobilă și o mare parte din atribuirea ta se evaporă în tăcere.

App Tracking Transparency agravează asta tăind semnalele inter-aplicații și inter-site, lovind Meta în mod special. Glosarul nostru definește ITP, ATT și restul acestor termeni pe înțelesul tuturor.

De ce supraviețuiește designul first-party, server-side

Rezolvarea are două jumătăți, pentru că pierderea are două jumătăți.

Prima jumătate sunt banii. Cu PrestaSignal, purchase și refund nu depind deloc de browser: 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. Ad blocker-ele trăiesc în browser și pot anula doar cereri care îl părăsesc — nu au nicio acoperire într-un apel pe care îl face serverul magazinului tău. Vânzarea este înregistrată exact o singură dată, iar un retur urmează cu transaction ID-ul corespunzător, așa că venitul se stornează corect.

A doua jumătate este tot restul — vizualizări de pagină, vizualizări de produs, pași de coș și de checkout. Acestea se întâmplă în continuare în browser, dar nu mai călătoresc către un domeniu de analiză terț. Modulul plasează un mic conector pe adresa web proprie a magazinului tău, iar browserul înregistrează evenimentele prin el — același domeniu de pe care cumpărătorul deja cumpără — cu bibliotecile de tag-uri Google servite tot de pe domeniul tău. Blocker-ele lucrează cu liste de filtrare de domenii de tracking cunoscute: listele de azi țintesc domeniile Google, iar cu totul încărcându-se de pe propria ta adresă, pe pagină nu există niciun domeniu de analiză terț cu care să se potrivească.

Aceasta este diferența structurală: evenimentele de zi cu zi rămân pe teren first-party, unde listele de filtrare de azi nu țintesc, iar evenimentele care plătesc facturile nu ating browserul deloc. Vezi server-side vs client-side pentru comparația completă, sau cum funcționează specific pe PrestaShop.

Cum arată de fapt recuperarea

Când comercianții mută tracking-ul achizițiilor pe server-side, conversiile pe care browserele cumpărătorilor lor le blocau devin din nou vizibile — mai ales pentru audiențe grele pe iOS sau pe folosirea de ad blocker-e. Asta nu este o creștere de fațadă într-un tablou de bord; sunt vânzări reale care devin vizibile pentru sistemele care îți cheltuiesc banii.

Efectele secundare contează mai mult decât cifra principală. Smart Bidding-ul Google și optimizarea Meta învață amândouă din datele de conversie. Alimentează-le cu conversiile recuperate și văd în sfârșit valoarea reală a fiecărui click și a fiecărei audiențe, încetează să liciteze prea puțin pe campanii în tăcere profitabile și redistribuie bugetul către ce funcționează cu adevărat.

Raportarea ta revine, de asemenea, la realitate: ratele de conversie încetează să pară artificial de mici, ROAS-ul încetează să pară artificial de slab, iar venitul din GA4 începe să se alinieze cu banii din contul tău.

Recuperarea nu este o portiță

Merită să fim clari despre ce este și ce nu este tracking-ul server-side. Nu este un truc pentru a urmări oameni care au refuzat consimțământul și nu este un mod de a ocoli legea privind confidențialitatea. Evenimentele respectă în continuare semnalele de consimțământ, iar datele personale sunt normalizate și hashuite cu SHA-256 înainte să îți părăsească vreodată magazinul.

Ce repară tracking-ul server-side este un eșec tehnic de livrare: conversii legitime, cu consimțământ, pe care browserul le-a renunțat din motive care nu au nimic de-a face cu dorințele clientului. Un cumpărător a cărui comandă nu a reușit să se raporteze pentru că i s-a închis tab-ul sau i-a căzut rețeaua nu a refuzat nimic.

Rulat corect, cu consimțământul respectat și cu un banner și o politică în vigoare, tracking-ul server-side este pur și simplu o conductă mai fiabilă pentru datele pe care ai deja dreptul să le colectezi. Dacă vrei ca propria ta pierdere să fie măsurată față de comenzi reale, programează o analiză.