Un audit publicat de Search Engine Journal pe opt magazine online din Marea Britanie arată că GA4 a ratat masiv comenzile reale. La un magazin, în perioada Crăciunului 2025, GA4 raporta o scădere de 68% pe zi față de anul anterior, în timp ce comenzile reale scăzuseră doar 13%. Rata de captură a căzut de la 81% în trimestrul 4 din 2024 la 41% în trimestrul 4 din 2025 și la 32% în perioada sărbătorilor. Concluzia practică: GA4 nu este registru de vânzări, ci unealtă de comportament. Sursa: Search Engine Journal.

Ce a găsit auditul, pe scurt

Autorul, Christian Goodrich, a comparat cifrele GA4 din trimestrele 4 din 2024 și 2025 cu evidențele de comenzi ale magazinelor. La șase din opt magazine a putut face potrivirea completă, iar la trei poveștile au fost complet diferite. Cauzele identificate sunt de trei tipuri.

Prima este bannerul de consimțământ care se oprea singur. Două magazine trecuseră pe un setup de consimțământ nou, cu un plafon de vizualizări de pagină pe lună. Când plafonul se termina, bannerul nu mai apărea până la data următoare de facturare. La un magazin, zilele lipsă din GA4 se încheiau mereu pe 14 ale lunii, la altul pe 20. GA4 continua să primească date parțiale, așa că nimic nu părea rupt. Cifrele arătau ca o prăbușire de vânzări, nu ca o problemă tehnică.

A doua este blackout-ul urmat de backfill târziu. Un magazin a avut 2.215 comenzi între 28 octombrie și 4 decembrie 2025, iar GA4 nu a înregistrat niciun purchase. Pe 9 decembrie au intrat 1.261 de purchase-uri într-o singură zi, dintre care 1.000 cu numere de comandă din intervalul lipsă. Aproape toate au ajuns în Unassigned.

A treia este dubla numărare. La același magazin, 657 din 3.365 de numere de comandă aveau mai mult de un purchase event, adăugând 735 de purchase-uri în plus. Pe totalul trimestrului erorile aproape se anulau: 4.100 purchase-uri în GA4 față de 4.501 comenzi reale. Cine se uită doar la totalul trimestrial nu vede nimic.

Al patrulea magazin a fost inundat de boți în septembrie: 23.187 de sesiuni într-o zi față de 300-900 în mod normal, aproape toate direct, desktop Chrome, cu o secundă de engagement. Click-urile din Search Console nu s-au mișcat.

De ce contează rata de captură mai mult decât totalul

Diferența dintre comenzile din magazin și purchase-urile din GA4 se numește rată de captură. Ea nu trebuie să fie 100%, pentru că o parte din cumpărători refuză trackingul, iar asta e normal și legal. Problema apare când rata de captură se schimbă brusc de la o săptămână la alta sau când scade în trepte.

În audit, un magazin a stat constant la 76% în ambii ani, altul între 72% și 84% în fiecare săptămână din trimestrul 4 2025. Asta e forma sănătoasă a gap-ului de consimțământ. În schimb, o rată care sare de la 94% la 36% nu e comportament de cumpărător, e problemă de tracking.

Recomandarea practică din material: exportă comenzile web săptămânal pentru trimestrul 4 din 2024 și 2025, fără marketplace, abonamente și comenzi manuale. Trage din GA4 purchase-urile pe aceleași săptămâni ca transaction ID-uri distincte, nu metricul transactions, care include și refund-uri. Împarte apoi purchase-urile GA4 la comenzile magazinului. O treaptă bruscă, o săptămână aproape de zero sau una peste 100% înseamnă problemă de tracking, nu de vânzări.

Search Console ca sistem de alarmă timpurie

Un truc simplu și subevaluat: împarte sesiunile organice Google din GA4 la click-urile din Search Console, săptămânal. Search Console numără un click ori de câte ori un rezultat trimite pe cineva în afara Google, indiferent ce fac tag-urile site-ului. Când trackingul cade, raportul se prăbușește.

În blackout-ul unui magazin, Google a trimis 4.244 de click-uri în săptămâna 3 noiembrie, iar GA4 a înregistrat 57 de sesiuni organice Google. Search Console a stat stabil tot intervalul. Asta e diferența dintre „traficul a murit" și „măsurătoarea a murit". Dacă ai un raport săptămânal cu acest raport, problema se vede în câteva zile, nu în ianuarie când faci retrospectiva.

Ce faci cu trackingul de purchase

Cea mai solidă recomandare din material este mutarea purchase-ului pe server-side. Majoritatea setup-urilor GA4 înregistrează purchase-ul în browserul cumpărătorului, unde o actualizare de checkout, o eroare de script, un ad blocker sau un refresh îl poate pierde sau dubla. Soluția: trimite purchase-ul din sistemul magazinului, la crearea comenzii, prin Measurement Protocol sau printr-un container server-side alimentat de magazin, cu cheie pe numărul comenzii.

Trece și client ID-ul și session ID-ul din GA4, capturate la checkout, ca GA4 să poată lega comanda de vizită. Păstrează tag-ul din browser pentru comportament, pentru că Measurement Protocol e gândit să completeze colectarea automată, nu să o înlocuiască. Și nu uita: trackingul server-side nu schimbă obligațiile de consimțământ, deci gap-ul constant rămâne. Dacă începi acum, trimite evenimentele într-o proprietate GA4 separată pe durata trimestrului 4, ca să nu dublezi nimic, în loc să faci switch-ul în noiembrie.

Atenție și la securitate: un script de analytics compromis poate face mult mai rău decât să piardă comenzi. Am scris despre cazul Convertr, script de analytics compromis cu skimmer pe checkout, care arată de ce orice tag injectat în checkout trebuie tratat ca suprafață de atac.

Ce înseamnă pentru tine, ca marketer în România

Dacă vinzi online în România, ai aceleași trei riscuri, doar că bannerul de consimțământ e livrat de alt vendor și plafoanele sunt altfel configurate. Pașii concreți pe care i-aș face săptămâna asta:

Primul, scoate un export cu comenzile reale pe ultimele 8-12 săptămâni, separat pe surse, fără marketplace. Al doilea, trage purchase-urile din GA4 ca transaction ID-uri distincte pe aceleași săptămâni și calculează rata de captură. Al treilea, pune în calendar o verificare săptămânală a raportului sesiuni organice Google împărțit la click-uri Search Console. Al patrulea, întreabă vendorul de consimțământ ce plafon are planul curent și dacă alerta de limită ajunge la marketing, nu doar la developer.

Pe partea de buget, exemplul din audit e cel care doare. La un magazin, comenzile web din trimestrul 4 au crescut de la 5.874 la 7.686, în timp ce GA4 arăta o scădere de o treime. În GA4, randamentul Google Ads scădea de la 8,07 la 4,79, iar venitul din organic aproape se înjumătățea. Potrivit pe comenzile magazinului într-un tool de atribuire multi-touch, randamentul Google Ads creștea de la 4,42 la 7,93 pe un buget cu 20% mai mic, iar venitul atribuit organic și direct creștea cu 58%. Modelele diferă, dar nu ar trebui să arate în direcții opuse. Dacă tăiai buget pe cifrele GA4, tăiai din canale care funcționau.

Asta se leagă direct de discuția despre Google AI Mode și ce înseamnă pentru SEO: cu cât mai multe suprafețe aduc trafic, cu atât mai important e să ai o sursă de adevăr pentru vânzări, nu doar metrici de platformă. Iar dacă lucrezi pe Shopify, mutarea payout-urilor în Dev Dashboard, despre care am scris aici despre Shopify și payout-urile din Dev Dashboard, e un moment bun să verifici și ce tag-uri rulează în checkout.

Ce rămâne de verificat, nu de presupus

Auditul e pe opt magazine din Marea Britanie, cu un autor care declară că agenția lui a lucrat cu toate cele opt. Nu e un studiu reprezentativ la nivel de piață și nu dovedește că orice cont GA4 are aceleași probleme. O verificare incompletă nu dovedește absența unei funcții sau a unui element. Dacă rata ta de captură arată stabilă, nu ai dovada că trackingul e perfect, ai dovada că nu vezi o ruptură în datele pe care le ai.

Nu afirma pierderi de bani sau efecte pe CPA doar dintr-un audit automat. Verifică întâi potrivirea cu comenzile reale, apoi trage concluzii despre buget. Și nu transforma o ipoteză într-o certitudine: dacă bănuiești boți, uită-te la pattern-uri (direct, desktop, engagement de o secundă, fără mișcare în Search Console) și blochează-i la firewall, cu excepția crawlerelor verificate precum Googlebot.

FAQ

GA4 e obligatoriu să arate toate comenzile? Nu. Gap-ul de consimțământ e normal și legal. Problema e schimbarea bruscă a ratei de captură, nu existența unui gap constant.

Pot muta trackingul de purchase pe server-side fără să pierd datele din browser? Da, dacă păstrezi tag-ul din browser pentru comportament și trimiți purchase-ul separat, prin Measurement Protocol sau container server-side, cu cheie pe numărul comenzii. Testează într-o proprietate separată înainte de switch.

Cât de des verific rata de captură? Săptămânal în sezonul de vârf. O treaptă bruscă sau o săptămână aproape de zero se vede imediat, nu în ianuarie.

AI-ul ajută la analiză, decizia rămâne la om

Un model bun poate să-ți structureze exportul, să calculeze rata de captură pe săptămâni și să semnaleze anomalii în date. Ce nu poate face e să decidă dacă o scădere din GA4 e reală sau de tracking, și nici să oprească bugetul pe un canal care funcționează. Decizia și execuția rămân la media buyer, care validează cifrele față de comenzile reale înainte să miște ceva. Pasul concret îl face ALLSoft Agency: verificăm rata de captură, curățăm trackingul și punem la punct un sistem de alarmă înainte de vârful sezonului, fără promisiuni de cifre pe care nu le putem susține cu date.