GTM Template Status Page - jak sprawdzić status szablonu Google Tag Manager?
Większość z nas kojarzy Google Tag Managera przede wszystkim ze zbiorem tagów, triggerów, skomplikowanych zmiennych i żmudnym debugowaniem kolejnych wdrożeń. Tymczasem w obrębie Custom Templates ukrywa się jeszcze jedno miejsce o ogromnym potencjale diagnostycznym. Z jego istnienia powinien zdawać sobie sprawę każdy, kto na co dzień tworzy lub tylko utrzymuje autorskie szablony tagów. Mowa o Template Status Page, czyli ukrytej stronie statusu dla rozwiązań zgłaszanych do Google Tag Manager Community Template Gallery. Ta z pozoru mało widoczna funkcjonalność pozwala sprawnie zweryfikować, co dokładnie stało się z kolejnymi paczkami kodu pobieranymi z GitHuba i czy wewnętrzne mechanizmy Google nie natrafiły na ścianę podczas ich synchronizacji. Dokładny opis tego narzędzia znalazł się w sierpniowym wydaniu GTMTips autorstwa cenionego analityka Simo Ahavy.
Czym dokładnie jest strona statusu w GTM?
Społecznościowa galeria szablonów Google Tag Managera to znakomite miejsce do publikacji własnych, niestandardowych rozwiązań. Użytkownicy przechowują ich kod źródłowy w publicznych repozytoriach na GitHubie. W ten sposób powstają potężne narzędzia ułatwiające codzienną pracę, do których zaliczyć można:
w pełni spersonalizowane Custom Tag Templates,
zmienne Custom Variable Templates,
gotowe rozwiązania z kategorii Custom Client Template,
dedykowane szablony trybu Consent Mode,
moduły ułatwiające integrację z zewnętrznymi API.
Musisz jednak pamiętać o tym, że samo wypchnięcie paczki na GitHuba absolutnie nie gwarantuje jeszcze natychmiastowego pojawienia się aktualizacji w samej galerii GTM. Po drodze do gry wkracza wbudowany importer. Jego jedynym zadaniem jest nieustanne sprawdzanie, czy nowe rewizje kodu poprawnie spełniają wszystkie rygorystyczne wytyczne i mogą zostać udostępnione szerszej publiczności. Ukryta strona statusu wyświetla natomiast bardzo dokładną, techniczną historię całego tego procesu audytowania.
Gdzie szukać Template Status Page?
Dla zdecydowanej większości analityków i marketerów jest to miejsce kompletnie nieprzydatne w codziennej pracy. Aby w ogóle do niego dotrzeć, musisz podążać ścieżką dla zaawansowanych. Najpierw należy otworzyć katalog główny Google Tag Manager Community Template Gallery. Kolejny krok to znalezienie i otwarcie strony interesującego Cię rozwiązania. Finalnie pozostaje już tylko kliknięcie odnośnika o nazwie "Status", który znajduje się w dyskretnym, bocznym panelu. Oczom ukaże się wtedy szczegółowy raport informujący między innymi o aktualnej dostępności paczki, numerze najnowszej wersji oraz kompletnej historii commitów zebranych i obsłużonych przez bezlitosny importer Google. Co więcej, każdy wyświetlany wpis stanowi jednocześnie bezpośredni odnośnik do wylistowanego commita z GitHuba.
Znaczenie poszczególnych wpisów
Jeżeli zawodowo tworzysz zaawansowane szablony do GTM, Twój proces deweloperski wygląda zapewne tak: wprowadzasz niezbędną modyfikację w kodzie, realizujesz commit, wypychasz zmiany na publicznego GitHuba, w tym momencie włącza się zautomatyzowany importer, a poprawka ląduje w Community Template Gallery. Komplikacje lubią jednak pojawiać się na absolutnie każdym z tych etapów. Bardzo często twórcy zmagają się z sytuacją, w której na GitHubie wszystko wygląda wręcz podręcznikowo, tymczasem najnowsza wersja rozwiązania uparcie nie chce zaktualizować się w katalogu. Dzięki tej funkcji nie musisz biernie czekać i zastanawiać się, czy skrypty giganta zdążyły już pobrać nową zawartość repozytorium. Zamiast tego od razu wchodzisz na zakładkę statusu i błyskawicznie weryfikujesz, w jaki sposób maszyna zinterpretowała konkretną paczkę z poprawką. Oszczędzasz tym samym masę czasu na zgadywanie w ciemno.
Idealny scenariusz to komunikat "Success"
W najmniej skomplikowanym z wariantów system wyświetla radosne powiadomienie z hasłem "Success". Świadczy to o tym, że maszyna przetworzyła wgraną wersję prawidłowo i nie napotkała po drodze żadnych nieprzewidzianych trudności. Kiedy jednak procedura nie powiedzie się i nastąpi błąd, rzut oka na status page ujawnia zazwyczaj konkretną przyczynę zatrzymania publikacji. To absolutnie największa zaleta płynąca z korzystania z tego małego, ale potężnego narzędzia.
Jakie błędy najczęściej komunikuje GTM?
Lista potencjalnych przeszkód technicznych wstrzymujących bezproblemowy import jest długa. Zależnie od konkretnej wpadki, po stronie Google może pojawić się cała gama różnorodnych alertów. Simo Ahava zwraca uwagę na kilka powtarzających się komunikatów:
Problem z plikiem metadata.yaml: maszyna nie potrafiła znaleźć tego niezbędnego pliku lub napotkała krytyczne problemy podczas odczytywania jego struktury,
Problem z plikiem template.tpl: skrypt odpowiadający za indeksowanie nie odszukał odpowiedniego pliku z szablonem dla wskazanej wersji paczki,
Uchybienia w licencjonowaniu: system bardzo często zgłasza niepokojący komunikat o błędnej lub wręcz całkowicie nieważnej licencji ("Failed to update template because the license is invalid"),
Brak sekcji Terms of Service: bez jej obowiązkowej obecności w strukturze repozytorium system kategorycznie wstrzyma procedurę,
Problem z repozytorium na platformie GitHub: serwer odpowie komunikatem błędu, jeśli nie znajdzie docelowego repozytorium lub spotka się z odrzuceniem dostępu (kod 404),
Błędna składnia konfiguracji YAML: niewielka literówka w formacie "metadata.yaml" wystarczy, by całkowicie uniemożliwić prawidłowe obsłużenie szablonu,
Brak pliku LICENSE: fizyczny brak wymaganej prawem dokumentacji licencyjnej wyklucza zatwierdzenie,
Niezrozumiały format pliku TPL: kiedy parser napotka nielogiczną treść pliku "template.tpl", proces aktualizacji wyłoży się w mgnieniu oka. Złota zasada wspomniana przez Ahavę sugeruje w takiej sytuacji wyczyszczenie błędów poprzez prewencyjny ponowny eksport z poziomu zintegrowanego Template Editora.
Kiedy autorskie narzędzie niespodziewanie znika z sieci
Jednym z najbardziej dolegliwych konsekwencji opisanych wyżej błędów może być bezpowrotne wyrzucenie udostępnionego tagu z ogólnodostępnego katalogu. Zakończenie pracy automatycznego importera ze wskaźnikiem niepowodzenia to nie tylko wstrzymanie wdrożenia zaplanowanej na dany dzień aktualizacji. W ściśle zdefiniowanych sytuacjach krytyczne luki przy procedurze integracji skutkują wręcz permanentnym ukryciem wspaniale działającego narzędzia. Template Status Page jest wówczas absolutnie kluczowe do tego, by metodycznie krok po kroku prześledzić sekwencję wydawanych commitów i w ten sposób precyzyjnie namierzyć moment, w którym wprowadzono feralny, psujący strukturę element kodu. Dzięki temu masz zdecydowanie większą wiedzę analityczną, niż gdyby pozostawiono Cię z komunikatem: "GTM przestał pokazywać moją łatkę i nie wiem dlaczego".
Nie każda wskazówka jest od razu czytelna
Korzystając ze strony statusów, natrafisz też na pewne ograniczenia. Użytkownicy zauważają, że nie każdy wypluwany przez system Google alert w sposób oczywisty odpowiada temu, co faktycznie dolega paczce. Może zdarzyć się na przykład sytuacja wywołana fałszywym raportowaniem braków krytycznych plików, w sytuacji gdy programista doskonale wie, iż dany plik znajduje się we właściwej strukturze wypchniętego commita. Z tego względu do Status Page najlepiej podchodzić jak do wyśmienitego radaru do poszukiwania usterek, a nie magicznej kuli gotowej natychmiast wręczyć odpowiedź sugerującą skasowanie dziesiątego wiersza kodu. Zdarza się, że weryfikacja błędu wymaga cierpliwego przeklikania historii w panelu GitHuba i bezpośredniego odpytania stanu zapisanego w danym momencie działania repozytorium.
Historia pracy nad aplikacją w jednym miejscu
Cudowną zaletą ukrytego widoku jest możliwość pełnego prześwietlenia drogi, jaką przebyła aplikacja w starciu z bezlitosnym importerem. Taki dziennik systemowy to niesamowite narzędzie w przypadku pracy w wielu rewizjach. Przykładowa ścieżka:
commit A → Success
commit B → Success
commit C → Error
commit D → Error Dzięki tak zapisanym logom deweloper ma stuprocentową pewność, co do dokładnego momentu zepsucia repozytorium. Co niezwykle przydatne z perspektywy szybkiej edycji, każde unikalne hashowanie jest jednocześnie bezpośrednim hiperłączem odsyłającym na adres problematycznego zapisu na stronie zewnętrznego repozytorium.
Odpowiedź na inne pytania niż sądzisz
Status Page nie weryfikuje samego faktu, czy aplikacja uruchamia się bez spięć u ostatecznego klienta. Ten mechanizm diagnozuje natomiast zagwozdkę pod tytułem: "W jaki właściwie sposób Google poradziło sobie z importem mojej najnowszej modyfikacji?". Ta różnica decyduje o wartości narzędzia. Może być przecież tak, że na GitHubie kod zdaje się lśnić doskonałością, podczas gdy GTM Gallery bez przerwy krzyczy o zaistniałym potężnym problemie. Tylko i wyłącznie skonfrontowanie wyników z obu platform jest w stanie zagwarantować pełen obraz usterki.
Must-have dla pasjonatów Custom Templates
Z perspektywy rynkowego wyjadacza i przeciętnego analityka ten moduł wydaje się niemalże całkowicie zbyteczny. Wszelkie zasady przestają obowiązywać, kiedy odwrócimy sytuację i zaczniemy wdrażać na rynek swoje osobiste patenty. Znajomość położenia tego narzędzia powinna wejść Ci w krew przy okazjach takich jak:
debiut świeżego szablonu pod szyldem Custom Template,
wydawanie obiecanej dawno aktualizacji łatającej luki,
moment, w którym z niezrozumiałych powodów Twój dodatek nagle się blokuje,
chwilach paniki, gdy zatwierdzone zmiany przestały aktualizować się u społeczności w Galerii,
sytuacji zniknięcia rozszerzenia z Community Template Gallery,
awaryjnym poszukiwaniu winnego błędu wskazanego w logu przez mechanizm importu,
potężnych operacjach przenoszenia całości do całkowicie nowego repozytorium,
a wreszcie podczas wprowadzania niewielkich kosmetycznych modyfikacji w obszarach config, czyli edycji plików "metadata.yaml", "template.tpl" czy standardowej "LICENSE".
Znajomość ukrytej zakładki pozwala zdecydowanie zmniejszyć stres w każdej z wyszczególnionych wyżej, nieprzyjemnych dla każdego twórcy, codziennych sytuacji.
A co jeśli błąd uderzy w Consent Mode?
Dla ekspertów wyspecjalizowanych w szeroko rozumianym bezpieczeństwie analitycznym i ochronie poufności cyfrowej ten zakamarek interfejsu niesie szczególny ładunek informacyjny. Ekosystem wybudowany wokół Google Tag Managera bardzo polega dziś na zgrabnych, dedykowanych rozwiązaniach odpowiedzialnych za prawidłowe wspieranie wbudowanego Consent Mode. Choćby publiczna biblioteka skryptów prowadzona przez wspominanego eksperta Simo Ahavę przechowuje wyodrębniony specjalnie w tym celu dodatek zatytułowany „Consent Mode (Google tags)”. Gdy Twoje zaplecze technologiczne polega na bezawaryjnej pracy autorskich rozwiązań odpowiedzialnych w tle za:
Consent Mode,
generowane przez przeglądarki sygnały zgody,
szeroko pojętą, stabilną analitykę,
mechanizmy emisyjne sieci reklamowych,
stabilne tagowanie zachowań użytkownika.
Bądź wyczulony na fakt, że niezawodność udostępnianego szablonu stanowi zaledwie jedno, drobne kółko zębate puszczającej w ruch maszynę rynkową. Gdy repozytorium zaniecha wysyłania poprawek, albo chmura Google przestanie autoryzować napływające porcje ulepszeń, poskutkuje to groźnym dla wiarygodności fiaskiem wielopoziomowych, rozbudowanych integracji na setkach komercyjnych serwisów internetowych.
Nie porzucaj tradycyjnego trybu testowania
Zadziwiająco łatwo wpaść w pułapkę zgubnego przeświadczenia o pełnej sprawności aplikacji w oparciu o zielone światło zapalone przez system. Sukces w dzienniku zdarzeń szablonu nie jest absolutnie żadnym argumentem poświadczającym bezbłędne ułożenie modułów programistycznych w kodzie źródłowym klienta docelowego. Panel statusu potwierdza zaledwie sukces w procedurze wtłaczania plików z repozytorium do katalogu publicznego. Nawet najdroższa technologia nie przeprowadzi za developera wyrafinowanego audytu działania konkretnego przypadku. Nawet przy zielonych wskaźnikach nie ustępuj z dalszego rzetelnego, stacjonarnego testowania zachowań takich funkcjonalności jak:
konfiguracja używanych wyzwalaczy (triggers),
wartości przyjmowanych oraz eksportowanych zmiennych środowiskowych,
stan uruchamianych poszczególnych tagów operacyjnych,
mechanizmy wymuszane protokołami Consent Mode,
sprawność decyzyjnego drzewa podczas analizowania kolejności startu zadań (priorities),
objętość i zawartość realizowanych żądań po stronie sieci,
poprawność merytoryczna przechwytywanych na serwerze i dalej przekazywanych metadanych reklamowych,
faktyczne zachowanie skryptów z poszanowaniem podjętych przez klienta zgód,
symulacja działania panelu w momencie celowej, natychmiastowej odmowy wszystkich zgód informacyjnych na stronie,
i wreszcie prawidłowość zapisu procesu przy wycofywaniu zezwoleń ex-post w panelu CMP. Znaczenie regularnych weryfikacji manualnych pod kątem prawa jest szalenie istotne dla spokoju ducha u osób koordynujących na witrynie systemy dbające o utrzymanie intymnej sfery dla internautów.
Gotowy proces działania
Skomplikowany mechanizm można łatwo zaprząc do pomocy posługując się schematyczną listą wdrożeniową. Krok 1: Weryfikacja po stronie GitHuba. Zbadaj czy finalna rewizja poprawki figuruje już po stronie otwartego profilu w witrynie GitHub. Krok 2: Konfrontacja znakowania hash. Dokonaj porównania, by potwierdzić stuprocentową zbieżność między zapisanym w repozytorium systemowym logiem GitHuba a sygnaturą obsłużoną i przetworzoną po stronie importera należącego do Google. Krok 3: Analiza statusu operacji. Sprawdź jak zakomunikowano rezultat. Zadowoli Cię krzepiący wskaźnik wpisu Success, czy może zmusi do działania widniejący na krwisto Error. Krok 4: Skrupulatna lektura błędu. Gdy zapali się alarm, prześledź i określ, którego podzespołu aplikacji dogłębnie dotyka anomalia, uwzględniając możliwości takie jak uchybienia w plikach źródłowych, zignorowanie pliku z prawami do dystrybucji, złamanie składni kodu dla zapisanych wartości, awarię dostępu u gospodarza pliku, niezastosowanie rygorystycznych zasad narzuconych na poprawną konfigurację kodu źródłowego pliku, czy trywialne pomyłki z nadawaniem złych wariantów numeracyjnych edycji. Krok 5: Analiza porównawcza. Gdy usterka w repozytorium nasila się natychmiast po implementacji niewielkiej kosmetycznej poprawki, wróć o poziom w dół i wykonaj zestawienie pliku awaryjnego ze wskaźnikami poprzedniej, doskonale działającej rewizji. Krok 6: Wydanie ratunkowej poprawki. Gdy wprowadzisz lekarstwo ucinające problem w zarodku, dokonaj odświeżenia statusu importera i zweryfikuj czy zielony znacznik przywrócono we wskazanym rekordzie. Stosowanie powtarzalnej rutyny to jedyne logiczne rozwiązanie wykluczające męczącą i frustrującą utratę czasu na diagnozowanie z pamięci poszczególnych zmiennych "zupełnie na wyczucie".
Czego jeszcze domaga się społeczność?
Fin uważa, że udostępniony użytkownikom interfejs zdecydowanie nie wykorzystuje pełnego potencjału narzucanego przez potężne wdrożenia na komercyjnym rynku i sygnalizuje pilną chęć wdrożenia szeregu poprawek. Społeczność developerów oczekuje rychłego implementowania tak użytecznych poprawek systemowych jak:
bezwzględne zapewnienie rzetelnej, wyczerpującej i bardzo dogłębnej specyfikacji wykazującej znaczenie ustandaryzowanych alertów dla raportowanych operacji błędnych,
bezbłędne przypisywanie dokładnych etykiet czasowych zwanych potocznie znacznikami czasu dla wszystkich wyświetlanych indeksów,
publikacji wytycznych obrazujących w szczegółowy sposób model architektury oprogramowania importera operacyjnego,
wyjaśnienia przyczyn incydentalnego mnożenia w bazie logów tych samych wskaźników rewizji,
uzbrojenia całkowicie nowo zarejestrowanych podmiotów na łamach katalogu galerii we wskazania opisane szczegółowym kodem informacyjnym. Wskazana lista roszczeń to dowód na pożądaną ewolucję systemu i ogromny potencjał przydatnego narzędzia diagnostycznego z punktu widzenia fachowców, którzy wymagają od narzędzi czystości, logiki działania i perfekcyjnej niezawodności w interpretowaniu wypluwanego komunikatu.