# Google Analytics 4: ghid de configurare, evenimente și conversii

> Configurează Google Analytics 4, măsoară formularele și comenzile, marchează evenimentele importante și verifică dacă datele sunt corecte înainte să iei decizii.

- **Autor:** Iuliana Alexandra
- **Publicat:** 2026-10-28
- **Actualizat:** 2026-10-28
- **Categorie:** Marketing
- **URL:** https://inonline.ro/marketing/google-analytics-4-ghid-configurare-evenimente-conversii

---

Google Analytics 4 (GA4) înregistrează interacțiuni de pe site sau aplicație ca evenimente și le organizează în rapoarte. Poate arăta cum ajung utilizatorii, ce pagini văd și ce acțiuni fac, dacă implementarea este corectă. Un tag instalat nu înseamnă automat că fiecare comandă este măsurată sau atribuită perfect unui canal.

Ghidul te duce de la proprietate la tag, evenimente pentru formulare și magazine, verificare în timp real și calitatea datelor. Configurarea consimțământului depinde de site și obligațiile aplicabile. Consultă documentația oficială la 28 octombrie 2026 și validează setările contului tău.

## Pe scurt
- Planifică ce acțiuni trebuie măsurate înainte de instalarea tagurilor.
- Instalează GA4 printr-un singur punct de configurare.
- Trimite evenimente după confirmarea reală a acțiunii.
- Marchează drept key events doar obiectivele importante.
- Testează DebugView, Realtime, scenarii negative și consimțământul.

## Ce măsoară GA4 și ce nu

GA4 colectează evenimente despre interacțiuni, în funcție de instalare, setări și consimțământ: vizualizări, clicuri, căutări, formulare, coșuri și cumpărări. Proprietarul decide ce acțiuni sunt importante și cum sunt trimise. Instrumentul nu observă automat orice comportament și nu oferă o imagine perfectă a fiecărui utilizator.

Search Console raportează performanța în rezultatele Google; Analytics urmărește activitatea măsurată după vizita pe site. Totalurile diferă din cauza definițiilor, fusului orar, consimțământului și atribuirii. Compară datele pentru aceeași întrebare, nu doar două numere cu denumiri asemănătoare.

## Planifică evenimentele înainte de instalare

Începe de la deciziile de business. Un site de servicii poate urmări trimiterea unui formular valid sau programarea. Un magazin poate măsura vizualizarea produsului, coșul, checkout-ul și achiziția. Nu măsura fiecare hover doar pentru că tehnic se poate; evenimentele fără scop aglomerează rapoartele.

Scrie pentru fiecare eveniment numele, acțiunea care îl declanșează, parametrii, paginile și persoana responsabilă de verificare. generate_lead trebuie trimis după confirmarea reală a formularului, nu doar la clic pe buton. Dacă cererea e invalidă sau serverul o respinge, nu raporta lead finalizat.

Păstrează convenții consistente pentru nume și parametri și nu trimite date personale. Separă testele de producție. Dacă angajații generează trafic intern, decide cum îl identifici și testează filtrele înainte de a exclude date.

## Creează proprietatea și fluxul web

Creează proprietatea pentru organizație și un flux web pentru domeniul care colectează date. Verifică fusul orar și moneda înainte de prima colectare; schimbările ulterioare nu rescriu toate rapoartele istorice. Notează Measurement ID-ul și separă staging-ul de producție dacă testezi schimbări.

Dacă ai mai multe domenii sau aplicații, decide dacă aparțin aceleiași proprietăți și cum vei citi parcursurile. Păstrează accesul individual și revizuiește-l când se schimbă echipa. Proprietatea poate conține date comerciale despre trafic și venituri.

## Instalează tagul o singură dată

Poți instala Google tag direct cu gtag.js sau prin Google Tag Manager. Alege un singur punct de configurare principal. Dacă tagul este injectat și de codul site-ului, și de GTM, page_view ori evenimentele pot apărea dublat.

În GTM configurează tagul Google cu Measurement ID și triggerul potrivit, apoi folosește Preview pentru a verifica paginile și ordinea declanșării. Publică după test și notează schimbarea. Cu gtag.js urmează snippetul documentat și asigură-te că evenimentele rulează după tagul Google.

Testează mobilul, pagina de confirmare, subdomeniile și redirecturile către procesatorul de plăți. Un script poate exista în pagină, dar o eroare JavaScript, blocator sau setare de consimțământ poate opri trimiterea. Documentația Google descrie configurarea pentru site-uri și aplicații.

## Enhanced measurement și evenimente recomandate

Enhanced measurement poate colecta automat anumite interacțiuni, în funcție de setări, precum scroll, clicuri externe sau descărcări. Verifică ce este activ și dacă evenimentul răspunde unei întrebări reale. Automat nu înseamnă automat util.

Pentru ecommerce, evenimente precum view_item, add_to_cart, begin_checkout și purchase au parametri așteptați. Un nume de eveniment fără valoare, monedă și items poate produce date incomplete. Pentru formulare, folosește un eveniment care reflectă trimiterea validă, nu doar o apăsare.

Nu trimite nume, e-mail, telefon, adresă sau conținut de formular în parametri Analytics. Folosește identificatori tehnici care nu identifică persoane și verifică URL-urile și titlurile pentru date introduse accidental.

## Formulare și lead-uri

Un clic pe Trimite nu este același lucru cu o solicitare înregistrată. Formularul poate eșua la validare sau din cauza rețelei. Trimite evenimentul după răspunsul de succes al aplicației sau pe o pagină de confirmare controlată și previne duplicarea la refresh.

Dacă trimiterea se face prin AJAX, folosește un callback de succes sau un eveniment dataLayer. Verifică formularul pe paginile unde apare; o programare și o cerere generică pot avea valoare diferită. Parametrii pot descrie tipul formularului, dacă nu identifică o persoană.

Dacă ai un CRM, compară solicitările cu lead-urile calificate fără să transformi Analytics într-un depozit de informații personale. Definește termenii în echipă: submit, lead calificat și client nu sunt aceeași etapă.

## Comenzi și ecommerce

Planifică traseul magazinului: listă, produs, coș, checkout și purchase. Începe cu evenimentele pe care le poți măsura fiabil și care susțin decizii. Purchase trebuie să reflecte comanda finalizată, nu simpla vizitare a paginii de mulțumire.

Folosește un transaction_id stabil, valoare, monedă și lista articolelor în forma documentată. Testează retrimiterile paginii și situațiile în care utilizatorul revine la confirmare, pentru a nu dubla tranzacțiile. Compară rapoartele cu sistemul de comenzi și explică anulări, retururi, taxe și diferențe de fus orar.

Testează cupoane, transport, monede și variante de produs. Nu schimba convenția la mijlocul perioadei fără să documentezi ruptura. Google publică un ghid pentru [evenimente ecommerce GA4](https://support.google.com/analytics/answer/12200568?hl=en) cu parametrii aferenți.

## Marchează acțiunile importante ca key events

În interfața actuală, acțiunile importante sunt numite key events. Mai întâi configurează și verifică evenimentul; apoi marchează-l. Schimbarea se aplică datelor viitoare și nu transformă retroactiv evenimentele anterioare.

Un business poate marca o cerere validă sau o programare; un magazin poate urmări purchase. Nu marca fiecare page_view, scroll sau click drept important, fiindcă rapoartele nu vor mai diferenția obiectivele.

Dacă folosești evenimentul în Google Ads, verifică legarea conturilor, permisiunile și importul. Evenimentul Analytics și conversia folosită pentru licitare au roluri conexe, dar nu sunt același lucru. Unele funcții depind de cont. Vezi [documentația key events](https://support.google.com/analytics/answer/13128484?hl=en).

## Verifică DebugView și Realtime

Folosește GTM Preview sau DebugView pentru sesiuni de test și verifică numele, parametrii și declanșarea fiecărui eveniment. Confirmă că page_view nu se trimite de două ori și că formularul sau comanda apare o singură dată.

Realtime poate confirma date recente. Dacă nu vezi evenimentul, verifică Measurement ID, triggerul, blocatoarele, consimțământul și erorile de JavaScript. Unele rapoarte standard apar după procesare, deci lipsa imediată nu înseamnă neapărat că nu s-a colectat nimic.

Testează și scenarii negative: formular invalid, click repetat, comandă anulată și refuzul măsurării opționale. Dacă evenimentul se trimite în toate cazurile, corectează condiția înainte de a-l marca drept important. Repetă testul după schimbări de frontend sau procesator.

## Rapoarte utile pentru echipe mici

Rapoartele de achiziție arată canalele în limitele atribuirii. Paginile de destinație indică locul de început al sesiunii, iar Events arată ce acțiuni au sosit. Compară perioade relevante și segmentează dispozitivul numai dacă ai o ipoteză.

Un funnel poate indica unde scad sesiunile măsurate între produs, coș și checkout, dar nu explică singur cauza. Verifică funcționalitatea, stocul, costul de livrare și implementarea. Pentru servicii, separă vizitele de solicitările confirmate și lead-urile calificate.

Leagă Analytics de întrebări simple: ce pagină atrage trafic relevant, ce acțiune se finalizează și ce pas pierde utilizatori. Pentru pagina de produs, continuă cu [lista de verificare a conversiei](/ecommerce/optimizarea-conversiei-12-lucruri-de-verificat-pe-pagina-de-produs).

## UTM-uri, mai multe domenii și referral

UTM-urile identifică sursa, mediul și campania. Folosește litere mici și reguli identice; variante precum Facebook și facebook pot fragmenta raportarea. Nu adăuga UTM-uri la linkurile interne, fiindcă poți afecta atribuirea.

Dacă vizitatorul trece între domenii proprii, configurează cross-domain și testează URL-ul. Un procesator extern poate apărea ca referral; investighează traseul înainte de a exclude sursa. O excludere configurată greșit poate ascunde probleme reale.

Nu pune date personale în URL-uri. Acestea pot apărea în loguri, istoricul browserului și rapoarte. Folosește numai valori de campanie și pagină care nu identifică utilizatorul.

## Confidențialitate și filtre

Configurarea trebuie să respecte politicile serviciului și obligațiile de confidențialitate aplicabile site-ului. Cerințele depind de scopuri, regiune și tehnologii; un banner de cookies nu rezolvă automat fiecare obligație. Nu configura Analytics ca să eviți o analiză juridică.

Verifică ce taguri rulează înainte și după alegerea utilizatorului și testează acceptarea, refuzul și retragerea. Nu trimite date personale în evenimente, URL-uri sau parametri. Revizuiește cine are acces la proprietate și ce integrări pot exporta date.

Filtrele de date pot exclude definitiv traficul identificat drept intern sau developer. Testează definiția și modul de verificare înainte de activare, documentează aprobarea și înțelege că datele excluse nu pot fi recuperate în rapoarte.

## Greșeli frecvente și plan în șapte pași

Greșelile comune sunt dublarea tagului, măsurarea clickului în loc de succes, nume UTM inconsistente, lipsa ID-ului de tranzacție și activarea pripită a filtrelor. Revizuiește schimbările din site și sezonalitatea înainte să atribui orice variație unei campanii.

Plan practic: definește obiectivele; inventariază evenimentele; creează proprietatea și fluxul; instalează o singură dată; configurează taguri; testează cazuri pozitive și negative; publică și documentează versiunea. Pentru magazine, testează tranzacții reale de probă și compară cu platforma de comenzi.

În primele zile verifică dacă datele sosesc și nu se dublează, apoi revizuiește lunar. Repetă validarea după redesign, schimbări în GTM, mutarea domeniului sau schimbarea procesatorului. Pentru email marketing, vezi și [ghidul de email pentru afaceri mici](/marketing/email-marketing-pentru-afaceri-mici-ghid-practic).

## O schemă de măsurare pentru un site de servicii

Pentru o firmă locală, definește traseul pe care vrei să îl înțelegi: pagină de serviciu, clic pe telefon, formular, confirmare și eventual programare. Decide dacă apelul este măsurat printr-o funcție disponibilă ori doar prin clic. Notează diferența: clicul nu confirmă convorbirea, iar un formular trimis nu garantează că solicitarea este calificată.

Stabilește numele evenimentelor, condițiile de declanșare și ce echipă folosește raportul. O acțiune importantă poate deveni key event, dar nu marca fiecare interacțiune. Dacă CRM-ul înregistrează etapa ulterioară, compară volumul cu Analytics într-o manieră care nu trimite date identificabile către parametrii GA4.

## Data layer și Google Tag Manager

Data layer este o structură de date prin care site-ul poate transmite informații către Google Tag Manager. Pentru un formular, aplicația poate emite un eveniment după ce serverul confirmă salvarea; pentru o comandă, poate transmite ID-ul tranzacției și valoarea. Această abordare este mai robustă decât declanșarea pe textul unui buton, care se poate schimba la redesign.

În Preview verifică ordinea evenimentelor, variabilele și condițiile. Testează formular valid, formular invalid, eroare de server și reîncărcarea paginii de confirmare. Dacă folosesc mai multe echipe același container, notează convențiile de nume și aprobarea pentru publicare. O regulă care pare corectă pe homepage poate declanșa accidental pe toate butoanele site-ului.

## Ecommerce: validează traseul și tranzacția

Verifică dacă evenimentele de produs și checkout descriu aceleași produse care apar în magazin. Parametrii items trebuie să conțină identificatori consecvenți cu catalogul, iar moneda și valoarea să urmeze o definiție stabilită. Dacă datele de produs sunt inconsistente, comparația dintre listă, produs și comandă devine înșelătoare.

Testează plata reușită, plata refuzată, anularea, rambursarea și revenirea pe pagina de confirmare. O tranzacție nu trebuie trimisă ca purchase când checkout-ul a eșuat. Folosește un identificator stabil și verifică dacă retrimiterea paginii nu dublează achiziția. Păstrează un mediu de test separat de datele de producție.

## Cross-domain și procesatori de plăți

Dacă utilizatorul trece între domenii controlate de aceeași afacere, configurează cross-domain pentru ca sesiunea să nu se rupă inutil. Testează URL-urile și parametrii pe toate etapele; nu presupune că setarea este funcțională doar pentru că ai adăugat domeniile în interfață.

Dacă checkout-ul folosește un procesator extern, verifică dacă acesta apare ca sursă referral și dacă revenirea în magazin păstrează corect sesiunea. Nu adăuga domenii la excluderi fără să înțelegi consecințele. O excludere prea largă poate ascunde referral-uri legitime sau poate crea atribuiri neașteptate.

## UTM-uri coerente pentru campanii

Scrie o convenție înainte de a crea linkuri. De exemplu, toate sursele se scriu cu litere mici, medium are un set redus de valori, iar campaign descrie promoția. Dacă fiecare coleg inventează ortografii, rapoartele se fragmentează. Păstrează un tabel cu valorile permise și persoana care îl întreține.

Nu folosi UTM-uri pe linkurile interne de navigare și nu include date personale în parametri. Testează redirecturile și URL-ul final. Pentru Ads, verifică auto-tagging și conexiunea conturilor înainte să amesteci UTM-uri personalizate cu setările platformei.

## Trafic intern și filtre: testează înainte

Pentru a separa testele echipei, stabilește o metodă de identificare a traficului intern și valideaz-o în modul de test disponibil. Dacă angajații lucrează de acasă sau folosesc rețele diferite, regula trebuie să reflecte situația reală. Altfel, poți elimina vizite legitime sau poți păstra trafic intern fără să-ți dai seama.

Filtrele de date pot avea efect permanent pentru datele excluse. Înainte de activare, verifică condiția, explică impactul, păstrează o perioadă de test și documentează decizia. Nu porni un filtru în mijlocul unei analize fără să marchezi ruptura, fiindcă comparațiile cu perioadele vechi nu mai sunt echivalente.

## Cum interpretezi atribuirea și conversiile

Atribuirea distribuie creditul între punctele de contact potrivit modelului și datelor disponibile. Nu este o observație perfectă a motivului pentru care un client a cumpărat. Un utilizator poate vedea un anunț, reveni direct și finaliza comanda; rapoartele pot credita interacțiuni diferite în funcție de setări.

Compară rapoartele de canal cu datele din platforma de comenzi, CRM și campanii, dar nu aduna totaluri care numără aceeași conversie în sisteme diferite. Definește ce înseamnă client, lead și comandă finalizată. Pentru Google Ads, verifică acțiunile importate și dacă sunt primare sau secundare înainte de a le folosi la licitare.

## Acces, medii și jurnalul schimbărilor

Păstrează proprietatea Analytics și containerul GTM în contul afacerii, cu cel puțin doi administratori responsabili și permisiuni minime pentru colaboratori. Nu partaja un singur login. Revizuiește rolurile când încetează colaborarea și păstrează codurile Measurement ID într-un inventar accesibil echipei tehnice.

Notează fiecare publicare: ce tag s-a modificat, de ce, cine a testat și ce rezultat trebuie observat. Dacă numerele se schimbă după un deploy, poți compara jurnalul cu data problemei. Păstrează un mediu de staging și evită să trimiți comenzi de probă în rapoartele de producție.

## Checklist de QA înainte de lansare

Testează o pagină simplă, un formular, o navigare internă, pagina de confirmare și versiunea mobilă. Confirmă că tagul se încarcă o dată, că page_view nu se dublează și că evenimentul important are numele și parametrii corecți. Verifică scenariul în care utilizatorul refuză cookies opționale.

Pentru magazin, fă o comandă de test dacă mediul permite și confirmă valoarea, moneda, transaction_id și items. Verifică dacă evenimentele de test rămân în mediul potrivit. După publicare, urmărește Realtime și DebugView, apoi revino după ce rapoartele standard procesează datele.

## Diferența dintre debug și raportare de producție

DebugView este destinat verificării evenimentelor din sesiuni de depanare, iar Realtime oferă un rezumat al activității recente. Niciunul nu este o reconciliere contabilă. Pentru o comandă concretă, verifică și platforma de vânzare; pentru numărul de sesiuni, lasă timp rapoartelor să proceseze datele și păstrează același interval de comparație.

În testare, folosește valori marcate clar și un mediu separat dacă platforma permite. După depanare, confirmă că tagurile de test nu mai trimit evenimente în proprietatea de producție. Altfel, comenzile interne și formularele echipei pot contamina rezultatele reale.

## Consent mode și verificarea opțiunilor de consimțământ

Dacă implementezi Google Consent Mode sau o platformă de gestionare a consimțământului, verifică starea transmisă înainte și după alegerea utilizatorului. Testează atât acceptarea, cât și refuzul și retragerea. Modul tehnic de integrare trebuie să reflecte politica site-ului și cerințele aplicabile; nu presupune că o setare implicită este potrivită pentru toate piețele.

Folosește Tag Assistant și instrumentele browserului pentru a vedea ce taguri se declanșează și ce semnale sunt trimise. Compară comportamentul în sesiune curată, fără extensii care pot altera testul. Pentru concluzii legale despre cookie-uri și date personale, consultă responsabilul de confidențialitate; documentația tehnică Google nu înlocuiește acea analiză.

## Parametri, dimensiuni personalizate și limite

Trimite parametri doar când îi vei folosi într-o întrebare sau raport. Un eveniment cu zeci de câmpuri greu de interpretat complică QA și guvernanța. Folosește valori controlate, nu text liber de la client. Înainte de a înregistra o dimensiune personalizată, verifică dacă parametrul există, este consecvent și are nevoie să fie raportat.

Numele evenimentelor și parametrii sunt parte dintr-un contract între site, container și rapoarte. Dacă schimbi numele, notează data și actualizează trigger-ele și documentația. Evită să creezi variante aproape identice precum form_submit, form-submit și submit_form pentru aceeași acțiune.

## Revizuire lunară a măsurării

O dată pe lună compară evenimentele importante cu sursele operaționale: formularul cu CRM-ul, purchase cu comenzile și apelurile cu logurile de call tracking, dacă există. Explică diferențele cunoscute, precum anulările, refuzul consimțământului și duplicările. Caută schimbări bruște care coincid cu lansări.

Înregistrează ce ai verificat și cine răspunde de fiecare eveniment. Elimină tagurile vechi numai după ce confirmi că nu sunt folosite de rapoarte sau platforme conectate. Un audit scurt și regulat reduce șansele ca un container moștenit să măsoare acțiuni inexistente ori să trimită date în proprietatea greșită.

## Stabilește un dicționar de evenimente

Păstrează o foaie cu numele evenimentului, descrierea, momentul declanșării, parametrii acceptați și rapoartele care îl folosesc. Notează dacă este eveniment recomandat sau personalizat și cine aprobă modificarea. Dicționarul previne situația în care o echipă numește aceeași acțiune diferit pe site, în GTM și în CRM.

Pentru fiecare eveniment, scrie cel puțin un caz pozitiv și unul negativ. De exemplu, un formular valid trebuie să genereze confirmarea, iar unul invalid nu. Când implementezi un nou flux, verifică dacă există deja un eveniment echivalent înainte să creezi altul. Documentația scurtă păstrează măsurarea inteligibilă după schimbarea agenției ori a developerului.

## Continuă cu ghidurile conexe
- [Google Search Console: indexare și trafic organic](/marketing/google-search-console-ghid-indexare-trafic-organic)
- [Google Business Profile: vizibilitate locală](/marketing/google-business-profile-ghid-afaceri-locale)

## Întrebări frecvente

### GA4 este gratuit?

Versiunea standard este disponibilă gratuit, cu limitele produsului. Analytics 360 este oferta plătită pentru organizații cu cerințe enterprise.

### Cum verific dacă GA4 funcționează?

Folosește Tag Assistant sau GTM Preview pentru implementare și DebugView ori Realtime pentru evenimente. Testează o acțiune și verifică să apară o singură dată, cu parametrii corecți.

### Ce este un key event?

Este un eveniment care măsoară o acțiune importantă pentru afacere. Configurează și verifică evenimentul înainte să îl marchezi; datele istorice nu se rescriu.

### De ce văd două page_view?

Probabil tagul este instalat în două locuri sau două configurări trimit aceeași vizualizare. Verifică sursa paginii, GTM și navigarea aplicației.

### Cum măsor formularul?

Trimite evenimentul după confirmarea reală a serverului sau pagina de succes, nu la simplul clic. Testează validarea, erorile și retrimiterile.

### Pot trimite e-mailul clientului ca parametru?

Nu trimite date personale în evenimente Analytics. Folosește parametri tehnici care nu identifică persoane și verifică setările de confidențialitate.

Documentația oficială a fost consultată la 28 octombrie 2026. Funcțiile și interfața pot varia în funcție de cont și de actualizările Google.