GTM zmienia obsługę gtag('config'): sprawdź wyzwalacze wieloznaczne

Google zmienił moment, w którym kontener zaczyna pracować, a skutek uboczny może odpalać tagi, których nikt nie planował. Zmiana trafiła do notatek wydania Tag Managera 8 października 2026 pod tytułem "Standardizing gtag('config') command behavior for Google Tag Manager". Notatka ma trzy zdania, więc łatwo ją przegapić.

Druga połowa notatki to ryzyko operacyjne, które czeka w twoim kontenerze, aż wydanie dotrze na stronę.

Co dokładnie się zmieniło

Każdy snippet Google Tag Managera, ten z gtm.js, ma być inicjalizowany przy wczytaniu kontenera i nie czeka już na polecenie gtag('config'). Dla strony wdrożonej standardowo zmiana jest prawie niewidoczna: Google usuwa zależność, którą wytworzyła tylko część wdrożeń.

Drugie zdanie trzeba przeczytać dwa razy. Skoro kontener nie czeka na polecenie konfiguracji, Google musi zdecydować, co zrobić z poleceniami, które nadal są na stronie. Odpowiedź brzmi: uczynić je widocznymi i przepuszczać przez dataLayer jako zdarzenia gtag.config.

Dlaczego zdarzenie w dataLayer ma znaczenie

Wpis gtag.config to pchnięcie do dataLayer z nazwą zdarzenia. Standardowe wyzwalacze pilnują gtm.js, gtm.dom, gtm.load i odsłon, więc je pomijają. Wyzwalacze zdarzeń niestandardowych zachowują się inaczej, a notatka wydania nie ukrywa konsekwencji: "If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire."

Dokumentacja wyzwalacza zdarzenia niestandardowego ostrzega przed tym od lat. Przy dopasowaniu regex wzorzec .* oznacza, że wyzwalacz uruchomi się na wszystkich wykrytych zdarzeniach, w tym na tych, które Google Tag Manager i Google tag emitują automatycznie. Rada była łatwa do zignorowania, dopóki automatyczny strumień zdarzeń był krótki. Od tego wydania gtag.config jest jego częścią.

Co realnie może pójść nie tak

Szkoda zależy od tego, do czego podpięty jest wyzwalacz, dlatego jedna odpowiedź dla całego kontenera jest błędna. Patrz na tagi.

• Tag zdarzenia GA4 wysyła dodatkowe trafienie za każdym razem, gdy gtag.config trafia do dataLayer, więc liczby zdarzeń i konwersji rosną.
• Tag konwersji Google Ads wysyła sygnał, za którym nie stoi żaden użytkownik. System licytacji czyta dane, których nie było.
• Tag remarketingowy buduje grupę odbiorców ze zdarzenia, którego odwiedzający nie wygenerował.
• Piksel zewnętrznego dostawcy dostaje wywołanie, którego nikt nie projektował.

Żaden z tych przypadków nie psuje strony: w konsoli nie ma błędu, a żaden raport nie powie, że liczba się przesunęła. Różnica między pulpitem i wyciągiem bankowym rośnie, jedno gtag.config naraz.

Nieobsługiwany układ, który Google zamyka

Za notatką stoi strona pomocy "Set up your Google tag installation correctly for gtag.js" z dosadniejszym ostrzeżeniem: snippety GTM wkrótce przestaną rozpoznawać polecenia gtag('config').

Google wskazuje układ, który uznaje za nieprawidłowy: identyfikator niebędący identyfikatorem GTM, czyli zaczynający się od G-, AW- lub DC-, wdrożony przez ścieżkę snippetu gtm.js, a pod nim gtag('config') w osobnym bloku skryptu. Takie strony mogą doświadczyć nieoczekiwanych zmian w działaniu tagów, a administratorzy dotkniętych kontenerów dostali maile. Pytanie, kto dostał maila, szybko wskaże strony do poprawy.

Poprawny układ zależy od celu. Jeśli chcesz wdrażać konfigurację dla Google Ads albo Analytics, użyj standardowego snippetu gtag.js: wczytaj https://www.googletagmanager.com/gtag/js?id=TWOJ_ID, a potem wywołaj gtag('js', new Date()) i gtag('config', 'TWOJ_ID'). Jeśli używasz Tag Managera do innych tagów, zostaw główny snippet GTM i wdróż tag Google w nim. Google mówi wprost: zastąp identyfikator G-, AW- lub DC- identyfikatorem GTM-XXXXXX.

Jak znaleźć wyzwalacze w ryzyku

Przejdź listę wyzwalaczy w każdym kontenerze. Szukasz tych zdarzeń niestandardowych, których warunek dopasowania jest szerszy niż zdarzenia, które naprawdę wysyłasz. Za większość ekspozycji odpowiadają trzy wzorce.

Pierwszy to nazwa zdarzenia ustawiona na .* z dopasowaniem regex. Drugi to wyrażenie, które wygląda na konkretne, ale takie nie jest, na przykład .*click albo samo _event. Trzeci to wyzwalacz z wąską nazwą zdarzenia, ale z ustawieniem "wyzwalacz uruchamia się na" zostawionym na wszystkich zdarzeniach niestandardowych. Szerokie wyzwalacze z wąskimi wyjątkami działają, dopóki strumień zdarzeń się nie zmieni.

Zapisz, do czego podpięty jest każdy wyzwalacz. Wieloznaczny wyzwalacz na tagu testowym jest nieszkodliwy. Ten sam wyzwalacz na tagu konwersji to cały problem. Problemem nie jest wyzwalacz, tylko para.

Poprawka to węższy warunek, nie usunięty wyzwalacz

Trzy drogi, i nie są równe. Czyste rozwiązanie to zawężenie wyrażenia do zdarzeń, które faktycznie wysyłasz. Jeśli strona wysyła form_submit, quote_request i video_play, wypisz je i usuń wieloznaczność. To więcej pracy na wejściu i zamyka klasę problemów na stałe.

Szybkie rozwiązanie to zostawienie szerokiego wzorca i dodanie wykluczenia, żeby wyzwalacz pomijał gtag.config. Działa, dopóki nikt nie doda kolejnego automatycznego zdarzenia.

Czego nie robić: zostawić to bez zmian, bo tag jest dziś tylko testowy. Tagi zmieniają przeznaczenie, a kontenera nikt nie czyta ponownie przed kolejną kampanią. Nie rozwiązuj tego też usunięciem wyzwalacza. Ruch, który na nim polegał, przestanie się liczyć, a zauważysz to dopiero, gdy klient zapyta, gdzie zniknęły konwersje. Zawęź warunek i opublikuj wersję z opisem zmiany.

Testuj w podglądzie przed publikacją

Tryb podglądu to jedyne miejsce, gdzie zobaczysz zdarzenie przed produkcją. Wczytaj stronę w sesji podglądu, poszukaj wpisu gtag.config w strumieniu zdarzeń i sprawdź, które tagi się na nim odpaliły. Jeśli na liście jest tag konwersji albo piksel, znalazłeś problem, zanim zaczął kosztować. Tag Assistant powie tylko, czy tag Google się ładuje. Podgląd pokaże, co jeszcze ciągnie za sobą.

Strona zgodności

Dla polskich wdrożeń to pytanie o zgodność tak samo jak o jakość danych. Zgodnie z art. 399 Prawa komunikacji elektronicznej przechowywanie i dostęp do informacji w urządzeniu końcowym wymaga zgody, a art. 400 PKE określa standard jej wyrażenia: musi być dobrowolna, konkretna, świadoma i jednoznaczna. Nic zbędnego nie powinno działać przed jej zebraniem.

Wyzwalacz wieloznaczny, który odpala tag reklamowy na gtag.config, działa przeciw tej zasadzie, bo tag uruchamia się na zdarzeniu, którego odwiedzający nie wygenerował. Jeśli Consent Mode jest jeszcze w stanie domyślnym z odmową, opierasz się na blokadzie, a nie na własnej decyzji. Jeśli odwiedzający zgodził się przy wcześniejszej wizycie, tag działa i nikt tego nie widzi. W obu przypadkach wyzwalacz robi coś, czego twój projekt zgody nie zakładał.

Co zrobić w tym tygodniu

1. Wypisz każdy kontener, którym zarządzasz, i identyfikator tagu Google, jaki ładuje. Identyfikator G-, AW- lub DC- na snippecie gtm.js to układ nieobsługiwany i pierwszy w kolejce.
2. Otwórz listę wyzwalaczy i skup się na wyzwalaczach zdarzeń niestandardowych z włączonym dopasowaniem regex.
3. Przeczytaj każdy warunek dosłownie, tak jak czyta go maszyna. Kropka i gwiazdka dopasowują więcej, niż wyglądają.
4. Zapisz tag, który napędza szeroki wyzwalacz. Tagi konwersji i piksele idą na początek kolejki.
5. Uruchom sesję podglądu i potwierdź, które tagi odpalają się na zdarzeniu gtag.config. Dowód bije przypuszczenie.
6. Zawęź warunki, opublikuj wersję z opisem wyjaśniającym zmianę i przetestuj ponownie.
7. Tam, gdzie kontener ładuje identyfikator nie-GTM przez snippet gtm.js, zaplanuj przejście na wspierany układ.

To kolejne z serii wydań, która zmienia obsługę kontenerów bez pytania nikogo o edycję. Lipcowa zmiana, w której o tym, które tagi działają, decyduje identyfikator kontenera, a nie ścieżka wczytania, była tym samym typem. Zasady dla snippetu wczytującego się zaostrzają, a odczuwają to najpierw kontenery, które nigdy nie były do końca standardowe.

Sprawdź wyzwalacze w tym tygodniu. Wieloznaczność, która we wrześniu była nieszkodliwa, dziś nie jest.