Jeśli Twoja strona korzysta z Google Tag Manager (w polskim interfejsie Menedżer tagów Google), Google zmienia sposób, w jaki Tag Manager uruchamia się na Twoich stronach. W informacji o wersji z 8 października 2026 r. Google pisze, że każdy kontener Tag Managera (miejsce w Tag Managerze, w którym są tagi Twojej strony) uruchomi się od razu po załadowaniu, zamiast czekać na polecenie gtag('config') na stronie. Ta zmiana Google Tag Manager gtag config najbardziej dotyczy stron, które łączą Tag Managera z osobnym kodem Google tag, oraz kontenerów z regułami (w angielskim interfejsie triggers), które uruchamiają tagi przy każdym zdarzeniu.
Google wysłał e-maile do właścicieli kontenerów, które uważa za źle skonfigurowane. Nie podał, ilu ich jest, a jego strona pomocy dotycząca poprawki nadal mówi, że aktualizacja nastąpi “wkrótce”.
Co zmieniło się w Google Tag Manager 8 października?
Google pisze, że kontenery Tag Managera nie będą już czekać na linię gtag('config'), czyli polecenie, które mówi tagowi Google, na które konto wysyłać dane i z jakimi ustawieniami. Informacja o wersji z 8 października mówi (w naszym tłumaczeniu), że wszystkie fragmenty kodu kontenera Google Tag Manager (gtm.js) “będą inicjowane przy ładowaniu kontenera, niezależnie od poleceń gtag(‘config’)”.
Fragment kodu to kilka linijek wklejonych na każdej stronie Twojej witryny. Tag to mały fragment kodu, który raportuje, co dzieje się w witrynie, na przykład wyświetlenie strony albo wysłany formularz. Tag wysyła te informacje do narzędzia takiego jak Google Analytics czy Google Ads. Witryna może ładować tagi Google jednym z dwóch fragmentów kodu:
| Fragment kodu Tag Managera | Fragment kodu Google tag | |
|---|---|---|
| Ładowany plik | gtm.js | gtag.js |
| Używany identyfikator | Zaczyna się od GTM- | Identyfikator usługi, np. G- lub AW- |
Oba fragmenty zapisują dane w dataLayer, kolejce komunikatów na stronie, którą czyta Tag Manager. Do tej pory kontener mógł zauważyć linię gtag('config') w innym miejscu strony i na nią poczekać, a niektóre strony na tym polegały. Informacja o wersji zmienia też to, co widzi kontener: polecenia config “będą teraz widoczne w dataLayer jako zdarzenia gtag.config”.
Których stron dotyczy zmiana Google Tag Manager gtag config?
Zmiana dotyczy dwóch grup stron. E-maile od Google trafiły do pierwszej grupy, która korzysta z tego, co Google nazywa “nieobsługiwaną implementacją”. Druga grupa może mieć konfigurację, którą Google uważa za poprawną, ale ma reguły, które uruchamiają tagi przy każdym zdarzeniu.
Konfiguracje mieszane. Strona pomocy Google o konfiguracji gtag.js opisuje witryny, które wdrażają identyfikator G-, AW- lub DC przez ścieżkę fragmentu kodu Tag Managera. Jako przykład nieprawidłowej konfiguracji podaje standardowy fragment z identyfikatorem GTM-, po którym stoi samodzielna linia gtag('config'). O takich witrynach Google pisze, że “mogą doświadczać nieoczekiwanych zmian w działaniu tagów”, a użytkownicy takich kontenerów “otrzymali e-maila z powiadomieniem”.
Reguły z symbolem wieloznacznym. Reguła mówi tagowi, kiedy ma się uruchomić. Reguła zdarzenia niestandardowego może dopasowywać nazwy zdarzeń wzorcem .*, który pasuje do każdego zdarzenia w dataLayer. Informacja o wersji ostrzega (w naszym tłumaczeniu): “Jeśli Twoje kontenery Google Tag Manager używają reguł zdarzeń niestandardowych z symbolem wieloznacznym, ta zmiana może spowodować uruchomienie tych tagów.”
Pomoc Google dotycząca reguł zdarzeń niestandardowych już wcześniej zalecała węższy wzorzec, bo .* pasuje też do zdarzeń, które Tag Manager i Google tag wysyłają automatycznie. PPC Land zauważa, że ryzyko związane z regułami wieloznacznymi dotyczy też stron, których konfigurację Google uważa za poprawną, bo sam standardowy fragment gtag.js zawiera wywołanie config.
Kiedy Google ogłosił zmianę gtag config?
Ostrzeżenie pojawiło się kilka tygodni przed informacją o wersji. PPC News Feed opisał komunikat na stronie pomocy Google 27 sierpnia 2026 r. Już 20 sierpnia użytkownik forum wsparcia WordPress.org opublikował e-mail, który jego klient otrzymał od Google. Brzmiał on (w naszym tłumaczeniu): “Od 2 października 2026 r. wszystkie fragmenty kodu gtm.js będą inicjowane przy ładowaniu kontenera”.
Informacja o wersji nosi datę 8 października. Strona pomocy Google dotycząca poprawki nadal mówi, że fragmenty kodu Tag Managera “zostaną wkrótce zaktualizowane”. Jak zauważają zarówno PPC Land, jak i Relevant Audience, Google nie powiedział, czy zmiana objęła wszystkie kontenery jednego dnia, czy jest wprowadzana stopniowo.
Czego Google nie powiedział
Google nie podał ostatecznego terminu ani żadnej miary tego, jak bardzo zmiana może zaburzyć dane. Relevant Audience zauważa, że informacja o wersji “nie wspomina o żadnym ograniczeniu krajowym ani regionalnym”, a strona pomocy dotycząca poprawki również żadnego nie podaje.
Jest też luka praktyczna. E-mail trafił do osoby wpisanej przy kontenerze. Relevant Audience zwraca uwagę, że jeśli to były pracownik albo dawny twórca strony, “ostrzeżenie mogło nigdy nie dotrzeć do osoby, która dziś zarządza witryną”.
Co to oznacza dla Twojej firmy
Naszym zdaniem to powód do starannego sprawdzenia, jak mierzysz ruch i zapytania. Chodzi o to, by sprawdzić, co ładują Twoje strony, wybrać jedną z dwóch poprawek Google, jeśli konfiguracja jest mieszana, i przetestować, czy każde zapytanie liczy się raz. Te kroki wykonalibyśmy w tej kolejności, zanim cokolwiek zmienisz na kontach reklamowych.
- Ustal, kto jest właścicielem kontenera. Żeby cokolwiek sprawdzić, potrzebujesz dostępu do Tag Managera, a właścicielem powinna być firma, z agencją dodaną jako użytkownik. Nasz poradnik o tym, jak ocenić agencję marketingową, wyjaśnia, dlaczego konta powinny należeć do Ciebie.
- Sprawdź, jaki fragment kodu ładują Twoje strony. Otwórz swoją witrynę, wyświetl źródło strony i wyszukaj “googletagmanager.com”. Jeśli adres zawiera gtm.js z identyfikatorem zaczynającym się od GTM-, Twój kontener działa w obsługiwany sposób. Jeśli gtm.js ma identyfikator G-, AW- lub DC albo obok fragmentu Tag Managera stoi samodzielna linia
gtag('config'), masz konfigurację, przed którą ostrzegał Google. - Wybierz jedną z dwóch poprawek Google. Użyj fragmentu kodu Google tag (gtag.js) na każdej stronie i usuń fragment gtm.js oraz wszystkie samodzielne linie config. Albo, jeśli Tag Manager obsługuje Twoje inne tagi, zostaw fragment z identyfikatorem GTM- i skonfiguruj Google tag w kontenerze. Przenieś ustawienia, które przekazywała stara linia config, i nie ruszaj konfiguracji zgody na pliki cookie, żeby tagi nadal respektowały wybór odwiedzającego w banerze cookie.
- Przeszukaj kontener pod kątem reguł
.*. Otwórz listę reguł i poszukaj reguł zdarzeń niestandardowych, które pasują do wszystkich zdarzeń. Zawęź każdą z nich do potrzebnych nazw zdarzeń, bo tag uruchamiany przy gtag.config może wysłać te same dane jeszcze raz, na przykład policzyć jedno zapytanie jako dwa. - Przetestuj w Tag Assistant i prawdziwym zapytaniem. Tag Assistant to narzędzie Google do sprawdzania tagów w witrynie, a strona pomocy Google mówi, że Twój identyfikator tagu powinien się tam wyświetlać “z zieloną lub niebieską ikoną stanu”. Potem wyślij testowe zapytanie z telefonu i sprawdź, czy zostało policzone raz, tak jak opisujemy w tekście o tym, gdy Google Ads daje kliknięcia, ale nie zapytania. W ramach prowadzenia kampanii Google Ads sprawdzamy pomiar przed każdą zmianą stawek.
- Porównaj liczby ze skrzynką lub CRM. Zestaw zapytania z Twojej skrzynki lub CRM z konwersjami, które Google raportuje za te same dni, przed 8 października i po nim. Ten sam test stosujemy w pracy nad CRM i analityką, a jeśli liczby przestały się zgadzać, tagi to pierwsze miejsce, które warto sprawdzić.
