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, zauważasz, że tag nie uruchamia się. Kontener ładuje się poprawnie i działa, jednak wyłącznie w trybie ograniczonym.

9 lipca 2026 roku Google zmieniło regułę, która wywoływała taki stan. Wcześniej kontenery ładowane z nietypowych ścieżek, takich jak /gtag/js albo /gtag/destination, przechodziły w stan ograniczony. Przepuszczały wtedy wyłącznie tagi oraz zmienne dostarczone przez samo Google. Od najnowszej wersji o zachowaniu decyduje identyfikator użyty do wczytania kontenera, niezależnie od ścieżki. Kontener z prefiksem GTM- otrzymuje pełne uprawnienia. Z kolei prefiksy produktowe, czyli G- i AW-, nadal zezwalają wyłącznie na działanie tagów i zmiennych od Google. Wdrożeń korzystających z oficjalnych snippetów Google ta zmiana w ogóle nie dotyczy.

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

Złe ścieżki rzadko są wpisywane celowo. Najczęściej odpowiada za nie plugin CMS, który wstrzykuje własny loader. Czasami robi to moduł zgód wstawiający skrypt po akceptacji, a innym razem narzędzie marketingowe zakładające konto analityczne i dodające własny fragment kodu. Zdarzają się też szablony stron z twardo wklejonym adresem skryptu. Osobny przypadek to migracje. Zdarza się, że ktoś podmienił identyfikator w istniejącym snipcie gtag, ale zostawił starą ścieżkę, ponieważ strona nadal funkcjonowała.

Główny kłopot z takim wdrożeniem polega na braku widocznych sygnałów błędu. Konsola przeglądarki milczy, kontener się ładuje, a dane trafiają do Google. Ograniczenie widać dopiero w momencie próby uruchomienia kodu, którego Google nie dostarcza. W rezultacie kontener może pracować w okrojonym trybie przez wiele miesięcy, a zespół dowiaduje się o problemie przy okazji konfiguracji pierwszego zewnętrznego tagu.

Jak sprawdzić typ wczytywanego kontenera

Podstawą są dwa żądania sieciowe. Oficjalny snippet GTM wysyła zapytanie o plik gtm.js?id=GTM-XXXXXXX. Zunifikowany tag Google i wdrożenia produktowe odpytują gtag/js?id=... lub ścieżkę /gtag/destination. W narzędziach deweloperskich wystarczy nałożyć filtr na ciąg gtag i gtm. Wtedy widać, który wariant występuje na stronie i w jakiej kolejności ładuje się względem menedżera zgód.

Następnie należy sprawdzić prefiks identyfikatora. Zwróć uwagę na znaki przed myślnikiem w adresie żądania. Ciąg GTM- oznacza kontener z pełnym zakresem tagów, obejmujący własny HTML, JavaScript, zmienne i skrypty stron trzecich. Z kolei G- i AW- to tagi produktowe ograniczone do wysyłki danych do usług Google. Dokumentacja Google opisuje ten mechanizm jako sposób na określanie zakresu uprawnień przez sam identyfikator, którym posługuje się dana strona.

Zmiana działa w obie strony

To najważniejszy praktyczny skutek aktualizacji. Jeżeli kontener z prefiksem GTM- był wcześniej wczytywany z nietypowej ścieżki, przed 9 lipca działał w trybie ograniczonym. Tagi HTML, skrypty zewnętrznych dostawców i szablony własne nie uruchamiały się. Po wprowadzeniu zmian ten sam kontener odzyskuje pełne uprawnienia bez jakiejkolwiek modyfikacji w panelu GTM.

W praktyce oznacza to, że tag dodany dwa lata temu i zapomniany przez zespół może zacząć działać przy najbliższej odsłonie strony. Na stronie pojawiają się nowe żądania sieciowe i mechanizmy zapisu w przeglądarce. Przy wdrożeniach korzystających z Consent Mode v2 należy upewnić się, czy takie tagi blokują się po odmowie zgody, czy też wysyłają dane od razu. Nie każdy tag zewnętrzny czeka na sygnał zgody i nie każdy został na taką sytuację przygotowany.

Dla części klientów zmienia się w ten sposób zakres danych opuszczających stronę. Zmiana w jednym pliku po stronie Google ma więc realne skutki dla dokumentacji. Należy przy tej okazji zaktualizować rejestr narzędzi i politykę prywatności. W razie kontroli UODO trzeba jasno wskazać, kto otrzymuje dane i na jakiej podstawie.

Kiedy kontener ma prefiks G- lub AW-

Taka konfiguracja nie jest błędem. Tak zachowuje się strona wdrożona z użyciem samego tagu Google, bez wsparcia Tag Managera. Jeżeli klient potrzebuje wyłącznie GA4 i mierzenia konwersji Google Ads, ograniczony zakres przynosi korzyści, ponieważ kontener fizycznie nie może uruchomić obcego kodu.

Trudności pojawiają się w momencie wyjścia poza ekosystem Google. Dotyczy to pikseli dostawców, narzędzi do nagrywania sesji, chatów czy systemów rekomendacji. Przy takim identyfikatorze nie da się ich uruchomić, a podmiana znaków w adresie skryptu nie zmienia typu kontenera. Poprawnym rozwiązaniem jest założenie kontenera GTM i wdrożenie oficjalnego snippetu z prefiksem GTM-. Dopiero wtedy zakres uprawnień obejmuje własny kod.

Poprawne wdrożenie po zmianach

Kontener z prefiksem GTM- musi być wczytywany zgodnie z dokumentacją: jednym oficjalnym snippetem odpytującym o plik gtm.js. Wewnątrz kontenera konfiguruje się tag Google dla GA4 oraz konwersje Google Ads. Z kolei tagi zewnętrznych dostawców działają osobno, z własnymi wyzwalaczami i zdefiniowanymi warunkami zgody.

Stary snippet gtag z identyfikatorem G- staje się w tym układzie zbędny. Jeżeli pozostanie na stronie razem z kontenerem, powstaje drugie źródło danych o tym samym ruchu i drugie miejsce wymagające sprawdzania zgody. Zdublowane wdrożenie rodzi zamieszanie w okresie przejściowym. Część tagów uruchamia się z kontenera, część z osobnego skryptu, a całość konfiguracji rozmywa się na dwa środowiska.

Po naniesieniu poprawek kontrola sprowadza się do trzech elementów. Sprawdzamy żądanie gtm.js?id=GTM-... w narzędziach deweloperskich, weryfikujemy obecność kontenera w Tag Assistant pod właściwym identyfikatorem i potwierdzamy w podglądzie istnienie tagów, które wcześniej były blokowane. Następnie można przejść do testowania zgody. Nowe żądania sieciowe trzeba ocenić pod kątem uprawnień udzielonych przez użytkownika.

Lista kontrolna dla wdrożeń klienta

1. Zbierz wszystkie ścieżki wdrożenia. Sprawdź w źródle strony lub w przechwyconych żądaniach, czy ładuje się gtm.js, czy gtag/js, i zanotuj przypisany do nich identyfikator.
2. Zapisz dla każdego wdrożenia parę składającą się z prefiksu identyfikatora oraz ścieżki. Te dwa fakty determinują zakres działania tagów.
3. Sprawdź w Tag Assistant, w jaki sposób Google odczytuje identyfikator. Rozbieżność między stroną a narzędziem najczęściej oznacza zdublowany loader lub stary, nieusunięty snippet.
4. Wejdź do każdego kontenera z prefiksem GTM- i sprawdź tagi HTML, szablony własne, skrypty zewnętrzne oraz niestandardowe zmienne dostawców. Zwróć uwagę na datę dodania i zweryfikuj, czy tag nie zaczął nagle wysyłać danych po 9 lipca.
5. Sprawdź zachowanie tagów przy odmowie zgody. Jeżeli wysyłają żądania przed zebraniem zgody, należy to naprawić od razu.
6. Usuń zdublowane loadery i wstaw jeden oficjalny snippet. Przy dwóch loaderach kolejność wczytywania jest losowa i na stałe utrudnia diagnozę.
7. Opisz wprowadzone ustalenia w dokumentacji konta. Zapisz, kto wdrożył skrypt, jakiego identyfikatora użyto i z jakiego powodu. Przy zmianie agencji lub zespołu taka wiedza szybko znika, jeśli nie jest utrwalona.

Brak błędów to nie to samo co poprawne wdrożenie

W ograniczonym trybie nic nie zgłasza awarii. Dane w raportach wyglądają prawidłowo, a klient nie narzeka na problemy. Ograniczenie przed zmianą, a także jego zniesienie po 9 lipca, odbywają się po cichu. Uwagę zwraca jedynie narzędzie, które przestaje działać lub włącza się niespodziewanie. Często szuka się wtedy przyczyny w samym tagu zamiast sprawdzić identyfikator dodany dwa lata wcześniej.

Prefiks identyfikatora to jedyne miejsce decydujące o tym, co kontener uruchamia. Należy znać tę wartość dla każdego prowadzonego konta i weryfikować ją przed rozpoczęciem nowych wdrożeń.