Debugowanie server-side GTM: Preview, logi i najczęstsze błędy

Debugowanie server-side GTM to proces diagnozowania, dlaczego dane pomiarowe nie docierają do platform reklamowych lub docierają w błędnej postaci - z wykorzystaniem trybu Preview kontenera serwerowego, logów środowiska hostingowego (Google Cloud Run lub stape.io) oraz narzędzi po stronie przeglądarki, takich jak Tag Assistant. W przeciwieństwie do klasycznego GTM po stronie przeglądarki, w server-side GTM (sGTM) analizujesz pary żądanie-odpowiedź HTTP, a nie zdarzenia w warstwie dataLayer, dlatego typowe błędy dotyczą transportu danych, przechwytywania żądania przez klienta (claim), nagłówków CORS oraz przekazywania zgody z Consent Mode.

Kontener serwerowy potrafi milczeć w wyjątkowo mylący sposób. Publikujesz wersję, konfiguracja wygląda poprawnie, a w Google Ads konwersje ani drgną. Przez lata audytowania kont Google Ads nauczyłem się, że w takiej sytuacji problem prawie nigdy nie leży tam, gdzie go szukasz na pierwszy rzut oka. Debugowanie po stronie serwera rządzi się własnymi prawami - nie ma tu podglądu dataLayer w konsoli przeglądarki, jest za to strumień żądań HTTP, który trzeba umieć odczytać. Ten artykuł to praktyczny warsztat: pokażę Ci, gdzie patrzeć, w jakiej kolejności i jak rozpoznać cztery błędy odpowiedzialne za większość awarii pomiaru.

Skrót artykułu

Co warto wiedzieć

Wnioski, które decydują o tym, czy kontener serwerowy realnie dowozi konwersje.

• Brak transport_url w tagu GA4 zatrzymuje zdarzenia po stronie przeglądarki

  Tag GA4 w kontenerze webowym wysyła dane prosto do Google, dopóki nie wskażesz mu subdomeny first-party w polu transport_url. Kontener serwerowy nie zobaczy wtedy żadnego żądania, a diagnozę zaczynasz w przeglądarce, nie w GTM.

• Żądanie bez przechwycenia przez klienta (claim) ginie mimo poprawnego transportu

  Claim to zgłoszenie się klienta w kontenerze serwerowym do obsługi przychodzącego żądania. Gdy przy żądaniu brakuje sekcji Claimed, żaden aktywny klient nie pasuje do jego ścieżki - to problem konfiguracji klientów, nie tagów.

• Status fired w zakładce Tags nie potwierdza, że platforma przyjęła zdarzenie

  Zakładka Tags mówi tylko tyle, że warunki wyzwalacza zostały spełnione. Potwierdzeniem jest kod 200 w sekcji Outgoing HTTP requests, a odpowiedź 400 lub 403 oznacza odrzucone dane albo brak uprawnień po stronie platformy.

• Tryb Preview pokazuje jedno żądanie, a awarie ruchu widać dopiero w logach hostingu

  Logs Explorer w Cloud Run filtruje żądania po kodzie HTTP, a stape.io w swoim cenniku daje uproszczony panel ruchu w planach od około 20 USD miesięcznie, z darmowym limitem do około 10 tys. żądań (stan na 2026 rok).

• Transport, claim, CORS i brak zgody odpowiadają za większość utraconych konwersji w sGTM

  Spośród 18 wdrożeń kontenera serwerowego, które audytowałem w ostatnim roku, w 11 co najmniej jeden z tych czterech błędów realnie gubił konwersje. Błąd CORS zostawia ślad wyłącznie w konsoli przeglądarki, więc w interfejsie GTM wygląda na brak problemu.

Na czym polega debugowanie kontenera serwerowego?

Debugowanie kontenera serwerowego polega na śledzeniu drogi pojedynczego zdarzenia od przeglądarki, przez subdomenę first-party, do klienta w kontenerze i dalej do tagów wysyłających dane na platformy. Analizujesz żądania i odpowiedzi HTTP, a nie zmienne w dataLayer. To fundamentalna różnica względem klasycznego GTM. To także moment, w którym narzędzia marketingu internetowego przestają być wymienne - do warstwy serwerowej potrzebujesz innego zestawu niż do debugowania w przeglądarce.

Cała ta architektura opiera się na server-side tagging - jeśli dopiero poznajesz temat, warto zacząć od pillara, a tu skupić się na diagnostyce. W praktyce debugowanie sprowadza się do trzech pytań zadawanych po kolei:

• Czy żądanie w ogóle dotarło do serwera? Odpowiada za to transport - jeśli nie, dane nie opuściły przeglądarki.
• Czy któryś klient je przechwycił? To kwestia claim - żądanie może dotrzeć, ale zostać zignorowane.
• Czy tag odpalił i z jakim skutkiem? Tu wchodzą zgoda (Consent Mode), mapowanie parametrów i odpowiedź platformy.

W mojej codziennej praktyce widzę, że osoby przenoszące się z client-side na server-side popełniają jeden błąd metodyczny: szukają problemu na końcu łańcucha (tag), zamiast na początku (transport). Uważam, że pierwszym miejscem, do którego powinieneś zajrzeć, jest zakładka Requests w Preview - nie logi i nie konfiguracja tagu. Kolejność zaglądania w warstwy jest tu istotna, bo analityka internetowa diagnozuje transport danych osobno od ich interpretacji.

Jak uruchomić tryb Preview w server-side GTM?

Tryb Preview w kontenerze serwerowym uruchamiasz przyciskiem „Podgląd” w interfejsie GTM dla przestrzeni roboczej kontenera Server. Otwiera się osobne okno debugera, które nasłuchuje żądań przychodzących na Twój kontener. Aby zobaczyć ruch, musisz wygenerować zdarzenie z witryny połączonej z tym kontenerem. Sam mechanizm nie zależy od platformy, ale server-side tagging PrestaShop wymaga własnego modułu, bo sklep nie wysyła zdarzeń tak jak zwykła witryna.

1. Wejdź w kontener Server w GTM i kliknij „Podgląd” w prawym górnym rogu.
2. Skopiuj adres debugera - kontener serwerowy dopisuje do żądań parametr, po którym rozpoznaje sesję debugowania.
3. Otwórz witrynę w tej samej przeglądarce i wykonaj akcję (np. zakup testowy lub przejście na stronę z tagiem).
4. Wróć do okna Preview - na liście po lewej pojawią się kolejne żądania oznaczone czasem i typem.

Jeśli po wykonaniu akcji lista żądań pozostaje pusta, nie zaglądaj jeszcze do tagów. To sygnał, że zdarzenie nie dociera do kontenera - a to zupełnie inna klasa problemu, którą rozłożę na czynniki w dalszej części.

TRYB PREVIEW

Co widzisz w trybie Preview kontenera serwerowego

Preview pokazuje pojedyncze żądanie HTTP: co przyszło do serwera, który klient je przechwycił i jakie tagi odpaliły.

Request #4 - POST /g/collect

Przychodzące żądanieGA4 Client - przechwyconeevent: purchase, value: 249.00, currency: PLN

Claimed by (przechwycone przez):

GA4 Clientstatus: claimed

Tag: Google Adsstatus: fired

Żądanie bez transportuBrak transport_urlŻĄDANIE NIE DOTARŁO DO SERWERA

Zakładka Requests

Lista wszystkich żądań, które dotarły do kontenera. Jeśli tu pusto, problem jest po stronie transportu, nie tagów.

Zakładka Tags i Console

Pokazuje, które tagi odpaliły dla wybranego żądania i jakie komunikaty zwrócił serwer.

Jak czytać żądania i odpowiedzi w trybie Preview?

Żądanie w trybie Preview czytasz od góry łańcucha: najpierw sprawdzasz, czy pojawiło się na liście, potem czy sekcja „Claimed” wskazuje klienta, a na końcu które tagi odpaliły i z jakim kodem odpowiedzi. Każde żądanie ma cztery zakładki: Message, Console, Tags i Outgoing HTTP requests.

Najwięcej informacji daje zestawienie zakładki Tags (co odpaliło) z zakładką Outgoing HTTP requests (co realnie wyszło z serwera na platformę). To tu wychodzą sytuacje, w których tag „odpalił”, ale Google Ads odrzucił żądanie z kodem 400. W zakładce Console znajdziesz komunikaty błędów zwrócone przez sam kontener - często najkrótsza droga do przyczyny.

• Message: Surowe parametry przychodzące - sprawdzasz tu nazwę zdarzenia, wartość, walutę i identyfikatory.
• Console: Komunikaty i ostrzeżenia serwera - pierwsze miejsce, gdzie zobaczysz błąd konfiguracji.
• Tags: Które tagi odpaliły, które pominięto i dlaczego (np. warunek wyzwalacza niespełniony).
• Outgoing HTTP requests: Realne żądania wychodzące na platformy wraz z kodem odpowiedzi (200, 400, 403).

Gdzie znaleźć logi kontenera: Cloud Run czy stape.io?

Logi kontenera serwerowego znajdziesz w środowisku, na którym go hostujesz: dla Google Cloud jest to Logs Explorer w usłudze Cloud Run, dla stape.io - wbudowany panel podglądu ruchu w ustawieniach kontenera. Logi uzupełniają Preview: łapią błędy, które pojawiają się poza Twoją sesją debugowania oraz awarie infrastruktury.

Preview jest świetny do jednego żądania na żywo, ale nie pokaże Ci, że dwie godziny temu 3% żądań kończyło się kodem 503. Do tego służą logi. W Google Cloud Run filtrujesz je po kodzie odpowiedzi i ścieżce, na stape.io masz uproszczony widok z liczbą żądań i statusami HTTP.

• Google Cloud Run (Logs Explorer): Pełna kontrola, filtrowanie po severity i kodzie HTTP, korelacja z metrykami instancji. Wymaga dostępu do projektu Google Cloud.
• stape.io (panel logów): Prostszy podgląd ruchu i statusów bez wchodzenia w konsolę Google Cloud - wystarczający dla większości wdrożeń bez własnego DevOps.
• Własny serwer/VPS: Logi zależne od konfiguracji (np. logi kontenera Docker) - najwięcej pracy, ale też najwięcej kontroli.

Koszt hostingu wpływa na to, jak głęboko sięgniesz w logi. stape.io zaczyna się od ok. 20 USD/mies. (z planem darmowym do ok. 10 tys. żądań/mies.), a Google Cloud w wariancie Cloud Run to zwykle od ok. 90-120 USD/mies. przy realnym ruchu - w zamian dostajesz pełną maszynę logowania. Jeśli chcesz sprawdzić, które rozwiązanie pasuje do skali Twojego konta, to jeden z pierwszych punktów, które analizuję podczas audytu wdrożenia.

Jakich narzędzi użyć do diagnostyki po obu stronach?

Do pełnej diagnostyki potrzebujesz narzędzi po obu stronach transportu: po stronie przeglądarki (czy zdarzenie wyszło) i po stronie serwera (czy zostało przyjęte i przetworzone). Poleganie tylko na Preview to najczęstsza luka metodyczna, jaką widzę w audytach.

Tag Assistant sprawdza warstwę webową - potwierdza, że tag w kontenerze klienta wysłał żądanie na Twoją subdomenę. GA4 DebugView weryfikuje odbiór po stronie GA4. Konsola przeglądarki i zakładka Network wychwytują błędy CORS oraz kody 4xx/5xx, których nie zobaczysz w samym GTM.

NARZĘDZIA DIAGNOSTYCZNE

Sześć narzędzi do debugowania kontenera serwerowego

Każde odpowiada za inny odcinek drogi zdarzenia - od przeglądarki po odpowiedź platformy.

Tryb Preview sGTM

Podgląd żądań, klientów i tagów w czasie rzeczywistym - narzędzie pierwszego wyboru.

GA4 DebugView

Potwierdza, że zdarzenia docierają do GA4 po stronie serwera.

Logi Cloud Run

Szczegółowe logi żądań i błędów dla kontenera na Google Cloud.

Panel logów stape.io

Podgląd ruchu i statusów HTTP dla kontenera hostowanego na stape.

Tag Assistant

Diagnostyka po stronie przeglądarki - czy tag web wysyła żądanie do serwera.

Konsola i Network

Wychwytywanie błędów CORS, kodów 4xx/5xx i zablokowanych żądań.

Jakie są najczęstsze błędy w server-side GTM?

Cztery błędy odpowiadają za zdecydowaną większość awarii pomiaru w kontenerze serwerowym: brak transportu, zły claim, błąd CORS oraz zablokowanie tagu przez brak zgody. Każdy ma charakterystyczny objaw, po którym rozpoznasz go w kilkanaście sekund, jeśli wiesz, gdzie patrzeć.

Spośród 18 wdrożeń kontenera serwerowego, które audytowałem w ostatnim roku, w 11 przynajmniej jeden z tych czterech błędów odpowiadał za realną utratę danych konwersji. Jestem przekonany, że większość rzekomych „błędów sGTM” to w rzeczywistości brak transportu - najbardziej banalna z możliwych przyczyn, a jednocześnie najczęstsza.

KATALOG BŁĘDÓW

Cztery najczęstsze błędy i pierwszy krok diagnozy

Kliknij każdy błąd, żeby zobaczyć objaw, przyczynę i pierwszy ruch.

1Brak transportu - żądania nie docierają do serwera

Objaw: zakładka Requests w Preview jest pusta, a GA4 Realtime milczy. Przyczyna: nie ustawiono transport_url w tagu konfiguracyjnym GA4 albo adres subdomeny first-party jest błędny. Pierwszy ruch: sprawdź, czy subdomena w ogóle odpowiada i czy w tagu web wskazano właściwy transport.

2Zły claim - żądanie dociera, ale klient go nie przechwytuje

Objaw: żądanie widoczne w Requests, ale bez sekcji „Claimed”. Przyczyna: brak aktywnego klienta pasującego do ścieżki żądania (np. wyłączony klient GA4) lub konflikt priorytetów klientów. Pierwszy ruch: aktywuj właściwy klient i sprawdź, czy ścieżka żądania odpowiada jego konfiguracji.

3Błąd CORS - przeglądarka blokuje odpowiedź

Objaw: w konsoli przeglądarki komunikat o zablokowanym żądaniu cross-origin. Przyczyna: kontener stoi na obcej domenie (third-party) zamiast na subdomenie first-party tej samej witryny. Pierwszy ruch: przenieś transport na subdomenę Twojej domeny, by żądanie było first-party.

4Brak zgody - tag nie odpala mimo poprawnego żądania

Objaw: żądanie przechwycone, ale tag pomija wysyłkę. Przyczyna: Consent Mode wstrzymuje tag przy braku zgody na pomiar. Pierwszy ruch: zweryfikuj, czy sygnały zgody z CMP faktycznie docierają do serwera - to zachowanie zgodne z RODO, nie usterka.

Dlaczego dane nie docierają do kontenera serwerowego?

Dane nie docierają do kontenera serwerowego prawie zawsze z powodu transportu: przeglądarka nie wie, gdzie wysłać zdarzenie, albo wysyła je pod adres, który nie odpowiada. To błąd numer jeden i jednocześnie ten, który najłatwiej pomylić z awarią tagów.

W kontenerze webowym tag GA4 musi mieć ustawiony transport_url wskazujący Twoją subdomenę first-party. Jeśli tego pola brak, dane lecą prosto do Google, a Twój kontener serwerowy w ogóle ich nie widzi - stąd pusta zakładka Requests. Diagnozę prowadź w tej kolejności:

• Sprawdź transport_url w tagu web: Czy w kontenerze klienta ustawiono adres serwera i czy nie ma literówki w subdomenie.
• Zweryfikuj DNS i SSL subdomeny: Rekord A/AAAA lub CNAME musi wskazywać serwer, a certyfikat SSL być ważny - inaczej przeglądarka zerwie połączenie.
• Potwierdź w Tag Assistant: Czy tag web realnie wysyła żądanie na subdomenę, a nie bezpośrednio do Google.
• Zajrzyj do Network w przeglądarce: Żądanie do subdomeny powinno mieć kod 200 - kod 4xx/5xx lub brak żądania wskazują źródło problemu.

Jak diagnozować błędy claim, CORS i zgody?

Błędy claim, CORS i zgody diagnozujesz w trzech różnych miejscach: claim w zakładce żądania w Preview, CORS w konsoli przeglądarki, a zgodę w sygnałach Consent Mode przekazywanych do serwera. Łączy je to, że żądanie technicznie dotarło - problem jest dalej w łańcuchu.

Zły claim rozpoznasz, gdy żądanie jest na liście, ale nie ma przy nim klienta - żaden klient nie zgłosił się do jego obsługi. Błąd CORS zobaczysz wyłącznie w konsoli przeglądarki, nie w GTM, bo to przeglądarka blokuje odpowiedź serwera z innej domeny. Brak zgody to sytuacja, w której żądanie jest przechwycone, ale tag świadomie nie wysyła danych, bo Consent Mode nie otrzymał sygnału zezwalającego na pomiar.

Ta ostatnia sytuacja bywa myląca, bo wygląda jak błąd, a jest poprawnym zachowaniem z perspektywy RODO. Server-side tagging daje Ci kontrolę nad tym, co opuszcza serwer, ale nie zwalnia z obowiązku uzyskania zgody - filtrowanie danych i respektowanie Consent Mode to element zgodności, nie usterka do „naprawienia”. Jeśli rozpoznajesz w swoich kampaniach wzorzec znikających konwersji przy poprawnej konfiguracji, to dokładnie ten typ problemu, który rozkładam na części podczas audytu pomiaru.

Jaki proces debugowania stosować krok po kroku?

Skuteczny proces debugowania idzie od początku łańcucha do końca: transport, potem claim, potem tag i zgoda, na końcu odpowiedź platformy. Trzymanie tej kolejności oszczędza godziny - większość osób traci czas, bo zaczyna od środka lub od końca.

Poniższa sekwencja to workflow, który stosuję przy każdym audycie wdrożenia. Pięć kroków, zawsze w tej samej kolejności:

1. Otwórz Preview i wygeneruj zdarzenie - jeśli Requests puste, zatrzymaj się na transporcie.
2. Sprawdź sekcję Claimed - brak klienta to problem konfiguracji klientów, nie tagów.
3. Przejrzyj zakładkę Tags - które tagi odpaliły, a które pominięto i dlaczego (wyzwalacz, zgoda).
4. Zweryfikuj Outgoing HTTP requests - kod 200 potwierdza przyjęcie, 400/403 wskazuje błąd danych lub uprawnień.
5. Skonfrontuj z logami i konsolą - Cloud Run/stape dla awarii, konsola przeglądarki dla CORS.

Ten sam schemat porządkuje objawy widoczne w danych. Poniższa mapa łączy to, co widzisz w raportach, ze statusem kontenera - dzięki temu wiesz, gdzie zacząć, zanim jeszcze otworzysz Preview.

SZYBKA DIAGNOZA OBJAWÓW

Objaw w danych a status kontenera serwerowego

Zielony - działa, żółty - wymaga uwagi, czerwony - dane nie płyną.

Requests pełne, tagi ze statusem fired

Kontener działa - dane płyną do platform.

GA4 DebugView pokazuje zdarzenia

Transport i klient GA4 działają poprawnie.

Dane docierają, ale parametry niekompletne

Sprawdź mapowanie zmiennych i wzbogacanie zdarzeń.

Konwersje z widocznym opóźnieniem

Możliwe modelowanie lub kolejkowanie - monitoruj 24-48h.

Zakładka Requests pusta

Brak transportu - dane nie opuszczają przeglądarki.

Żądanie bez sekcji Claimed

Zły claim - żaden klient nie przechwytuje żądania.

Podsumowanie

Debugowanie server-side GTM nie jest sztuką magiczną - jest procesem z ustaloną kolejnością. Przestań traktować kontener serwerowy jak czarną skrzynkę, w której „coś nie działa”. Zacznij czytać go jak łańcuch: transport, claim, tag, zgoda, odpowiedź platformy. Kiedy raz przyjmiesz tę optykę, większość awarii przestaje być zagadką, a staje się kwestią sprawdzenia właściwej zakładki.

Z mojego doświadczenia jako specjalisty Google Ads wynika, że najdroższe błędy to te ciche - kontener wygląda na sprawny, a połowa konwersji nigdy nie dociera do platformy. Dlatego debugowanie to nie czynność jednorazowa po wdrożeniu, lecz nawyk: regularny rzut oka na Requests, DebugView i logi. Jeśli podejrzewasz, że Twój kontener gubi dane mimo poprawnej konfiguracji, potraktuj to jako sygnał do audytu pomiaru - im wcześniej wyłapiesz cichy błąd, tym mniej danych stracisz po drodze.

Na czym opieram te wnioski

Źródła i dokumentacja

Debugowanie kontenera serwerowego opieram na dokumentacji, która opisuje realne zachowanie narzędzi: monitoring hostingu, komunikaty CORS w przeglądarce i weryfikację wysyłki po stronie klienta. Poniższe cztery źródła stoją za konkretnymi sekcjami tego artykułu.

developers.google.com

Monitoring infrastruktury kontenera serwerowego

Google opisuje tu raporty Cloud Run i zapytania Cloud Logging (severity ERROR, httpRequest.status >= 400, logName stdout oraz logs/requests) i tłumaczy, że kod 4XX zwykle oznacza żądanie, którego żaden klient nie przechwycił, a 5XX awarię po stronie usługi. Techniczna podstawa sekcji o logach kontenera w Cloud Run i na stape.io oraz potwierdzenie diagnozy złego claim.

Google for Developers Otwórz

developer.mozilla.org

Błędy CORS i gdzie je zobaczyć

MDN wylicza 15 nazwanych przyczyn blokady cross-origin i wprost zaznacza, że szczegóły błędu nie są dostępne dla kodu JavaScript - jedynym miejscem, gdzie je odczytasz, jest konsola przeglądarki. Punkt wyjścia do sekcji o diagnozie błędów claim, CORS i zgody, która tłumaczy, dlaczego CORS nie zostawia śladu w interfejsie GTM.

MDN Web Docs Otwórz

support.google.com

Diagnostyka tagów w Tag Assistant

Pomoc Google opisuje, że Tag Assistant dopina do adresu parametr debugowania _dbg, pokazuje listę tagów na stronie, ich trafienia, aktualizacje warstwy danych i błędy wdrożenia, a sesję przekazuje dalej do GA4 DebugView. Zaplecze sekcji o narzędziach diagnostycznych po obu stronach transportu, w części dotyczącej warstwy przeglądarki.

Pomoc Google Otwórz

searchenginejournal.com

Pięć sposobów sprawdzenia pomiaru

Autor pokazuje, jak potwierdzić wysyłkę danych: zakładka Network w narzędziach Chrome z filtrem collect lub gtm, raport w czasie rzeczywistym i tryb Preview, przy czym zwraca uwagę, że zduplikowany kod pomiarowy dotyczy mniej więcej połowy nowych wdrożeń, które audytował. Wsparcie dla sekcji o tym, dlaczego dane nie docierają do kontenera - zwłaszcza dla kroku z podglądem żądania w przeglądarce.

Search Engine Journal Otwórz

Najczęściej zadawane pytania

Pytania i odpowiedzi (FAQ)

Debugowanie server-side GTM: punkt startu, pusta zakładka Requests i różnice wobec klasycznego GTM.

01Od czego zacząć debugowanie server-side GTM?

Zacznij od trybu Preview i zakładki Requests. Wygeneruj zdarzenie z witryny i sprawdź, czy żądanie w ogóle dotarło do kontenera. Jeśli lista jest pusta, problemem jest transport, a nie tagi - i dalszą diagnozę prowadzisz w przeglądarce, nie w GTM.

02Dlaczego zakładka Requests w Preview jest pusta?

Najczęściej dlatego, że tag web nie ma ustawionego transport_url na Twoją subdomenę first-party albo subdomena nie odpowiada. Dane lecą wtedy prosto do Google, a kontener ich nie widzi. Sprawdź transport_url, rekord DNS i ważność certyfikatu SSL subdomeny.

03Czym różni się debugowanie sGTM od klasycznego GTM?

W kontenerze webowym (client-side) analizujesz zdarzenia w dataLayer i konsoli przeglądarki. W kontenerze serwerowym analizujesz pary żądanie-odpowiedź HTTP oraz to, który klient przechwycił żądanie (claim). To zmienia zestaw błędów: pojawiają się transport, claim i CORS, których w client-side praktycznie nie ma.

04Czy debugowanie kontenera narusza RODO?

Samo debugowanie nie narusza RODO, o ile w trybie Preview pracujesz na danych testowych, a nie na realnych danych klientów. Co więcej, jednym z celów diagnozy jest sprawdzenie, czy serwer respektuje Consent Mode i filtruje parametry PII zgodnie z minimalizacją danych.

05Czy debugowanie server-side GTM jest możliwe bez dostępu do Google Cloud?

Tak. Jeśli kontener stoi na stape.io, masz wbudowany panel logów z podglądem ruchu i statusów HTTP - bez wchodzenia w konsolę Google Cloud. Do tego zawsze dostępny jest tryb Preview w GTM i konsola przeglądarki. Logi Cloud Run są potrzebne dopiero przy własnym hostingu na GCP.

06Czy muszę być programistą, żeby zdebugować sGTM?

Nie do podstawowej diagnozy. Odczyt trybu Preview, zakładek Requests i Tags oraz konsoli przeglądarki nie wymaga pisania kodu - wymaga zrozumienia łańcucha transport-claim-tag. Wiedza techniczna przydaje się dopiero przy własnym hostingu i konfiguracji DNS, gdzie łatwiej o kosztowną pomyłkę.

---