Ce este Google Tag Manager și cum îl instalezi corect

Google Tag Manager este un sistem prin care instalezi și administrezi codurile de urmărire de pe site — Google Analytics, conversiile din Google Ads, pixelul Meta — dintr-o interfață web, fără să modifici codul site-ului de fiecare dată. Documentația oficială îl descrie drept „un sistem de management al tagurilor care îți permite să configurezi și să administrezi taguri pe site fără să schimbi codul site-ului”. Pui o singură dată două blocuri de cod pe site, apoi lucrezi din browser. Este gratuit.

Partea asta o găsești explicată în aproape orice articol românesc pe subiect. Ce nu găsești este restul: cum verifici că ai instalat corect, cum testezi înainte să publici, cine din firmă are voie să apese butonul, ce faci când publici ceva care strică măsurarea și de unde vin, de fapt, tagurile care se declanșează de două ori.

Acolo stă diferența dintre un container care funcționează și unul care raportează cifre în care nu te poți încrede.

Notă: articolul acoperă containerul web. Nu tratează server-side tagging, construcția avansată de dataLayer și containerele pentru aplicații mobile — sunt subiecte separate, cu alt nivel de dificultate și alt buget de implementare.

Ce rezolvă Google Tag Manager și când nu îți trebuie

Problema pe care o rezolvă este de proces, nu de tehnologie. Fiecare instrument de marketing îți cere să pui un cod pe site, iar fără un container, fiecare cod nou și fiecare modificare a unuia existent înseamnă o sarcină pentru cineva care are acces la temă — de obicei un dezvoltator, de obicei cu alte priorități.

Cu un container, dezvoltatorul face o singură intervenție. Restul se administrează din interfață, de către omul care are efectiv nevoie de date.

Notă: la scară globală, W3Techs măsura pe 26 iulie 2026 că Google Tag Manager este folosit de 45,8% dintre toate site-urile, ceea ce înseamnă o cotă de 99,7% între sistemele de management al tagurilor. Sunt cifre globale, nu românești — nu există date publice despre adopția în România.

Nu îți trebuie în trei situații concrete:

• Ai un singur instrument de măsurare și nu intenționezi să adaugi altul. Dacă folosești doar GA4, instalat prin integrarea nativă a platformei, containerul adaugă un strat pe care nu îl folosești.
• Platforma îți pune deja tagurile și nu ai nevoie de evenimente proprii. Magazinele care se mulțumesc cu evenimentele standard de ecommerce nu câștigă nimic din a le reconstrui manual.
• Nu ai pe nimeni care să întrețină containerul. Un container abandonat, cu taguri rămase de la agenții anterioare și declanșatoare pe care nu le mai înțelege nimeni, este mai rău decât lipsa lui: strică datele în tăcere.

Regula practică: containerul merită din momentul în care ai al doilea instrument de măsurat sau prima cerință de urmărire care nu vine gata făcută din platformă.

GTM, eticheta Google și GA4: cine ce face

Confuzia dintre aceste trei lucruri este cauza cea mai frecventă de instalare dublă. Toate trei se numesc, colocvial, „codul de la Google”, deși fac lucruri complet diferite.

Citit de sus în jos, tabelul spune un singur lucru: containerul este un transportator, eticheta Google este un pasager, iar GA4 este destinația. Dacă pui același pasager de două ori, în două transporturi diferite, ajunge de două ori la destinație — și exact așa apar dublurile.

Documentația pentru dezvoltatori descrie eticheta Google ca „un singur tag pe care îl poți adăuga pe site ca să folosești produsele Google de măsurare și publicitate”. Recomandarea din aceeași pagină este explicită: „dacă nu ești familiarizat cu JavaScript, îți recomandăm să folosești Google Tag Manager în locul lui gtag.js”.

Notă: documentația le prezintă ca alternative, nu ca instrumente complementare, și nu tratează explicit situația în care le ai instalate pe amândouă. În practică, este exact situația în care ajung multe site-uri — iar consecința ei este în secțiunea despre taguri duplicate.

Dacă vrei mecanica din partea cealaltă, a produsului care primește datele, am detaliat-o separat în diferența dintre GTM și GA4.

Procedura completă, în 8 pași

Ce urmează este harta. Fiecare pas are dedesubt, în secțiunile următoare, terenul lui detaliat.

Dacă vrei o singură listă pe care să o urmezi și să o bifezi, este aceasta.

1. Creezi contul și containerul de tip Web. Verifici: numele containerului este adresa de bază a site-ului, așa cum cere documentația, și ai la îndemână identificatorul de forma GTM-XXXXXXX.
2. Pui cele două blocuri de cod pe fiecare pagină. Verifici: primul este cât mai sus în <head>, al doilea imediat după <body>, pe toate paginile, inclusiv pe cele de mulțumire și de finalizare a comenzii.
3. Scoți din site tagurile pe care le muți în container. Verifici: pentru fiecare instrument măsurat există un singur loc de unde pleacă. Acesta este pasul pe care îl sare toată lumea.
4. Configurezi consimțământul înainte de a construi primul tag. Verifici: în ecranul de prezentare a consimțământului nu rămâne niciun tag în grupul neconfigurat despre care să nu fi luat o decizie conștientă.
5. Construiești primul tag și declanșatorul lui. Verifici: declanșatorul descrie exact evenimentul pe care îl vrei, nu unul apropiat.
6. Testezi în modul de previzualizare. Verifici: apare starea „Connected”, iar tagul se declanșează exact o dată per interacțiune, nu de două ori și nu deloc.
7. Publici cu nume și descriere de versiune. Verifici: lista de modificări din spațiul de lucru conține doar ce ai făcut tu.
8. Confirmi pe site-ul live și ții pregătită revenirea. Verifici: știi la ce versiune revii și prin ce comandă, înainte să ai nevoie.

Pașii 3, 4 și 8 sunt cei pe care ghidurile obișnuite îi omit. Sunt și cei care fac diferența între o instalare care merge și una despre care afli peste trei luni că raporta dublu.

Unde se pune codul pe site

Documentația este neechivocă în privința plasării. Primul bloc: „copiază primul bloc de cod și lipește-l cât mai sus posibil în tagul <head>”. Al doilea: „copiază al doilea bloc de cod și lipește-l imediat după tagul <body> de deschidere”.

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-ABCDEFGH');</script>

<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-ABCDEFGH"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>

Două lucruri se citesc direct din codul de mai sus, fără să crezi pe cuvânt pe nimeni. Scriptul este marcat async, deci se încarcă fără să blocheze randarea paginii. Al doilea bloc este un <iframe> ascuns în <noscript>, adică rezerva pentru browserele fără JavaScript — nu un al doilea sistem de urmărire, cum apare uneori descris.

Notă: documentația precizează că „dacă site-ul tău este construit cu un constructor de site-uri sau un sistem de management al conținutului precum WordPress, Shopify sau Wix, poți configura eticheta Google printr-o integrare care nu îți cere să actualizezi codul pe fiecare pagină”. Ruta e comodă și este, în același timp, cea mai frecventă sursă de instalare dublă. Revin asupra ei mai jos.

Ai deci trei rute pentru a ajunge la codul paginii: editezi tema singur, folosești integrarea platformei sau ceri unui dezvoltator. Structura de deasupra codului rămâne aceeași indiferent de rută — un cont per organizație, un container pentru fiecare site sau aplicație, iar la creare alegi între cele cinci tipuri disponibile: Web, iOS, Android, AMP și Server. Indiferent pe care o alegi, după instalare verifici direct din interfață: introduci adresa site-ului și apeși butonul de testare.

Primul tag și primul declanșator, pas cu pas

Containerul este, în termenii documentației, „o colecție de taguri, declanșatoare, variabile și configurări asociate, instalată pe un site sau pe o aplicație”.

Cele trei componente au roluri stricte. Tagul este codul care se execută. Declanșatorul stabilește când se execută. Variabilele „simplifică și automatizează configurarea tagurilor”.

1. În spațiul de lucru, deschizi secțiunea de taguri și creezi unul nou.
2. Alegi tipul de tag din listă — pentru început, tagul Google care trimite date către proprietatea ta de analiză.
3. Adaugi identificatorul contului de destinație.
4. Atașezi declanșatorul. Pentru un tag de bază, declanșatorul este afișarea paginii, pe toate paginile.
5. Salvezi cu un nume care spune ce face tagul, nu ce tip are.

Convenția de denumire pare un detaliu cosmetic până în ziua în care cauți, într-un container cu patruzeci de taguri, de ce se numără de două ori o conversie. „GA4 — afișare pagină” se caută peste un an. „Tag 1” nu.

Modul Preview: la ce te uiți, în ce ordine

Aici se rupe traseul în majoritatea ghidurilor românești: se explică cum construiești tagul și se trece direct la publicare.

Modul de previzualizare conectează site-ul la Tag Assistant și îți arată, în cuvintele documentației, „ce taguri s-au declanșat și în ce ordine”. Se pornește din spațiul de lucru, introduci adresa și apeși conectarea.

Ordinea contează pentru că fiecare rând îl elimină pe următorul. Dacă starea de conectare lipsește, restul tabelului este irelevant. Dacă evenimentul nu apare în listă, nu ai o problemă de tag.

Rândul 4 este cel pentru care merită să deschizi previzualizarea chiar și când totul pare în regulă: un tag care se declanșează de două ori arată identic cu unul care se declanșează o dată, până când te uiți la numărător.

Previzualizarea nu schimbă nimic pentru vizitatorii site-ului live — afectează doar sesiunea de browser conectată la Tag Assistant. Poți da acces unui coleg printr-un link generat din interfață, care îi permite „să se conecteze la site în modul de previzualizare și să vadă interfața de depanare Tag Assistant” fără să aibă acces la container.

Notă: două limitări declarate oficial. Modul de previzualizare nu este disponibil pentru containerele de aplicații mobile și nici pentru cele AMP.

Testarea în previzualizare rezolvă ce se declanșează. Nu rezolvă ce se pierde pe drum după declanșare — atribuire ruptă, parametri căzuți la redirect, trafic care ajunge în categoria greșită. Am tratat separat ce se întâmplă când tagurile pierd datele pe drum.

De unde vin tagurile duplicate și cum le găsești

Documentația spune un lucru care explică jumătate din problemele de măsurare pe care le vedem: Tag Manager „va declanșa tagurile migrate alături de tagurile administrate în afara Tag Manager”.

Containerul nu știe și nu are cum să știe ce mai există pe site. Nu înlocuiește nimic — adaugă.

Tabelul se citește pe coloana a treia: fiecare dublură are o metodă de verificare care durează sub un minut și nu cere acces la cod. Dacă nu ai timp să le faci pe toate patru, fă-o pe a doua — este cea care produce cele mai multe cazuri și cea despre care nu te avertizează nimeni.

Pe WordPress, pluginul oficial Google detectează codul existent și îți lasă comutatorul de plasare. Documentația lui avertizează direct, pe exemplul AdSense: „a permite Site Kit să plaseze fragmentul de cod AdSense atunci când a detectat deja cod AdSense existent înseamnă că site-ul tău are fragmente de cod AdSense plasate de două ori. Acest lucru poate duce la dublarea datelor colectate.” Mecanismul — detectare plus comutator — este același pentru celelalte servicii conectate, iar comutatorul se oprește din setările pluginului.

Pe Shopify, conectarea la GA4 se face prin canalul de vânzări Google & YouTube. Documentația platformei nu conține un avertisment echivalent, ceea ce nu înseamnă că riscul nu există — înseamnă doar că nimeni nu îl scrie.

Notă: măsurarea îmbunătățită din GA4 este dublura pe care nu o caută nimeni, pentru că nu apare nicăieri în container. Se activează din proprietatea de analiză, nu din Tag Manager, și de aceea scapă tuturor auditurilor făcute doar pe container.

Măsurarea îmbunătățită colectează automat, fără nicio linie de cod, evenimente ca derularea paginii, clicurile către alte site-uri, descărcările de fișiere, căutările interne, interacțiunea cu materialele video și începerea sau trimiterea unui formular.

Dacă construiești în container un tag pentru o interacțiune pe care GA4 o colectează deja, aceeași interacțiune ajunge de două ori în raport. Documentația Google nu tratează explicit acest caz; concluzia vine din faptul că ambele mecanisme trimit același eveniment către aceeași proprietate.

Pentru achiziții există o plasă de siguranță pe care merită să o cunoști. Documentația Google Ads precizează că identificatorul de tranzacție „trebuie să fie unic pentru fiecare tranzacție în parte și trebuie generat dinamic de backendul site-ului sau de platforma de ecommerce, pentru fiecare achiziție”, iar mecanismul funcționează astfel: „dacă există 2 conversii pentru aceeași acțiune de conversie cu același identificator de tranzacție, Google Ads va ști că a doua conversie este un duplicat”.

Notă: avertismentul din aceeași sursă contează la fel de mult ca mecanismul. Un identificator fix, hardcodat, „va duce la subnumărarea semnificativă a conversiilor” — adică plasa de siguranță prost montată face mai mult rău decât lipsa ei.

În GA4, același parametru este obligatoriu pentru evenimentele de achiziție și de rambursare. Dacă vinzi online și conversiile din Google Ads măsurate fără dubluri contează pentru deciziile de buget, acesta este primul lucru de verificat.

Așa arată auditul pe care îl facem pe un container, în ordinea în care îl facem:

1. Inventariem ce trimite site-ul, din sursa paginii și din interfața de depanare — nu din documentația clientului, care descrie de obicei intenția, nu realitatea.
2. Comparăm inventarul cu lista de taguri din container. Orice se trimite și nu apare în container vine din altă parte și trebuie găsit.
3. Verificăm integrările native ale platformei și pluginurile care plasează cod, unul câte unul.
4. Comparăm evenimentele colectate automat de GA4 cu tagurile construite manual, pe fiecare tip de interacțiune.
5. Verificăm în modul de previzualizare de câte ori se declanșează fiecare tag pe o sesiune completă, inclusiv pe finalizarea comenzii.
6. Confirmăm că achizițiile trimit un identificator de tranzacție unic.
7. Documentăm ce scoatem, de unde, și la ce versiune de container se poate reveni.

Regula de migrare care lipsește din aproape toate sfaturile pe care le vei citi: muți tagurile unul câte unul, iar pentru un tag dat nu există fereastră de suprapunere.

Suprapunerea nu este o măsură de siguranță — este exact dublura. Ce îți trebuie în locul ei este posibilitatea de a reveni: versiunea anterioară a containerului rămâne publicabilă, iar fragmentul vechi de cod rămâne în istoricul de versiuni al site-ului, nu pe site. Sfatul „scoate tot trackingul vechi deodată”, pe care îl vei întâlni des, funcționează până în ziua în care ai scos și ceva ce nu era înlocuit. Aceeași disciplină se aplică și dincolo de Google: pixelul Meta instalat fără taguri duplicate cere aceeași verificare, cu miză mai mare, pentru că un pixel care raportează dublu optimizează campania către publicul greșit.

Consimțământ, drepturi de publicare și revenirea la o versiune anterioară

Ce oprește GTM până la consimțământ și ce nu

Containerul lucrează cu patru tipuri de consimțământ:

• ad_storage — stocarea, inclusiv cookie-uri, legată de publicitate.
• analytics_storage — stocarea legată de analiză, de exemplu durata vizitei.
• ad_user_data — trimiterea către Google a datelor de utilizator legate de publicitate.
• ad_personalization — publicitatea personalizată.

Tagurile Google au verificări încorporate care „își modifică comportamentul în funcție de consimțământul acordat”. Pentru restul poți impune verificări suplimentare din setările avansate ale fiecărui tag.

Ecranul de prezentare a consimțământului îți dă „o vedere de ansamblu asupra tuturor setărilor de consimțământ din tagurile containerului”, împărțite în configurate și neconfigurate. Este ecranul pe care ar trebui să îl deschizi înainte de fiecare publicare, nu doar la prima configurare.

Delimitarea care se pierde cel mai des: containerul aplică alegerea vizitatorului, nu o colectează. Bannerul de consimțământ rămâne o componentă separată, iar ordinea în care se leagă cele două decide dacă tagurile pornesc înainte sau după alegere — am tratat pe larg ordinea în care pornesc tagurile față de consimțământ, inclusiv verificarea.

Cele cinci niveluri de acces, traduse în cine ce face

Nivelul implicit pentru un colaborator nou este Editare, nu Publicare. Modificările lui rămân în spațiul de lucru până când cineva cu drept de publicare le trece în revistă — este singura barieră reală între o greșeală de configurare și site-ul live.

Google recomandă explicit „să existe cel puțin două conturi active de administrator” și avertizează că „dacă în contul tău există un singur administrator, s-ar putea să pierzi accesul la taguri dacă acel utilizator devine indisponibil”. În practică, cazul se întâmplă cel mai des la schimbarea agenției sau la plecarea unui angajat.

Notă: fluxul formal de aprobare, în care ceri permisiunea de a publica și cineva aprobă sau îți trimite modificarea înapoi, este disponibil doar în Tag Manager 360. În versiunea gratuită, guvernanța se face exclusiv prin permisiuni. Nu căuta butonul — nu există.

Cum revii la versiunea anterioară

Fiecare publicare creează automat o versiune, descrisă oficial ca „o instantanee a configurației containerului la un moment dat”, iar platforma păstrează un istoric din care se vede când a fost activă fiecare versiune și cine a publicat-o.

1. Deschizi secțiunea de versiuni și identifici ultima versiune despre care știi că funcționa.
2. Din meniul de acțiuni de lângă ea, alegi comanda care o setează ca versiune curentă — operațiunea „înlocuiește versiunea curentă de lucru a containerului cu conținutul versiunii selectate”.
3. Publici versiunea respectivă.

Două lucruri fac diferența între o revenire de un minut și o seară pierdută. Primul: numele și descrierea versiunii, fără de care ai o listă de „Versiunea 1, 2, 3” în care nu găsești niciodată când s-a schimbat ceva.

Al doilea: înainte de a publica, citești lista de modificări din spațiul de lucru. Dacă mai multe persoane au drept de editare, acea listă poate conține și modificări care nu sunt ale tale, iar publicarea le trimite live împreună cu ale tale.

Dacă ajungi în punctul în care containerul e administrat de mai mulți oameni, cu proceduri scrise și responsabilități separate, discuția nu mai e despre un tutorial de instalare. Așa arată arhitectura de tracking administrată dintr-un singur container când e tratată ca infrastructură.

Întrebări frecvente

GTM încetinește site-ul?

Nu există un reper oficial publicat de Google pentru performanța fișierului containerului, deci orice procent pe care îl vei citi pe tema asta este o estimare, nu o măsurătoare.

Ce se poate afirma se citește direct din codul de instalare: scriptul este marcat async, deci nu blochează randarea paginii, iar al doilea bloc este un <iframe> ascuns, activ doar fără JavaScript. Greutatea reală vine din ce pui înăuntru — fiecare tag adăugat este o resursă în plus — și o controlezi prin numărul de taguri, prin declanșatoare care nu pornesc pe toate paginile și prin curățarea celor rămase nefolosite.

Pot instala Meta Pixel prin Google Tag Manager?

Da. Documentația Meta pentru dezvoltatori confirmă că pixelul „va funcționa în majoritatea soluțiilor de tag management și de containere de taguri”, iar în container se adaugă ca tag de tip HTML personalizat, cu propriul declanșator.

Singura precauție reală: dacă platforma ta are deja o integrare oficială cu Meta, alegi una dintre cele două rute, nu pe amândouă, altfel evenimentele se dublează.

Cine ar trebui să aibă drept de publicare în container?

Maximum două-trei persoane, dintre care cel puțin doi administratori activi — Google avertizează explicit că un singur administrator înseamnă riscul de a pierde accesul la taguri.

Toți ceilalți primesc Editare, ca modificările lor să treacă printr-o revizuire înainte să ajungă live. Clientul sau conducerea primesc Citire: văd tot, nu pot strica nimic.

Am nevoie de Google Tag Manager dacă folosesc deja eticheta Google?

Depinde de câte lucruri ai de măsurat. Eticheta Google acoperă produsele Google; containerul administrează orice tag, inclusiv eticheta Google. Dacă ai doar GA4 și nu adaugi altceva, eticheta singură e suficientă.

Dacă le păstrezi pe amândouă, asigură-te că nu trimit ambele către aceeași proprietate — este una dintre cele patru surse clasice de dublare.

Cum verific dacă un tag s-a declanșat de două ori?

Deschizi modul de previzualizare, parcurgi pe site interacțiunea care te interesează, apoi apeși pe titlul paginii în bara din stânga. Sumarul îți arată de câte ori s-a declanșat fiecare tag pe pagina respectivă.

Un tag care apare de două ori pe o singură interacțiune este o dublură confirmată, nu o bănuială.

Concluzie: containerul e infrastructură, nu un panou de butoane

Modelul mental care ține pe termen lung este acesta: un container Google Tag Manager se comportă ca infrastructura din spatele afacerii tale, nu ca o setare pe care o bifezi o dată. Are un moment de instalare, o procedură de testare înainte de fiecare schimbare, o listă de oameni cu drepturi diferite și o cale de întoarcere. Fiecare dintre cele patru se poate sări, și fiecare se răzbună diferit: instalarea greșită duce la date lipsă, lipsa testării la date duble, drepturile prea largi la modificări pe care nu le-a cerut nimeni, iar lipsa unui plan de revenire transformă o greșeală de zece minute într-o săptămână de măsurători pierdute.

Diferența practică dintre cineva care „are GTM instalat” și cineva care se poate baza pe cifrele lui este un singur obicei: nu publici nimic pe care nu l-ai văzut declanșându-se corect, exact o dată, în modul de previzualizare. Restul — structura contului, convenția de denumire, matricea de permisiuni — există ca să facă obiceiul ăsta ușor de respectat când containerul are patruzeci de taguri și trei oameni cu acces, nu trei taguri și un singur om.

Dacă ai deja un container și nu ești sigur ce trimite, ordinea de verificare este cea din auditul de mai sus: întâi ce pleacă efectiv de pe site, apoi ce zice containerul că pleacă, apoi diferența dintre ele. Dacă preferi să nu o faci singur, cere un diagnostic de măsurare și îți spunem ce găsim, cu dovezile pe ecran.