Schimbarea Google Tag Manager gtag config: ce verificați pe site

Dacă site-ul dumneavoastră folosește Google Tag Manager (în interfața în română, Manager de etichete), Google schimbă modul în care Tag Manager pornește pe pagini. Într-o notă de versiune din 8 octombrie 2026, Google spune că fiecare container Tag Manager (cutia din Tag Manager care conține etichetele site-ului) va porni imediat ce se încarcă, în loc să aștepte o comandă gtag('config') pe pagină. Această schimbare Google Tag Manager gtag config contează cel mai mult pentru site-urile care combină Tag Manager cu un cod separat al etichetei Google și pentru containerele cu reguli (declanșatoare) care rulează etichete la orice eveniment.

Google a trimis e-mailuri proprietarilor de containere pe care le consideră configurate greșit. Nu a publicat câte sunt, iar pagina sa de ajutor despre remediere spune încă că fragmentele vor fi actualizate “în curând”.

Ce s-a schimbat în Google Tag Manager pe 8 octombrie?

Google spune că containerele Tag Manager nu vor mai aștepta linia gtag('config'), comanda care îi spune unei etichete Google în ce cont să trimită datele și cu ce setări. Nota de versiune din 8 octombrie, disponibilă doar în engleză, spune, în traducerea noastră: “toate fragmentele de container Google Tag Manager (gtm.js) se vor inițializa la încărcarea containerului, indiferent de comenzile gtag(‘config’).”

Un fragment este cele câteva linii de cod lipite în fiecare pagină a site-ului. O etichetă este o mică bucată de cod care raportează ce se întâmplă pe site, de exemplu o vizualizare de pagină sau un formular trimis. Eticheta trimite aceste informații către un instrument precum Google Analytics sau Google Ads. Un site poate încărca etichetele Google cu unul dintre două fragmente:

Ambele fragmente scriu în dataLayer, o coadă de mesaje de pe pagină pe care o citește Tag Manager. Până acum, un container putea observa o linie gtag('config') în altă parte a paginii și o putea aștepta, iar unele site-uri se bazau pe asta. Nota de versiune schimbă și ce vede containerul: “comenzile config vor apărea acum în dataLayer ca evenimente gtag.config vizibile.”

Ce site-uri afectează schimbarea Google Tag Manager gtag config?

Sunt afectate două grupuri de site-uri. E-mailurile Google au mers către primul grup, care folosește ceea ce Google numește o “implementare neacceptată”. Al doilea grup poate avea o configurare pe care Google o consideră corectă, dar are reguli (declanșatoare) care rulează etichete la orice eveniment.

Configurări mixte. Pagina de ajutor Google despre configurarea gtag.js descrie site-uri care încarcă un cod G-, AW- sau DC prin calea fragmentului Tag Manager. Exemplul său de configurare greșită este fragmentul GTM- standard urmat de o linie gtag('config') de sine stătătoare. Despre aceste site-uri, Google spune că “pot înregistra modificări neașteptate ale comportamentului etichetei”, iar utilizatorii acestor containere “au primit o notificare prin e-mail”.

Declanșatoare cu wildcard. Un declanșator este regula care îi spune unei etichete când să ruleze. Un declanșator personalizat de evenimente poate potrivi numele evenimentelor cu modelul .*, care se potrivește cu orice eveniment din dataLayer. Nota de versiune Google avertizează, în traducerea noastră: “Dacă containerele Google Tag Manager folosesc declanșatoare de evenimente personalizate cu wildcard, această schimbare poate face ca acele etichete să se declanșeze.”

Ajutorul Google despre evenimentele personalizate recomanda deja un model mai restrâns, pentru că .* se potrivește și cu evenimentele pe care Tag Manager și eticheta Google le trimit automat. PPC Land observă că riscul declanșatoarelor cu wildcard privește și site-urile a căror configurare Google o consideră corectă, pentru că fragmentul standard gtag.js conține el însuși un apel config.

Când a anunțat Google schimbarea gtag config?

Avertismentul a venit cu săptămâni înainte de nota de versiune. PPC News Feed a relatat despre notificarea de pe pagina de ajutor Google pe 27 august 2026. Pe 20 august, un utilizator al forumurilor de asistență WordPress.org a publicat e-mailul primit de un client de la Google. E-mailul spunea: “Începând cu 2 octombrie 2026, toate fragmentele gtm.js se vor inițializa la încărcarea containerului”.

Nota de versiune este datată 8 octombrie. Pagina de ajutor Google despre remediere spune încă că fragmentele Tag Manager “vor fi actualizate în curând”. Așa cum subliniază atât PPC Land, cât și Relevant Audience, Google nu a spus dacă schimbarea a ajuns la toate containerele într-o singură zi sau este introdusă treptat.

Ce nu a spus Google

Google nu a dat un termen final și nicio estimare a volumului de date pe care schimbarea l-ar putea perturba. Relevant Audience observă că nota de versiune “nu menționează nicio limită pe țări sau regiuni”, iar pagina de ajutor despre remediere nu numește nici ea vreuna.

Există și o problemă practică. E-mailul a mers la persoana trecută pe container. Relevant Audience arată că, dacă acea persoană este un fost angajat sau un dezvoltator web anterior, “avertismentul s-ar putea să nu fi ajuns niciodată la cel care administrează site-ul astăzi”.

Ce înseamnă pentru afacerea dumneavoastră

În opinia noastră, situația cere o verificare atentă a configurării de urmărire. Sarcina este să verificați ce încarcă paginile, să alegeți una dintre cele două remedieri Google dacă aveți o configurare mixtă și să testați că fiecare cerere este numărată o singură dată. Noi am face acești pași în această ordine, înainte de a schimba ceva în conturile de publicitate.

1. Aflați cine deține containerul. Aveți nevoie de acces la Tag Manager ca să verificați orice, iar containerul ar trebui să fie al companiei, cu agenția adăugată ca utilizator. Ghidul nostru despre evaluarea agenției de marketing explică de ce conturile ar trebui să fie la dumneavoastră.
2. Uitați-vă la fragmentul pe care îl încarcă paginile. Deschideți site-ul, afișați sursa paginii și căutați “googletagmanager.com”. Dacă URL-ul conține gtm.js cu un cod care începe cu GTM-, calea containerului este cea acceptată. Dacă gtm.js are un cod G-, AW- sau DC, ori lângă fragmentul Tag Manager se află o linie gtag('config') de sine stătătoare, aveți configurarea despre care a avertizat Google.
3. Alegeți una dintre cele două remedieri Google. Folosiți fragmentul etichetei Google (gtag.js) pe fiecare pagină și eliminați fragmentul gtm.js și orice linii config de sine stătătoare. Sau, dacă Tag Manager gestionează celelalte etichete, păstrați fragmentul cu codul GTM- și configurați eticheta Google în interiorul containerului. Preluați toate setările pe care le transmitea vechea linie config și lăsați neschimbată configurarea consimțământului pentru cookie-uri, astfel încât etichetele să urmeze în continuare alegerea vizitatorului din bannerul de cookie-uri.
4. Căutați declanșatoare .* în container. Deschideți lista de declanșatoare și căutați declanșatoarele de evenimente personalizate care se potrivesc cu toate evenimentele. Restrângeți fiecare la numele de evenimente de care are nevoie, pentru că o etichetă care rulează la gtag.config poate trimite din nou aceleași date, de exemplu numărând o cerere de două ori.
5. Testați cu Tag Assistant și cu o cerere reală. Tag Assistant este instrumentul Google de depanare pentru verificarea etichetelor de pe site, iar pagina de ajutor Google spune că acolo codul etichetei ar trebui să apară cu o pictogramă de stare verde sau albastră. Apoi trimiteți o cerere de test de pe telefon și verificați că este numărată o singură dată, așa cum descriem pentru Google Ads care aduce clicuri, dar nu și cereri. În administrarea campaniilor Google Ads, verificăm urmărirea înainte de orice modificare a licitărilor.
6. Comparați cifrele cu inboxul sau CRM-ul. Puneți cererile din inbox sau din CRM lângă conversiile raportate de Google pentru aceleași zile, înainte și după 8 octombrie. Folosim aceeași verificare în proiectele noastre de CRM și analiză, iar dacă cifrele nu mai corespund, etichetele sunt primul loc unde trebuie căutat.

← Toate articolele