GA4: ce este și cum îl configurezi fără date greșite

GA4 este versiunea actuală a Google Analytics: un instrument gratuit care înregistrează ce fac oamenii pe site-ul tău sub formă de evenimente și le organizează în rapoarte. Instalarea lui este partea ușoară. Partea grea vine imediat după: rapoartele arată credibil chiar și când cifrele din ele sunt greșite, iar o cifră greșită care arată credibil e mai scumpă decât lipsa ei.

Ca leadurile și vânzările să fie măsurate corect, trei lucruri trebuie să fie adevărate în același timp: evenimentul potrivit ajunge în proprietate, el este marcat ca eveniment-cheie, iar proprietatea nu îi distruge valoarea prin monedă, prin perioada de păstrare a datelor sau prin atribuire ruptă la plată. Mai jos e ordinea în care se fac aceste lucruri, cu documentația Google pentru fiecare pas, și un test de acceptanță cu 14 verificări la final. Nu tratăm aici exportul în BigQuery, Measurement Protocol, GA4 pentru aplicații mobile și nici diagnosticul erorii „Direct / not set”.

Ce demonstrează GA4 singur și ce nu

GA4 îți spune ce s-a întâmplat pe site. Nu îți spune de ce s-a întâmplat și nu îți confirmă cât ai încasat. Diferența asta decide dacă îl folosești ca instrument de decizie sau ca sursă de conflicte între departamente.

• Nu demonstrează cauzalitate. O creștere a conversiilor după o campanie nu dovedește că a produs-o campania.
• Nu este sursa de adevăr pentru venit. Sistemul tău de facturare este; GA4 aproximează, iar aproximarea se strică ușor.
• Nu vede ce se întâmplă în afara site-ului: comenzi telefonice, vânzări în showroom, discuții pe WhatsApp, retururi procesate manual de un om.
• Nu compensează o configurare greșită. Un raport frumos construit peste date colectate prost rămâne un raport greșit.

Consecința practică: înainte să compari canale sau să muți buget, trebuie să știi că datele trec un prag minim de corectitudine. Compararea GA4 cu celelalte instrumente din stackul de măsurare — instrumente de sesiune, de heatmap, de raportare — este alt subiect și o tratăm separat.

Proprietatea: ce alegi la creare și ce repari în prima zi

Aici se iau deciziile pe care le plătești cel mai scump, pentru că unele dintre ele nu se mai repară retroactiv. Documentația Google pentru configurarea inițială descrie ordinea, iar ordinea contează: fusul orar și moneda se aleg în ecranul de creare a proprietății, nu mai târziu.

1. Creezi contul — el reprezintă organizația, nu site-ul.
2. Creezi proprietatea și alegi acolo fusul orar de raportare și moneda.
3. Creezi fluxul de date pentru site și obții ID-ul de măsurare, de forma G- urmată de caractere alfanumerice.
4. Instalezi eticheta Google, direct în pagină sau printr-un manager de etichete.
5. Verifici colectarea în raportul Timp real.

Google precizează că poate dura până la 30 de minute până începe colectarea datelor. Dacă în acest interval nu vezi nimic în Timp real, ai o problemă de instalare, nu de răbdare.

Fusul orar și moneda: două setări cu consecințe opuse

Documentația spune despre fusul orar că modificarea lui afectează doar datele viitoare. Nu se rescrie nimic în urmă, deci rămâi cu o discontinuitate în serie exact în ziua în care ai schimbat setarea.

Moneda se comportă invers. Referința Google pentru monede spune că tipul global de monedă al unei proprietăți este, în lipsa altei alegeri, USD, că se schimbă din setările proprietății și că modificarea afectează atât datele viitoare, cât și pe cele istorice, care sunt convertite. Dacă facturezi în lei și proprietatea raportează în dolari, toate valorile de venit din rapoarte sunt convertite, la cursul din ziua precedentă tranzacției.

Notă: Google precizează explicit că nu verifică datele de curs valutar și că acestea pot fi întârziate. Pentru un magazin care încasează în lei, singura variantă care nu adaugă zgomot este ca proprietatea să raporteze direct în RON.

Păstrarea datelor: două valori, și una dintre ele te costă un an

Pe o proprietate standard, păstrarea datelor are exact două valori posibile: 2 luni sau 14 luni. Verifică acum ce valoare are proprietatea ta, pentru că setarea nu se anunță singură și pentru că efectul ei apare abia când ai nevoie de comparații lungi.

• Setarea nu afectează rapoartele standard agregate, ci doar explorările și rapoartele privind canalele.
• Mărirea perioadei se aplică datelor pe care le-ai colectat deja și nu le-ai șters încă.
• Datele care au trecut deja de perioada de păstrare sunt șterse automat, lunar, și nu se recuperează prin schimbarea setării.

Traficul intern: propriul birou îți poluează raportul

Dacă angajații și colaboratorii intră zilnic pe site de la aceleași adrese IP, sesiunile lor se amestecă cu ale clienților. Pe un site cu trafic mic, asta e suficient ca să deplaseze rata de conversie și paginile de top.

Google documentează procedura în doi pași: întâi definești traficul intern la nivel de flux de date, pe adrese IP, apoi creezi un filtru de date care îl exclude. Filtrul are trei stări, iar cea în care se blochează majoritatea implementărilor este „Testing” — în care marchează datele, dar nu exclude nimic.

Citește tabelul pe ultima coloană, nu pe prima: setările care nu se repară retroactiv sunt cele pe care le faci în prima zi, chiar dacă par mărunte. Google avertizează, de altfel, că un filtru de excludere activ are efect permanent — datele excluse nu sunt procesate niciodată și nu devin disponibile ulterior.

Cum verifici că eticheta e instalată o singură dată

Google documentează că ID-ul de măsurare este identificatorul unic al unui singur flux de date web și că este același cu ID-ul de destinație. Documentează, de asemenea, că eticheta Google configurată într-un manager de etichete folosește același ID.

Ce nu documentează Google este ce se întâmplă când același ID ajunge în pagină pe două căi în același timp — de exemplu, prin fragmentul lipit direct în cod și, separat, printr-un manager de etichete. Nu există o pagină oficială pe acest caz, deci nu îți spunem ce ar trebui să se întâmple. Îți spunem cum verifici ce se întâmplă la tine:

1. Deschizi DebugView din secțiunea de administrare, cu modul de depanare activat prin Tag Assistant sau prin parametrul dedicat.
2. Încarci o singură pagină de pe site, o singură dată.
3. Numeri câte evenimente page_view apar pentru acea încărcare.
4. Repeți pe o pagină de conversie — pagina de mulțumire sau confirmarea comenzii — pentru că acolo se instalează cel mai des coduri suplimentare, adăugate în timp de oameni diferiți.

Un page_view este rezultatul așteptat, pentru că măsurarea îmbunătățită îl colectează automat și, spune documentația, colectarea lui nu se poate dezactiva. Două înseamnă că ai două surse care trimit spre același ID și trebuie să elimini una. După verificare, scoate parametrul de depanare din configurație — Google precizează că setarea lui pe false nu îl dezactivează.

Evenimentele care arată drumul real spre vânzare

Un eveniment cu nume inventat funcționează, dar rămâne mut: nu populează rapoartele predefinite. Google recomandă explicit numele standard, tocmai pentru că ele actualizează dimensiuni și valori predefinite și dau acces la rapoarte pe care evenimentele personalizate nu le pot alimenta.

Tabelul se citește ca o secvență, nu ca o listă de opțiuni: dacă implementezi doar primele două, măsori doar ce intră, niciodată ce iese.

Leadul: unde declanșezi generate_lead

Declanșarea pe clic de buton numără intenția, nu rezultatul. Un formular respins de validare, trimis de două ori sau blocat de un câmp obligatoriu produce același clic. Declanșează evenimentul pe confirmarea reală a trimiterii — pagina de mulțumire sau un semnal venit din spatele site-ului.

Vânzarea: purchase, transaction_id și moneda

Documentația pentru dezvoltatori cere currency în format ISO 4217 din trei litere și precizează că, dacă trimiți value, atunci currency devine obligatoriu pentru ca valorile de venit să fie calculate corect. transaction_id este ce îți permite să identifici comanda mai târziu.

Notă: dacă transaction_id nu este unic per comandă, aceeași vânzare poate fi numărată de mai multe ori — de exemplu la reîncărcarea paginii de confirmare.

Rambursarea: evenimentul pe care nu îl trimite nimeni

refund este eveniment recomandat oficial și acceptă transaction_id-ul comenzii inițiale, exact ca să lege rambursarea de vânzare. Nu se colectează automat: dacă nu îl implementezi, retururile pur și simplu nu există în GA4, iar consecința e simplă — raportezi venit brut și îl numești venit.

Pentru un magazin din România diferența nu e cosmetică. Plata la livrare produce refuzuri la primire, iar retururile în termenul legal produc rambursări — ambele apar în contabilitate și niciuna în GA4, dacă nu trimiți evenimentul. Dacă vinzi online, cum lucrăm pe partea de eCommerce pornește exact de la reconcilierea dintre ce arată platforma și ce arată măsurarea.

Cum marchezi evenimentele-cheie și ce ajunge în Google Ads

Un eveniment colectat nu înseamnă un rezultat măsurat. Lanțul documentat de Google are trei trepte, iar majoritatea implementărilor se opresc la prima.

1. Evenimentul este colectat de proprietate.
2. Îl marchezi ca eveniment-cheie din secțiunea de administrare — asta îl scoate în rapoarte ca acțiune importantă.
3. Cu un cont Google Ads conectat, creezi din el o conversie, disponibilă în ambele platforme pentru licitare.

O proprietate standard permite maximum 30 de evenimente-cheie, față de 50 la versiunea 360. Limita e mai mult decât suficientă dacă marchezi rezultate; se atinge rapid dacă marchezi clicuri.

Aici e și punctul în care măsurarea începe să coste sau să aducă bani: campaniile optimizează pe ce le trimiți. Dacă evenimentul-cheie se declanșează pe un clic de buton, algoritmul cumpără clicuri pe buton. Din același motiv, deciziile de buget din Google Ads luate pe conversii reale depind mai mult de ce marchezi în GA4 decât de setările din contul de reclame.

Notă: marchează rezultate, nu pași intermediari. Un „adăugare în coș” marcat ca eveniment-cheie mută optimizarea campaniei către oameni care adaugă în coș și nu cumpără.

Procesatorul de plăți îți rupe atribuirea la checkout

Simptomul arată așa: campania aduce trafic, clientul plătește, iar vânzarea apare atribuită procesatorului de plăți în loc de canalul care a adus clientul. Bugetul se mută apoi în direcția greșită, pentru că sursa reală a dispărut din raport.

Mecanismul este documentat de Google, iar procesatorii de plăți sunt chiar exemplul folosit în pagina despre referralurile nedorite: când clientul finalizează plata pe un domeniu extern și revine pe site, traficul de întoarcere ar fi contorizat în mod normal ca referral de la acel domeniu.

Cele două remedii nu se substituie: excluderea oprește atribuirea greșită, măsurarea între domenii păstrează identitatea utilizatorului. Google le tratează în pagini separate pentru că rezolvă probleme diferite.

Domeniile nu se ghicesc dintr-o listă. Procedura corectă e să le citești din propriile date:

1. Faci o plată de test și notezi domeniul care apare în bara de adrese în timpul plății.
2. După ce ai date din plăți reale, deschizi rapoartele de achiziție și te uiți la sursele de tip referral.
3. Adaugi domeniile procesatorului tău în lista de referraluri nedorite, din setările fluxului de date.
4. Repeți verificarea după ce se adună date noi, ca să prinzi și domeniile secundare folosite la autentificarea plății.

Printre procesatorii folosiți în România sunt Netopia, EuPlătesc și PayU, dar domeniul prin care trece efectiv plata ta depinde de integrarea magazinului, nu de numele furnizorului — de aceea pasul 1 nu se sare. Google documentează un maximum de 50 de referraluri nedorite per flux de date, mai mult decât are nevoie orice magazin, și precizează că sesiunile deja atribuite își păstrează sursa inițială. Dacă simptomul tău este invers — trafic real care ajunge în „Direct” — cauza e de obicei alta, iar diagnosticul complet e în articolul nostru despre „Direct / not set” în GA4.

Consimțământul schimbă ce vezi în rapoarte

Dacă vizitatorul nu acceptă cookie-urile, o parte din date nu se colectează. Asta nu e o eroare de configurare, ci comportamentul așteptat — dar devine eroare în momentul în care compari perioade fără să știi că semnalele s-au schimbat între ele.

Google Analytics urmărește patru semnale de consimțământ:

• ad_storage — stocarea pentru publicitate
• analytics_storage — stocarea pentru analiză
• ad_user_data — trimiterea datelor de utilizator pentru publicitate
• ad_personalization — personalizarea reclamelor

Verificarea se face din raportul Consent settings din secțiunea de administrare, care arată starea semnalelor pentru fiecare flux de date și procentul de trafic din Spațiul Economic European. Google precizează că notificările se pot actualiza în 48–72 de ore după ce începi să trimiți semnalele — deci nu tragi concluzii în aceeași zi.

Partea juridică — ce trebuie să conțină bannerul, ce înseamnă consimțământ valabil, ce riscuri există — este un subiect separat și îl tratăm separat, împreună cu testarea celor patru stări de consimțământ. Aici ne oprim la verificarea tehnică: semnalele ajung sau nu ajung în proprietate.

Testul de acceptanță: 14 verificări înainte să te bazezi pe rapoarte

O implementare nu e gata când vezi date. E gata când datele trec un test pe care l-ai scris înainte să te uiți la ele. Cele 14 verificări de mai jos se pot face fără instrumente plătite și fiecare are un criteriu clar de trecere.

Testul se citește ca un prag, nu ca o listă de bifat pe rând: dacă pică oricare dintre rândurile 1, 2, 5, 8 sau 11, rapoartele de venit nu sunt utilizabile pentru decizii de buget, indiferent cât de bine arată restul. Celelalte rânduri produc erori care se corectează mai târziu fără pierdere de date.

Când nu merită să treci prin tot: dacă site-ul nu are încă tranzacții sau formulare reale, verificările 10–13 nu au ce măsura. Fă-le pe cele de proprietate și de flux acum, pentru că ele nu se repară retroactiv, și amână restul până când există ce măsura.

Întrebări frecvente

GA4 este gratuit pentru o firmă mică?

Da, versiunea standard e gratuită și acoperă confortabil nevoile unei firme mici. Limitele publicate de Google pentru o proprietate standard sunt 30 de evenimente-cheie, 100 de audiențe, 50 de dimensiuni personalizate la nivel de eveniment și păstrarea datelor de maximum 14 luni. Versiunea 360 ridică aceste praguri, dar e o decizie de volum, nu de mărime a firmei.

Pot instala GA4 fără Google Tag Manager?

Da. Google documentează instalarea manuală a etichetei direct în codul paginii, iar pentru un site cu puține evenimente e suficientă. Un manager de etichete devine util când ai mai multe evenimente de întreținut sau când nu vrei să atingi codul site-ului la fiecare modificare.

De ce diferă comenzile din GA4 față de platforma magazinului?

Din trei cauze frecvente, în această ordine: transaction_id care nu e unic și produce dubluri, lipsa evenimentului refund care lasă retururile în afara raportului, și refuzul consimțământului, care oprește colectarea pentru o parte dintre vizitatori. Platforma magazinului rămâne sursa de adevăr pentru bani; GA4 rămâne sursa pentru drumul până la ei.

Cât timp păstrează GA4 datele și ce se pierde după?

Pe o proprietate standard poți alege 2 sau 14 luni. Setarea nu afectează rapoartele standard agregate, ci explorările și rapoartele privind canalele — deci un raport lunar obișnuit rămâne disponibil, dar o analiză an la an pe explorări nu. Mărirea perioadei se aplică datelor deja colectate și neșterse, însă ce a fost șters nu se recuperează.

De ce apare trafic real în „Direct / none”?

Pentru că GA4 nu a primit informația despre sursă: parametri pierduți la redirecționare, aplicații care deschid linkuri fără referrer, sau context de sesiune care nu ajunge. Am tratat cauzele și procedura de diagnostic pe larg în articolul despre „Direct / not set”.

Măsurarea începe când datele trec testul

Modelul mental care ajută cel mai mult este acesta: GA4 nu e un instrument de raportare, e un lanț de custodie pentru o cifră. Cifra pleacă din browserul clientului, trece prin etichetă, prin evenimente, prin marcarea ca eveniment-cheie și prin setările proprietății, iar fiecare verigă o poate modifica sau pierde în tăcere. Un raport nu îți spune niciodată prin ce verigă a trecut și ce a pierdut pe drum — de asta testul de acceptanță se face înainte de primul raport, nu după prima decizie greșită.

A doua idee de reținut e că ordinea nu e negociabilă. Setările care nu se repară retroactiv se fac în prima zi, chiar dacă nu produc niciun efect vizibil atunci. Evenimentele se implementează după ce știi ce decizie susțin. Marcarea ca eveniment-cheie vine la final, pentru că ea determină ce cumpără algoritmii de licitare.

Dacă ai deja GA4 instalat și nu ești sigur pe cifre, rulează cele 14 verificări pe proprietatea ta înainte de următoarea decizie de buget. Dacă preferi să te uite altcineva peste ele, așa arată cum lucrăm pe măsurare, de la obiective la verificarea datelor — și poți începe cu un diagnostic al măsurării tale actuale.