Kontener rośnie przez dodawanie, a rzadko przez usuwanie. To sprawdzenie odczytuje w przeglądarce eksport Google Tag Managera i wylicza, co nie jest już z niczym połączone: tagi bez działającej reguły (triggera), reguły i zmienne, do których nic się nie odwołuje, pozostałe szablony i foldery oraz elementy potrzebne tylko wstrzymanym tagom. Uszkodzone odwołania (identyfikator reguły lub {{zmienna}}, która nie istnieje) i zduplikowane identyfikatory też trafiają na listę, bo to właśnie one sprawiają, że tag po cichu nic nie wysyła.
W Tag Managerze: Administracja → Eksportuj kontener, dla wersji lub przestrzeni roboczej. Format API wersji kontenera także działa.
Wszystko poniżej można usunąć, pogrupowane jak w Tag Managerze. Najlepiej w tej kolejności: tagi, reguły, zmienne, szablony, foldery – wtedy przy usuwaniu nic już nie odwołuje się do elementu. Zmiennych wbudowanych się nie usuwa, tylko odznacza w Zmienne → Konfiguruj. Pozycje z „używane tylko przez …” zwalniają się, gdy wskazane tam elementy znikną.
To nie są kandydaci do usunięcia, lecz błędy do naprawy: odwołania donikąd, zduplikowane identyfikatory i podobne.
Przegląd
| Element | W kontenerze | Kandydaci do usunięcia |
|---|
Budowa: format eksportu (containerVersion z listami tagów, reguł, zmiennych, folderów, zmiennych wbudowanych, szablonów, stref, klientów i transformacji), zduplikowane identyfikatory i nazwy.
Odwołania: reguły uruchamiające i blokujące, członkowie grup reguł, tagi konfiguracji i czyszczenia według nazw, każda {{zmienna}} w parametrach, filtrach i polach zgód, typy własnych szablonów (cvt_…) oraz identyfikatory folderów. Nazwy są porównywane dokładnie, z wielkością liter i spacjami.
Osierocone elementy: tag jest aktywny, gdy nie jest wstrzymany i ma istniejącą regułę uruchamiającą albo jest uruchamiany przez aktywny tag. Od aktywnych tagów, stref, klientów i transformacji śledzone są reguły, zmienne i szablony. To, do czego się nie dociera, jest albo nieużywane (nic się do tego nie odwołuje), albo używane tylko przez martwe elementy (odwołują się do tego tylko wstrzymane lub nigdy nieuruchamiane elementy).
Kolejność: najpierw uszkodzone odwołania, potem nieużywane elementy, potem punkty warte uwagi.
Sprawdzenie opiera się na nazwach i identyfikatorach w eksporcie. Niewidoczne są nazwa składana w skrypcie jako zwykły tekst, element, którego nadal używa inna przestrzeń robocza, oraz tag pozostawiony celowo. Wymieniony element jest kandydatem, a nie wyrokiem: przed usunięciem warto porównać go z historią wersji i podglądem. Kontenery serwerowe są czytane tak samo, a odwołania od klientów i transformacji liczą się jako aktywne.
JSON kontenera jest odczytywany i analizowany w przeglądarce i nigdzie nie jest wysyłany. Eksporty zawierają identyfikatory tagów, identyfikatory pomiarów, a czasem kody pikseli lub klucze w niestandardowym HTML; dlatego nic tu nie jest zapisywane ani przesyłane, a obszary wyników są wyłączone z nagrywania sesji.
Więcej narzędzi do kontenerów GTM:
- Analizator duplikatów w GTM – znajduje tagi, reguły i zmienne, które robią to samo dwa razy.
- Audyt konwencji nazewnictwa w GTM – porównuje nazwy elementów z przyjętą konwencją.
- Historia kontenera GTM i wyszukiwanie pogłębione – znajduje wersję, w której element został dodany, zmieniony lub usunięty.
- Generator ścieżek zmiennych dataLayer w GTM – zamienia zagnieżdżony obiekt dataLayer w ścieżki zmiennych do utworzenia.
- Porównanie tekstu i kodu – porównuje dwa eksporty, na przykład przed porządkami i po nich.
Artykuły o utrzymywaniu porządku w kontenerze:
- Tutorial: Ustalenie konwencji nazw GTM i wprowadzenie jej w istniejącym kontenerze – po nazwach łatwo rozpoznać osierocone elementy.
- Porównywanie dwóch eksportów kontenera GTM – tak widać, że porządki usunęły tylko to, co miały.
- Tutorial: Znalezienie wersji kontenera, w której zmienił się tag – na wypadek, gdy usunięty element jednak okaże się potrzebny.
- Tutorial: Przygotowywanie i weryfikacja zmian w Google Tag Manager za pomocą Claude Code – sprawdzenie porządków przed publikacją.