Identyfikator kontenera w GTM: to on decyduje, które tagi działają

Przejmujesz stronę klienta po poprzedniej agencji. GA4 zbiera dane, konwersje z Google Ads się zgadzają, przez pierwsze tygodnie nikt nie zagląda w kod. Dopiero gdy wdrażasz narzędzie dostawcy spoza listy Google, okazuje się, że tag nie odpala. Kontener jest, działa, ładuje się poprawnie, tylko w trybie ograniczonym.

9 lipca 2026 Google zmieniło regułę, która do tego prowadziła. Wcześniej kontenery ładowane z nietypowych ścieżek, takich jak /gtag/js albo /gtag/destination, przechodziły w stan ograniczony i przepuszczały wyłącznie tagi oraz zmienne dostarczone przez Google. Od tej wersji o zachowaniu decyduje identyfikator użyty do wczytania kontenera, niezależnie od ścieżki. Kontener z prefiksem GTM- nie jest ograniczany. Prefiksy produktowe, czyli G- i AW-, nadal pozwalają wyłącznie na tagi i zmienne od Google. Wdrożenia korzystające z oficjalnych snippetów Google ta zmiana nie dotyczy.

Skąd na stronie biorą się nietypowe ścieżki

Nikt nie wpisuje złej ścieżki celowo. W praktyce robi to plugin CMS, który wstrzykuje własny loader, moduł zgód wstawiający skrypt po akceptacji, narzędzie marketingowe zakładające konto analityczne i podrzucające swój fragment kodu, albo szablon strony z twardo wklejonym adresem skryptu. Osobny przypadek to migracja: ktoś podmienił identyfikator w istniejącym snipcie gtag i zostawił starą ścieżkę, bo strona nadal działała.

Problem z takim wdrożeniem polega na tym, że nie sygnalizuje się w żaden widoczny sposób. Nie ma błędu w konsoli, kontener się ładuje, dane płyną do Google. Ograniczenie widać dopiero wtedy, gdy próbujesz uruchomić coś, czego Google nie dostarcza. Dlatego kontener może pracować w okrojonym trybie miesiącami, a zespół dowiaduje się o tym przy okazji pierwszego tagu własnego.

Jak sprawdzić, czym naprawdę wczytuje się kontener

Podstawa to dwa żądania sieciowe. Oficjalny snippet GTM prosi o plik gtm.js?id=GTM-XXXXXXX. Zunifikowany tag Google i wdrożenia produktowe proszą o gtag/js?id=... lub o ścieżkę /gtag/destination. W narzędziach deweloperskich wystarczy filtr na ciąg gtag i gtm, żeby zobaczyć, który wariant jest na stronie, i w jakiej kolejności względem menedżera zgód.

Drugi krok to prefiks identyfikatora. Zobacz, co stoi przed myślnikiem w adresie żądania. GTM- oznacza kontener z pełnym zakresem tagów, w tym własny HTML i JavaScript oraz skrypty stron trzecich. G- i AW- oznaczają tagi produktowe ograniczone do wysyłki danych do usług Google. Dokumentacja Google opisuje to jako sposób na świadome wybieranie zakresu uprawnień przez sam identyfikator, którym posługuje się strona.

Zmiana działa w obie strony

To najważniejszy praktyczny skutek tej wersji i najczęściej pomijany. Jeżeli kontener z prefiksem GTM- był dotąd wczytywany z nietypowej ścieżki, do 9 lipca działał w trybie ograniczonym. Tagi HTML, skrypty zewnętrznych dostawców i szablony własne nie odpalały. Po zmianie ten sam kontener przestaje być ograniczany, bez jednej modyfikacji w panelu GTM.

Co to oznacza w praktyce: tag dodany dwa lata temu i zapomniany może zacząć działać przy pierwszym odsłonie strony. Dochodzą nowe żądania sieciowe i nowe mechanizmy zapisu w przeglądarce. Przy wdrożeniu z Consent Mode v2 trzeba sprawdzić, czy te tagi są zablokowane przy odmowie zgody, czy wysyłają dane od razu. Nie każdy tag z listy własnych czeka na sygnał zgody i nie każdy jest na to w ogóle przygotowany.

Dla części klientów zmienia się więc zakres danych, które opuszczają stronę. To dobra okazja, żeby zaktualizować rejestr narzędzi i politykę prywatności, bo przy kontroli UODO trzeba umieć wskazać, kto otrzymuje dane i na jakiej podstawie. Zmiana w pojedynczym pliku po stronie Google ma tutaj realne skutki dokumentacyjne.

Kiedy kontener ma prefiks G- lub AW-

Ten układ nie jest błędem. Tak wygląda strona wdrożona na samym tagu Google, bez Tag Managera. Jeżeli klient potrzebuje wyłącznie GA4 i konwersji Google Ads, ograniczony zakres jest zaletą: kontener fizycznie nie może uruchomić obcego kodu.

Kłopot pojawia się w momencie, gdy pojawia się potrzeba wyjścia poza Google: piksel dostawcy, narzędzie do nagrań sesji, chat, system rekomendacji. Z takim identyfikatorem tego nie uruchomisz i żadna sztuczka z podmianą znaków w adresie skryptu nie zmieni typu kontenera. Jedyne poprawne rozwiązanie to założenie kontenera GTM i wdrożenie oficjalnego snippetu z prefiksem GTM-. Dopiero wtedy zakres tagów obejmuje własny kod.

Jak wygląda poprawne wdrożenie po tej zmianie

Kontener z prefiksem GTM- ma być wczytywany tak, jak przewiduje dokumentacja: jednym oficjalnym snippetem, który prosi o gtm.js. Wewnątrz kontenera konfiguruje się tag Google dla GA4 i dla konwersji Google Ads, a tagi dostawców zostają osobno, z własnymi wyzwalaczami i własnymi warunkami zgody.

Stary snippet gtag z identyfikatorem G- w tym układzie staje się zbędny. Jeżeli zostanie na stronie razem z kontenerem, dochodzi drugie źródło danych o tym samym ruchu i drugie miejsce, w którym trzeba sprawdzać zgodę. Zdublowane wdrożenie myli też w okresie przejściowym, bo część tagów odpala się z kontenera, a część z osobnego skryptu, i nie widać tego w jednym miejscu.

Po poprawce kontrola sprowadza się do trzech rzeczy: żądanie gtm.js?id=GTM-... w narzędziach deweloperskich, kontener widoczny w Tag Assistant pod właściwym identyfikatorem, oraz obecność w podglądzie tych tagów, które wcześniej były blokowane. Wtedy można wrócić do sprawdzenia zgody, bo nowe żądania sieciowe trzeba ocenić w kontekście tego, co użytkownik zaakceptował.

Lista kontrolna dla wdrożeń klienta

1. Zbierz wszystkie ścieżki wdrożenia: w źródle strony albo w przechwyconych żądaniach zapisz, czy ładuje się gtm.js, czy gtag/js, i jaki identyfikator tam stoi.
2. Zapisz dla każdego wdrożenia parę: prefiks identyfikatora plus ścieżka. To jedyne dwa fakty, które decydują o zakresie tagów.
3. Sprawdź w Tag Assistant, jak identyfikator widzi Google. Rozbieżność między tym, co na stronie, a tym, co raportuje narzędzie, zwykle oznacza zdublowany loader albo stary, nieusunięty snippet.
4. Wejdź do każdego kontenera z prefiksem GTM- i przejrzyj tagi HTML, szablony własne oraz skrypty dostawców. Sprawdź datę dodania i to, czy tag nie zaczął nagle wysyłać danych po 9 lipca.
5. Zweryfikuj zachowanie tych tagów przy odmowie zgody. Jeżeli wysyłają żądania przed zgodą, to jest osobne zadanie do naprawy i nie czeka na kolejny przegląd kwartalny.
6. Usuń zdublowane loadery i wstaw jeden oficjalny snippet. Przy dwóch loaderach kolejność wczytywania zależy od przypadku, a to utrudnia diagnozę na zawsze.
7. Opisz ustalenie w dokumentacji konta: kto wdrożył skrypt, jaki identyfikator jest używany i dlaczego. Przy zmianie agencji nikt tego nie odtworzy z pamięci.

Dlaczego to problem porządku, nie awarii

Nic się nie zepsuło, dane w raportach wyglądają dobrze, klient nie zgłasza problemu. Oba stany, i ograniczenie przed zmianą, i zniesienie ograniczenia po niej, działają cicho. Widoczne jest tylko to, co przestaje działać albo zaczyna działać nagle, i wtedy szuka się przyczyny w tagu, a nie w identyfikatorze sprzed dwóch lat.

Prefiks identyfikatora to jedyne miejsce, w którym zapisana jest decyzja o tym, co kontener może uruchomić. Warto znać tę wartość dla każdego konta, które prowadzisz, i sprawdzić ją przed kolejnym wdrożeniem, a nie po nim.