Google Tag Manager: noul cod de instalare și ce ai de făcut

Săptămâna asta am creat un container nou de Google Tag Manager și, la pasul de instalare, am primit alt cod decât cel pe care îl știam pe de rost de ani de zile. Nu mai sunt două bucăți, una pentru head și una pentru body. E un singur fragment, care seamănă foarte mult cu vechiul gtag.js.

Prima reacție a fost că am nimerit într-un test de interfață. Nu e cazul. Google a schimbat oficial codul de instalare pentru containerele web, ca parte din unificarea dintre Google tag și Google Tag Manager.

Am adunat mai jos ce s-a schimbat concret, ce rămâne la fel și unde pot apărea probleme, cu trimiteri la documentația Google pentru fiecare afirmație.

Cum arată noul cod de instalare

La un container nou, în fereastra „Installation instructions”, tabul „Install manually” afișează acum acest fragment:

<!-- Google Tag Manager -->
<script async src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
</script>
<!-- End Google Tag Manager -->

Pentru comparație, varianta cu care am lucrat toți până acum avea două părți:

<!-- Google Tag Manager -->
<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-XXXXXXX');</script>
<!-- End Google Tag Manager -->

<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-XXXXXXX"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->

Diferențele care contează în practică:

• Un singur fragment. Se pune în <head>, cât mai sus. Pagina oficială de instalare nu mai afișează partea de <noscript> pentru versiunea curentă.
• Scriptul se încarcă direct. gtm.js este cerut printr-un tag <script async> obișnuit, nu mai este injectat de funcția aceea compactă.
• Apare funcția gtag(). Codul definește gtag() și apelează gtag('js', new Date()), dar fără nicio comandă gtag('config').
• dataLayer rămâne același. Obiectul window.dataLayer este inițializat la fel, deci un dataLayer.push() din site ajunge în container ca înainte.
• Două căi de instalare. Primul tab, „Install with a website builder or CMS”, te duce pe integrările pentru platforme precum WordPress, Shopify sau Wix. Al doilea este instalarea manuală, cu un câmp în care poți testa dacă site-ul are codul.

Ambele variante de cod sunt publicate de Google în pagina Install a web container.

De ce a făcut Google schimbarea

Până acum existau două produse care făceau lucruri apropiate. Google tag (gtag.js) era codul primit din GA4 sau din Google Ads. Google Tag Manager era containerul în care îți administrai toate tagurile, inclusiv pe cele de la Meta sau TikTok.

Google le unește. Anunțul oficial, Updates to Google tag and Google Tag Manager, spune câteva lucruri clare:

• Google tag-urile vor fi trecute la containere Google Tag Manager cu funcționalitate completă. Cine avea doar gtag.js primește interfața GTM, modul de depanare și istoricul de versiuni.
• Toate codurile noi de instalare vor fi identice și nu vor mai conține comanda gtag config.
• Pentru inițializare, Google recomandă triggerul de tip Initialization (gtm init).
• Comportamentul din pagină al Google tag-urilor existente nu se schimbă.

Mai e un detaliu care explică de ce codul arată la fel peste tot. De acum, ce are voie să ruleze un container depinde de prefixul ID-ului, nu de calea prin care este încărcat. Un ID care începe cu GTM- permite orice tip de tag, inclusiv scripturi terțe și Custom HTML. Un ID cu G- sau AW- este limitat la tagurile Google. Regula este descrisă în Manage tagging behavior using the container ID.

Ce faci cu site-urile care au deja GTM instalat

Nimic. Google scrie explicit, în aceeași pagină de instalare, că site-urile care folosesc varianta anterioară a codului nu trebuie retaguite și că acel container va funcționa în continuare așa cum este.

Regula pe care o aplic eu:

• Site existent, cu tracking care merge: nu ating codul de instalare doar pentru această schimbare. Google nu cere înlocuirea snippetului vechi, iar o modificare netestată poate afecta colectarea datelor.
• Site nou sau container nou: instalez varianta nouă, exact cum o dă interfața.
• Nu instalez ambele variante ale codului pentru același container pe aceeași pagină. Folosesc o singură variantă și verific să nu fie adăugată încă o dată de temă sau plugin.

Dacă site-ul este pe WordPress, Shopify sau altă platformă și GTM este pus printr-un plugin care cere doar ID-ul containerului, rămâi pe plugin. Nu contează dacă acesta inserează încă varianta clasică, pentru că ea rămâne valabilă.

Unde pot apărea probleme: gtag('config') lângă GTM

Partea aceasta afectează și site-urile vechi, nu doar containerele noi.

În notele de lansare Google Tag Manager, la data de 8 octombrie 2026, Google a anunțat standardizarea comportamentului comenzii gtag('config'). Pe scurt:

• Toate containerele încărcate prin gtm.js se inițializează la încărcare, indiferent dacă în pagină există sau nu comenzi gtag('config').
• Comenzile gtag('config') din pagină apar acum în dataLayer ca evenimente vizibile, cu numele gtag.config.
• Dacă vrei să folosești în continuare gtag('config') pentru configurare, paginile trebuie să folosească snippetul Google tag (gtag.js). Nu te baza doar pe snippetul GTM pentru acele comenzi.

Cine trebuie să verifice: site-urile care încarcă un container prin gtm.js și se bazează pe gtag('config') din pagină pentru configurare, precum și cele cu triggere Custom Event care pot reacționa la gtag.config. Comenzile pot veni dintr-o temă, un plugin sau o integrare nativă a platformei. Simpla prezență a GTM și gtag pe aceeași pagină nu dovedește dublarea.

Riscul concret este o declanșare suplimentară. Dacă în container ai un trigger Custom Event cu expresie regulată de tip .*, acesta poate declanșa taguri și pe gtag.config, dacă sunt îndeplinite și celelalte condiții ale triggerului. Dublarea unui pageview sau a unei conversii depinde de tagurile și condițiile configurate și trebuie verificată în Preview.

Ce e de făcut:

• Caută în sursa paginii gtag('config' și verifică ce destinații și setări depind de aceste comenzi. Dacă le muți în GTM, configurează-le și testează-le înainte să elimini codul redundant. Dacă păstrezi configurarea prin gtag, folosește snippetul gtag.js.
• Deschide triggerele de tip Custom Event și verifică-le pe cele cu regex larg. Exclude gtag.config sau înlocuiește expresia cu numele exacte ale evenimentelor.
• Nu încărca un ID G- sau AW- prin gtm.js. Combinația este tratată de Google ca instalare nesusținută.

Sintaxa oficială a comenzii este în documentația pentru dezvoltatori. Google marchează gtag('config') drept deprecated și recomandă gestionarea destinațiilor și setărilor în interfața GTM, dar precizează că instalările existente cu gtag.js și config continuă să funcționeze fără retaguire.

Bannerul „Optimize your Tag Manager container”

A doua parte a schimbării se vede în containerele existente: un banner pe pagina Overview care te invită să optimizezi containerul. Este opțional și nimic nu se aplică automat.

Ce face optimizarea, conform paginii Optimize your Google Tag Manager container:

• Containerul trimite datele direct către destinațiile Google, fără să mai încarce separat gtag.js. De aici vine câștigul de viteză.
• Setările Google tag-urilor se mută într-o secțiune nouă, Settings, unde vezi și lista destinațiilor Google.
• Tagurile de evenimente și triggerele existente se păstrează.
• Containerul este legat de conturile de destinație, iar la optimizare alegi ce nivel de acces primește fiecare. Permisiunile nu sunt versionate și se pot modifica din Admin, secțiunea External Account Links.

Pașii sunt simpli când toate Google tag-urile au aceleași setări: Review details, Preview changes, Add to workspace, test în Preview, apoi Submit. Dacă tagurile au setări diferite, butonul este Get started și trebuie să alegi ce setări se consolidează.

Aici recomand răbdare. Pe un container cu un singur Google tag sau cu setări identice, procesul este mai simplu, dar tot verific schimbările în Preview înainte de publicare. Pe unul cu mai multe conturi Google Ads, setări diferite de la un tag la altul și mai mulți oameni cu acces, o tratez ca pe o migrare: o fac într-un workspace separat, testez fiecare conversie în Preview și abia apoi public. Dacă ceva nu iese, poți reveni la versiunea anterioară a containerului. Permisiunile nu sunt versionate și trebuie verificate separat în External Account Links.

Optimizarea de mai sus vizează setările și destinațiile Google, nu o rescriere a tagurilor Meta, TikTok, LinkedIn sau a altor taguri terțe. Verific totuși și tagurile terțe dacă folosesc triggere Custom Event cu regex larg, pentru că pot reacționa la gtag.config.

Ce verific la orice instalare, veche sau nouă

Lista mea scurtă, în ordinea în care o parcurg:

• Același container nu este instalat de două ori. Snippetul nou se pune în <head>, cât mai sus; instalarea clasică validă poate rămâne cu cele două fragmente.
• ID-ul începe cu GTM-. Altfel tagurile terțe și Custom HTML nu vor rula.
• Comenzile gtag('config') din temă, plugin sau integrarea platformei sunt verificate: nu mă bazez doar pe snippetul GTM pentru configurarea lor și nu elimin setări necesare fără migrare și testare.
• Triggerele Custom Event cu regex larg sunt verificate pentru declanșări nedorite pe gtag.config; exclud evenimentul sau folosesc nume exacte acolo unde este necesar.
• GA4 și Google Ads sunt configurate în container, iar fiecare conversie este testată în Preview, cu Tag Assistant.
• Tabul Network din DevTools arată cereri către googletagmanager.com/gtm.js. Dacă apar și cereri către /gtag/js, verific de unde sunt inițiate: un container GTM neoptimizat poate încărca el însuși gtag.js pentru destinațiile Google. Prezența ambelor cereri nu dovedește singură un al doilea snippet sau dublarea datelor.

Pe scurt: codul nou este o altă formă de a încărca același container. Problemele pot apărea când pagina se bazează pe gtag('config') împreună cu snippetul GTM sau când triggerele cu regex larg reacționează la gtag.config. Verific implementarea și declanșările, nu presupun o problemă doar pentru că apar atât GTM, cât și gtag.

Dacă nu ești sigur ce rulează pe site-ul tău, scrie-mi și mă uit pe instalare.

Surse oficiale

• Install a web container - codul nou și cel anterior, mențiunea că site-urile existente nu trebuie retaguite
• Updates to Google tag and Google Tag Manager - anunțul unificării, coduri de instalare identice, fără gtag config
• Release notes for Google Tag Manager - nota din 8 octombrie 2026 despre gtag('config') și evenimentul gtag.config
• Manage tagging behavior using the container ID - ce poate rula un container în funcție de prefixul ID-ului
• Optimize your Google Tag Manager container - pașii de optimizare, secțiunea Settings, permisiuni
• Configure Google products and send event data - sintaxa comenzii config în gtag.js

• Set up your Google tag installation correctly for gtag.js - implementări nesusținute și păstrarea configurațiilor existente