Zmiany w Google Tag Manager 2026: inicjalizacja kontenera, zdarzenia gtag.config i ograniczenia ID

Kalendarz zmian w Google Tag Manager w 2026 roku

W 2026 roku Google wprowadził w Tag Managerze kilkanaście zmian, ale tylko dwie wymagają działania w większości kontenerów: ograniczenia zależne od identyfikatora i nowe zdarzenie gtag.config. Pozostałe to nowe funkcje lub zmiany, które warto znać przy planowaniu wdrożeń.

Stan na październik 2026 roku. Google nie podał, czy zmiana z 8 października jest wdrażana od razu dla wszystkich kontenerów, czy stopniowo, dlatego testy warto powtórzyć po kilku dniach.

Ograniczenia ID od 9 lipca 2026: kiedy kontener uruchomi tylko tagi Google

Od 9 lipca 2026 roku zakres tego, co może uruchomić kontener, zależy od identyfikatora, z którym go załadowano, a nie od adresu skryptu. Kontener z identyfikatorem GTM- działa normalnie, a przy identyfikatorach G- i AW- działają wyłącznie tagi i zmienne dostarczone przez Google.

Wcześniej kontener wczytany nieobsługiwaną ścieżką, np. przez adresy przeznaczone dla tagu Google (/gtag/js lub /gtag/destination), przechodził w tryb ograniczony. Teraz reguła jest prostsza: identyfikator przesądza o wszystkim. W praktyce oznacza to, że jeśli Twoje tagi uruchamiają się przez fragment z identyfikatorem G- lub AW-, nie zadziałają w nim niestandardowe tagi HTML, szablony z galerii społeczności ani piksele innych firm, np. Meta czy TikToka. Zablokowane będą też niestandardowe zmienne JavaScript.

Instalacji opartych na standardowych fragmentach kodu od Google zmiana nie dotyczy. Administratorzy kontenerów, na które miała duży wpływ, dostali wiadomości e-mail. Jeżeli w tym czasie nastąpił nagły spadek zdarzeń z pikseli innych firm, a tagi Google działały dalej, sprawdź w narzędziach deweloperskich, z jakim identyfikatorem ładuje się kontener. Rozwiązaniem jest instalacja standardowego fragmentu GTM z identyfikatorem GTM-, opisana w poradniku Google Tag Manager od podstaw.

Inicjalizacja kontenera i zdarzenia gtag.config od 8 października 2026

Od 8 października 2026 roku każdy fragment gtm.js inicjalizuje kontener od razu po jego wczytaniu, niezależnie od poleceń gtag('config') na stronie. Same polecenia config są natomiast widoczne w warstwie danych jako zdarzenia o nazwie gtag.config.

Co się zmieniło w instalacjach hybrydowych

Wcześniej kontener gtm.js potrafił rozpoznać polecenie gtag('config') umieszczone gdzie indziej na stronie i poczekać na nie z inicjalizacją. Część serwisów korzystała z tego, łącząc fragment GTM z luźną linijką konfiguracji zamiast ładować gtag.js. Google uznaje takie konfiguracje za nieobsługiwane i ostrzega, że mogą w nich nastąpić nieoczekiwane zmiany w działaniu tagów. Typowy przykład wygląda tak:

<!-- Konfiguracja hybrydowa – nieobsługiwana -->
<script async src="https://www.googletagmanager.com/gtm.js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

Masz dwie poprawne drogi. Pierwsza to pełny fragment tagu Google, czyli skrypt gtag/js z identyfikatorem G- i poleceniem config, umieszczony zaraz po otwarciu sekcji head. Druga to standardowy fragment GTM z identyfikatorem GTM- i tag Google skonfigurowany w panelu Tag Managera. Zanim usuniesz linijkę config, przenieś jej ustawienia, np. niestandardowe parametry, do nowej konfiguracji, żeby nie powstała luka w danych.

Reguły „Zdarzenie niestandardowe” z wyrażeniem .*

Druga grupa, której dotyczy zmiana, jest znacznie liczniejsza. Reguła typu „Zdarzenie niestandardowe” z nazwą zdarzenia .* i włączonym dopasowaniem do wyrażenia regularnego reaguje na każde zdarzenie w warstwie danych, więc od października także na gtag.config. Dotyczy to również stron z poprawną instalacją gtag.js, bo standardowy fragment zawiera polecenie config.

Ryzyko zależy od tego, co wisi na takiej regule. Tagi diagnostyczne i logujące wyślą jeden dodatkowy wiersz – to zwykle drobna niedogodność. Groźniejsze są tagi konwersji, remarketingu i niestandardowy HTML przekazujący każde zdarzenie do zewnętrznej platformy, bo mogą zawyżyć liczby. Ponieważ GTM obsługuje składnię wyrażeń regularnych bez tzw. lookahead, najprościej dodać do reguły warunek wykluczający:

Typ reguły: Zdarzenie niestandardowe
Nazwa zdarzenia: .*   [x] Użyj dopasowania do wyrażenia regularnego
Uruchamiaj w przypadku: Niektóre zdarzenia niestandardowe
Warunek: Event | nie jest równe | gtag.config

Alternatywa – zawężona lista zdarzeń:
Nazwa zdarzenia: ^(view_item|add_to_cart|begin_checkout|purchase)$

Jak sprawdzić, czy zmiany w GTM 2026 dotyczą Twojej strony

Audyt sprowadza się do dwóch pytań: jak kontener jest zainstalowany i czy w kontenerze są reguły reagujące na wszystkie zdarzenia. Poniższą procedurę przejdziesz w około godzinę.

1. Przejrzyj kod źródłowy. Wyszukaj frazy gtm.js?id=, gtag/js?id= i gtag('config'. Fragment gtm.js z identyfikatorem G-, AW- lub DC- albo polecenie config bez skryptu gtag.js nad nim oznacza instalację hybrydową.
2. Sprawdź żądania sieciowe. W narzędziach deweloperskich przeglądarki, w zakładce Network, przefiltruj żądania po fragmencie „googletagmanager” i zanotuj, które skrypty się ładują i z jakimi identyfikatorami.
3. Otwórz Tag Assistant. W sekcji z listą znalezionych tagów Google upewnij się, że widzisz właściwy kontener i tagi.
4. Wylistuj ryzykowne reguły. W GTM przejrzyj reguły „Zdarzenie niestandardowe” z włączonym wyrażeniem regularnym i zapisz, jakie tagi uruchamiają.
5. Znajdź zdarzenie w podglądzie. W trybie podglądu odszukaj gtag.config na liście zdarzeń i sprawdź, które tagi się przy nim uruchomiły. Strukturę samego zdarzenia też najlepiej obejrzeć właśnie tam.
6. Zdecyduj o każdym tagu. Tagi logujące możesz zostawić, a dla konwersji, remarketingu i tagów przekazujących dane dalej dodaj wykluczenie lub zawęź listę zdarzeń.
7. Porównaj dane. Zestaw liczbę odsłon i konwersji z 7 dni przed zmianą i po niej. Nagły wzrost transakcji przy stałych przychodach w sklepie wskazuje na duplikaty – sposoby ich wykrywania opisujemy w artykule o duplikatach transakcji w GA4.

Jeśli konwersje w GA4 i Google Ads zaczęły się rozjeżdżać właśnie w październiku, przyczyną może być tag uruchamiany dodatkowym zdarzeniem tylko w jednym z systemów. Inne źródła różnic omawiamy w tekście o rozbieżnościach konwersji między GA4, Google Ads i Meta. Szerszą listę kontrolną kontenera przed sezonem znajdziesz w audycie tagów przed Black Friday, a techniki testowania – w poradniku jak sprawdzić, czy tag działa.

Opcjonalna optymalizacja kontenera od 12 października

Od 12 października 2026 roku możesz przełączyć kontener tak, żeby wysyłał dane bezpośrednio do usług pomiarowych Google, bez ładowania osobnego skryptu gtag.js. Google uzasadnia zmianę tym, że dodatkowy skrypt wydłużał przesyłanie danych.

Według zapowiedzi z maja 2026 roku optymalizacja jest dobrowolna: nic nie zmieni się automatycznie, a proces uruchamia osoba z uprawnieniami do edycji, zatwierdzania lub publikowania przez baner w interfejsie GTM. Wszystkie wygenerowane zmiany można obejrzeć przed publikacją. Ustawienia tagu Google trafiają do nowej zakładki ustawień kontenera, która pokazuje, do jakich usług Google kierowane są dane, a tagi zdarzeń pozostają bez zmian. Google opisuje też, że optymalizacja tworzy powiązania kontenera z kontami docelowymi, takimi jak usługa GA4 czy konto Google Ads; uprawnienia wynikające z tych powiązań można potem zmienić w zarządzaniu użytkownikami.

Zanim się zdecydujesz, zanotuj numer bieżącej wersji kontenera, żeby w razie problemów wrócić do niej przez opublikowanie poprzedniej wersji. Po publikacji sprawdź w podglądzie, czy tagi nadal respektują stan zgód, oraz porównaj czasy ładowania przed zmianą i po niej. Jak mierzyć wpływ skryptów na szybkość strony, pokazujemy w artykule o tagach a Core Web Vitals. Sama optymalizacja dotyczy sposobu dostarczania danych – nie zmienia reguł, zgód ani zakresu zbieranych informacji.

Mniejsze zmiany z przełomu 2025 i 2026 roku

Oprócz dwóch najważniejszych zmian Google wprowadził kilka udogodnień, które upraszczają typowe konfiguracje. Najbardziej przydatne są nowe zmienne i rozwój bramy tagów.

• Zmienne Client ID, Session ID i Session Number (11 grudnia 2025 roku) – oficjalny sposób na pobranie identyfikatora klienta i sesji GA4 bez odczytywania ciasteczek własnym kodem. Razem z nimi pojawił się typ zmiennej do odczytu danych GA4 z wybranym identyfikatorem pomiaru lub prefiksem ciasteczek.
• API readAnalyticsStorage (sierpień 2025 roku) – to samo dla twórców szablonów niestandardowych, którzy wcześniej musieli rozbierać format ciasteczek GA.
• Szerszy zbiór zdarzeń w Google Ads (luty 2026 roku) – na stronie mogą pojawić się dodatkowe żądania do domen Google; uwzględnij to w opisie celów przetwarzania w banerze zgód.
• Rozwój Google Tag Gateway – kolejne integracje z Akamai, Fastly, Google Cloud i Amazon CloudFront. Czym Google Tag Gateway różni się od pełnego tagowania po stronie serwera, wyjaśniamy w porównaniu Google Tag Gateway i server-side GTM.
• Propozycje opisu wersji (17 września 2026 roku) – AI podpowiada nazwę i opis publikowanej wersji; traktuj je jako szkic.

Równolegle zmieniały się zasady po stronie GA4 i zgód. Od 15 czerwca 2026 roku o przepływie danych reklamowych z tagu GA do Google Ads decyduje wyłącznie ad_storage, co opisujemy w tekście o oddzieleniu Google Signals od ad_storage. Pełny przegląd nowości w raportach znajdziesz w artykule o GA4 w 2026 roku, a konfigurację konwersji z danymi klientów – w poradniku o Enhanced Conversions przez GTM. Wszystkie teksty o konfiguracji kontenera zebraliśmy w podtemacie Google Tag Manager.