Podsumowanie wersji w GTM pisane przez AI: co widzi, a czego nie

Od 17 września 2026 Google Tag Manager sam pisze nazwę i opis wersji. Klikasz Submit, a model czyta różnicę w workspace i wypełnia oba pola gotowym tekstem. Nota wydania opisuje to jednym zdaniem, a strona pomocy o publikowaniu wersji nadal o tym nie wspomina.

Dla zespołu, który publikuje codziennie, to wygoda. Firma, która pół roku później tłumaczy klientowi, skąd wzięła się nowa piksela, dostanie odpowiedź tylko na połowę pytania. Automat opisuje, co zmieniło się w kontenerze. Nie wie, po co.

Co mówi nota wydania

Cały komunikat to jedno zdanie: ekran Submit dostał podsumowanie wersji generowane przez AI, które podsumowuje zmiany w workspace i samo proponuje nazwę oraz opis wersji.

Praktycy opisali interfejs na podstawie własnych kont. W sekcji Submission Configuration pojawia się przełącznik Suggested version summary, w polu nazwy widać etykietę Generowanie, a przycisk Generate powtarza generowanie po kolejnej zmianie w workspace. Simo Ahava podał w swoim wpisie z serii GTM Tips, że funkcja jest włączona domyślnie w kontenerach.

Dokumentacja nie nadąża za wdrożeniem. Strona pomocy o publikowaniu, wersjach i zatwierdzeniach, sprawdzona 30 września, nie zawiera ani słowa o podsumowaniu. Na razie jedynym opisem zachowania jest nota wydania.

Ekran Submit, do którego to trafia

Funkcja wypełnia pole, które istniało od lat. Google podaje wzór: nazwa wersji GA page view tag - initial launch i opis Launch the Google Analytics pageview tag on example.com. Nazwa, czynność, zakres.

Wchodzisz do kontenera i klikasz Submit w prawym górnym rogu. Ekran Submit Changes pozwala opublikować kontener i zapisać wersję, więc zostaw zaznaczone Publish and Create Version. Przejrzyj sekcję Workspace Changes i sprawdź, czy konfiguracja wygląda tak, jak ma. Wpisz nazwę i opis wersji i kliknij Publish. Każda publikacja tworzy wersję, a samo tworzenie wersji wymaga uprawnienia Approve lub wyższego.

Menu More Actions przy elemencie pokazuje różnice między wersjami albo pozwala porzucić zmianę. Wersję bez publikowania zapiszesz przez Submit i Create Version, wcześniej zapisaną wypuścisz przez Versions, Action i Publish, a Actions oraz Set as Latest Version podmienia szkic na zawartość wybranej wersji.

Czego model nie wie

Podsumowanie powstaje z różnicy w konfiguracji. Model widzi dodany, usunięty albo zmieniony tag, nowy warunek w wyzwalaczu, zmienioną nazwę zmiennej.

Nie widzi powodu. Ta sama różnica może znaczyć dwie różne rzeczy: nieużywany tag dostawcy zniknął po zakończeniu umowy albo tag, który odpalał się przed zebraniem zgody, został usunięty po przeglądzie. Wpis w historii jest identyczny, a tylko jedna z tych historii należy do twojej dokumentacji.

To samo dotyczy zwykłych decyzji: czy zmiana jest testem, czy zostaje na stałe, którego zgłoszenia dotyczy, czy rusza bramkowanie zgód i kto ją zatwierdził. Nic z tego nie siedzi w konfiguracji workspace.

Niepełna lista to nie teoria

Simo Ahava przetestował funkcję na własnym kontenerze. Generator pominął fakt, że przed kliknięciem Submit wstrzymał 29 tagów. Reszta opisu była poprawna, więc wpis wyglądał wiarygodnie, mimo że nie opisywał najważniejszej części zmiany. Wniosek jest krótki: traktuj tekst jako punkt startowy i dopisuj to, co pominął.

Druga obserwacja mówi więcej o naturze narzędzia. Generator wybiera to, co uznaje za najistotniejsze, a wynik potrafi różnić się między uruchomieniami. Opis pewny siebie i niepełny jest gorszy od pustego pola, bo następna osoba czyta go i przestaje dopytywać.

Ryzyko: co jest faktem, a co opinią

GA4 Optimizer opisał funkcję jako włączoną opt-outowo: generowanie startuje od razu po kliknięciu Submit, bez ekranu akceptacji warunków i bez przełącznika na poziomie konta, którym dział IT mógłby wyłączyć to dla całej organizacji. Autorzy zauważają też, że Google nie opublikował oświadczenia o prywatności dotyczącego właśnie tej integracji.

To analiza dostawcy, nie komunikat Google, więc sprawdź zachowanie na własnym koncie, zanim powtórzysz to klientowi. Ma jednak znaczenie, bo konfiguracja kontenera zawiera listę dostawców, logikę zmiennych, konwencje nazw i identyfikatory pomiaru. Jeśli w firmie obowiązuje zasada o tym, co wolno wysyłać do zewnętrznych usług AI, ten przepływ zasługuje na decyzję.

Simo Ahava patrzy na to spokojniej: Google i tak ma wgląd w zawartość kontenera, więc uruchomienie modelu na tych samych zasobach nic nie zmienia. Osobna sprawa, że kontener webowy jest czytelny dla każdego, kto spojrzy w źródło strony. To pytanie o to, co w ogóle powinno być w kontenerze webowym, a nie o tę jedną funkcję.

RODO, UODO i ślad zmian

Zasada rozliczalności z art. 5 ust. 2 RODO wymaga, żebyś umiał wykazać zgodność, a nie tylko jej przestrzegać. Konfiguracja tagów decyduje, które skrypty się uruchamiają i czy zgoda jest sprawdzana przed startem.

Zapis informacji na urządzeniu użytkownika reguluje w Polsce art. 399 Prawa komunikacji elektronicznej, a standard zgody wyznacza RODO przez art. 400 PKE. Zmiana dotykająca bramkowania zgód albo dodająca dostawcę przetwarzającego dane osobowe nie jest porządkami. Wpisz jej wpływ na zgodę sam, bo automatyczne podsumowanie tego nie zrobi.

Dziennik zmian, który odpowie na pytanie

Traktuj tekst z modelu jako pierwszy szkic i dopisz pola, które niosą sens. Krótki szablon w polu opisu pokrywa prawie każdy przypadek:

• Typ zmiany: nowy tag, poprawka, usunięcie albo zmiana związana ze zgodami.
• Powód i źródło: kto poprosił i czego dotyczy, na przykład start kampanii albo zgłoszenie błędu.
• Wpływ na zgodę: czy zmienia się to, co odpala się przed zgodą, i czy dochodzi dostawca przetwarzający dane osobowe.
• Punkt powrotu: do której zapisanej wersji wrócić, jeśli coś pójdzie nie tak.
• Osoba zatwierdzająca: kto to odbił, jeśli w firmie działa zatwierdzanie.

Praktyka jest krótsza. Czytaj proponowany tekst przed publikacją i porównaj go z listą Workspace Changes. Przy zmianach dotyczących zgód i widocznych dla klienta pisz opis od zera. Ustal jedną politykę dla wszystkich klientów, żeby decyzji nie podejmował przypadkowy wydawca. Twórz wersję przed dużą zmianą. Przeglądaj historię publikacji raz w miesiącu, bo kolumna Published pokazuje, kiedy wersje były na produkcji i kto je wypuścił.

Zatwierdzenia, jeśli masz GTM 360

Zatwierdzenia to funkcja Google Tag Managera 360 z pakietu Google Marketing Platform i domykają większość luki opisanej wyżej. Użytkownicy z uprawnieniem Edit lub wyższym widzą opcję zgłoszenia prośby o zatwierdzenie, w której można wskazać osobę i dodać komentarz, a decyzję podejmuje każdy z uprawnieniem Approve lub Publish. Zakładka Approvals zbiera otwarte prośby, w tym prośby o publikację, zatwierdzenia External Account Links i tagi przysłane z Campaign Manager 360. Niebieskie kółko oznacza prośbę otwartą dla wszystkich, czerwone czeka na ciebie.

Bez 360 zostaje konwencja na piśmie: jedna osoba publikuje, opis idzie według szablonu, a prośba żyje w systemie zgłoszeń, którego już używacie.

Co zrobić w tym tygodniu

Otwórz ekran Submit na najbardziej zajętym kontenerze i poszukaj przełącznika. Zostaw go włączony, opublikuj coś drobnego i przeczytaj, co powstało. Oceń tekst wobec różnicy w konfiguracji, a nie wobec pustego pola.

Potem dopisz dwie rzeczy, których model nie dostarczy: powód i wpływ na zgodę. Nazwa i opis wersji to nie formalność. To jedno miejsce w kontenerze, w którym następny właściciel dowiaduje się, co miałeś na myśli.