Strona główna / Poradniki

Google Tag Gateway: sprawdzenie, czy naprawdę działa

Tag Gateway serwuje skrypty Google z Twojej domeny. Co zmienia się w żądaniu, czym różni się od server-side GTM i jak po cichu działa połowicznie.

Opublikowano 10 sierpnia 2026

Tag Gateway przenosi dostarczanie pomiaru Google na Twoją własną domenę. Zamiast pobierać gtag.js z googletagmanager.com i wysyłać dane na google-analytics.com, przeglądarka robi jedno i drugie przez ścieżkę pomiaru na Twoim hoście — coś w rodzaju example.com/metrics/… — którą Twój CDN przekazuje dalej do Google.

To nie jest server-side GTM, a różnica ma znaczenie

Te dwie rzeczy są mylone bez przerwy, a psują się zupełnie inaczej.

• Server-side GTM przenosi wykonanie tagów do kontenera, który prowadzisz. Przeglądarka wysyła jedno żądanie do Twojego serwera; to serwer decyduje, co i komu przekazać. Tam możesz zdarzenia przepisać, wzbogacić albo odrzucić.
• Tag Gateway przenosi wyłącznie transport. Tagi nadal wykonują się w przeglądarce, zawartość się nie zmienia, a Twoja infrastruktura jest rurą, nie uczestnikiem.

Możesz mieć oba, jedno albo żadne. Przy debugowaniu brakującego zdarzenia świadomość, które z nich jest w grze, mówi, czy podejrzewać konfigurację kontenera, czy regułę routingu.

Co zmienia się w żądaniu

W środku nic. tid, en, cid, parametry zdarzenia, pozycje, flagi zgód — wszystko identyczne. Zmienia się host i prefiks ścieżki. Ten jeden fakt tłumaczy, dlaczego tyle narzędzi do debugowania nagle nic nie pokazuje: rozpoznają trafienia Google po nazwie hosta, a host jest teraz Twój.

Czytanie po ścieżce — /g/collect gdziekolwiek, na dowolnym hoście — utrzymuje je widocznymi; to ta sama sztuczka, która czyni czytelnymi trafienia server-side GTM.

Cztery sposoby na połowiczne działanie

1. Skrypt jest first-party, a trafienia nie. Niepełna konfiguracja serwuje gtag.js z Twojej domeny, podczas gdy zbieranie nadal idzie do Google. W raportach wszystko wygląda dobrze, a z trwałości, dla której to wdrażałeś, nie masz nic. Sprawdź hosta na żądaniu /g/collect, nie na skrypcie.
2. Ścieżka pomiaru koliduje z trasą aplikacji. Jeśli aplikacja już odpowiada na tym prefiksie albo router ma regułę łapiącą wszystko, reguła CDN nigdy nie dostaje szansy, a żądania wracają jako Twoja własna strona 404. Błąd 404 na żądaniu collect to nie usterka, którą znajdziesz w GA4 — widać ją tylko w sieci.
3. Reguła cache łapie endpoint. Ścieżki pomiaru leżą na tej samej domenie co strony, więc szeroka reguła cachowania może objąć i je. Zbuforowana odpowiedź collect nie gubi trafienia — żądanie i tak wychodzi — ale zbuforowany gtag.js potrafi przypiąć odwiedzających do starej konfiguracji na cały czas TTL.
4. Zgody się nie zmieniają, choć wielu zakłada inaczej. Dostarczanie first-party nie zmienia tego, co wolno zbierać, kiedy odczytywane są sygnały Consent Mode ani czy baner musi się pojawić. Parametry gcs i gcd podróżują dokładnie jak wcześniej i to je należy sprawdzić.

Rzecz, o której warto zdecydować świadomie

Część raportowanego wzrostu przy serwowaniu first-party pochodzi z żądań, które blokada treści zatrzymałaby na hoście Google, a na Twoim nie zatrzymuje. To realny efekt i lepiej go zrozumieć od razu niż odkryć później: to decyzja o tym, jak traktujesz odwiedzających, którzy wybrali blokowanie śledzenia, i jest ona niezależna od tego, czy Twoja implementacja zgód jest poprawna.

Procedura

1. Wczytaj stronę i znajdź żądanie gtag.js. Zanotuj jego hosta.
2. Znajdź żądanie /g/collect. Zanotuj hosta i tutaj. Jeśli się różnią, konfiguracja jest zrobiona w połowie.
3. Sprawdź kod odpowiedzi. Błędny routing gatewaya objawia się jako 404 albo przekierowanie, nigdy jako brak danych w raporcie.
4. Otwórz trafienie i potwierdź, że tid, nazwa zdarzenia i gcs są takie jak przed migracją. Zawartość powinna być nietknięta.
5. Przejdź konwersję od początku do końca i porównaj liczby z poprzednią konfiguracją, zanim ją wyłączysz.

Powiązane poradniki

• Gdy GA4 twierdzi, że ruch przyszedł skądinąd
• Śledzenie wewnątrz osadzonego widżetu
• Jak debugować server-side GTM