Ten sam plik, dwa identyfikatory

Google tag i Tag Manager przez dziesięć lat były dwiema drogami do tego samego. Od wiosny 2026 Google je łączy: istniejące tagi Google są podnoszone do pełnoprawnych kontenerów Tag Managera, a produkty Google, do których kontener wysyła dane, nazywają się odtąd celami.

Przejście jest dobrowolne, samo z siebie nic nie zmienia, a pożytek jest raczej niewielki. Godne uwagi jest inne zdanie – to z notatki z 9 lipca 2026, mówiące, że odtąd identyfikator decyduje o tym, co kontener w ogóle może.

Czym jest cel

Dotąd kontener doładowywał osobną bibliotekę dla każdego produktu Google: raz gtag/js dla identyfikatora pomiaru, raz dla konta reklamowego, ewentualnie jeszcze raz dla Floodlight. Po przejściu te produkty są celami przy kontenerze, a dostarczaniem zajmuje się sam plik kontenera. Opis Google odnotowuje, że każdy cel Google nadal otrzymuje własny tag – konsolidowane jest dostarczanie, nie konfiguracja.

Zysk nie leży zatem w rozmiarze pliku. Kontener obsługujący trzy cele jest większy niż taki bez żadnego. Odpada runda w przebiegu ładowania: dokument znajduje kontener, kontener znajduje bibliotekę, biblioteka zgłasza pierwsze trafienie. Usunięcie środkowego stopnia przesuwa wszystko, co następuje po nim, do przodu.

Decyduje identyfikator, a nie ścieżka

9 lipca 2026 Google opublikowało notatkę o zachowaniu kontenerów przy nieobsługiwanych ścieżkach instalacji. Rozstrzygające zdanie mówi, że identyfikator użyty do załadowania kontenera steruje tym zachowaniem, niezależnie od użytej ścieżki. Kontener załadowany z GTM-… działa jak dotąd. Kontener załadowany z identyfikatorem produktu takim jak G-… lub AW-… jest ograniczony do tagów i zmiennych dostarczanych przez Google.

To miejsce, w którym konfiguracja potrafi niepostrzeżenie stać się węższa. Podniesienie istniejącego tagu Google przy pozostawieniu starego fragmentu z identyfikatorem pomiaru daje pełnoprawny kontener w interfejsie i ograniczone wykonanie na stronie. Własne tagi HTML, obcy dostawcy i ręcznie napisane zmienne wtedy znikają – nie dlatego, że zostały usunięte, lecz dlatego, że identyfikator w kodzie źródłowym ich nie dopuszcza.

Co dzieje się z poleceniem config

Nowe fragmenty wdrożeniowe będą jednolite i nie będą już zawierać polecenia gtag('config', …). Jego miejsce zajmuje reguła o nazwie gtm init, przez którą ustawia się zachowanie przy starcie. Dla istniejących konfiguracji przewidziano, że reguła ta potrafi zaczekać na stare polecenie, aby zachować dotychczasową kolejność.

Co znika z fragmentu

  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');    <- nie ma tego w nowym fragmencie

Co zajmuje jego miejsce

  reguła "gtm init" w kontenerze
    steruje tym, kiedy następuje inicjalizacja
    potrafi zaczekać na stare polecenie config tam, gdzie
    istniejąca konfiguracja nadal je wysyła

Czym steruje identyfikator (notatka z 9 lipca 2026)

  załadowany z GTM-…   pełny zakres funkcji
  załadowany z G-…     tylko tagi i zmienne dostarczane przez Google
  załadowany z AW-…    tylko tagi i zmienne dostarczane przez Google

Wszędzie tam, gdzie rozwiązanie zgód wstrzymuje dziś polecenie config albo zmienia jego kolejność, jest to dokładnie miejsce do obejrzenia przed przejściem. Reguła potrafi odtworzyć tę samą kolejność, ale nie robi tego sama z siebie.

Co znaczy tu dobrowolne

Strona Google mówi wyraźnie: żadne zmiany nie zostaną wprowadzone automatycznie, a przyjęcie nowej konfiguracji pozostaje decyzją. Istniejące kontenery, tagi, reguły i zmienne działają bez zmian, a tagi obcych dostawców pozostają w pełni obsługiwane.

Dobrowolne nie znaczy jednak bez następstw. Nowe fragmenty wyglądają inaczej niż stare, a zespół opiekujący się dwiema witrynami opiekuje się odtąd być może dwoma różnymi sposobami instalacji. Instrukcja spisana w firmowej wiki obowiązuje wtedy dla jednej witryny, a dla drugiej już nie.

Co da się policzyć wcześniej

Pożytek z przejścia da się ustalić na własnej witrynie w kilka minut, zanim cokolwiek zostanie zmienione. Panel sieci w przeglądarce z filtrem googletagmanager.com pokazuje, ile bibliotek faktycznie się ładuje. Pojedynczy kontener z jednym identyfikatorem pomiaru ładuje często tylko dwa pliki; tam niewiele da się zyskać. Konfiguracja narosła przez lata, z kontem reklamowym, Floodlight i osobno wstawionym tagiem Google, ładuje cztery albo pięć i tam rachunek się opłaca.

Druga liczba stoi w interfejsie: ile tagów własnej budowy leży w kontenerze. Ona rozstrzyga, jak bolesny byłby błędny identyfikator w kodzie źródłowym.

Kiedy lepiej poczekać

Przejście jest nowe, jest dobrowolne, a jego zysk to jedna runda w przebiegu ładowania. To nie uzasadnia operacji na konfiguracji, która działa – uzasadnia natomiast podgląd na drugorzędnej witrynie, aby nowy fragment, regułę i wykonanie zobaczyć raz, zanim nadejdzie decyzja.

Od razu opłaca się natomiast spojrzenie na identyfikator w kodzie źródłowym. Stoi tam już dziś, od 9 lipca 2026 steruje większą liczbą rzeczy niż wcześniej i jest jedynym miejscem w całej tej zmianie, gdzie możliwa jest cicha utrata funkcji.