Google Tag Gateway: co zmienia w żądaniu pomiarowym i czym różni się od tagowania po stronie serwera

Google Tag Gateway zaczął na Cloudflare, 1 czerwca 2026 stał się ogólnie dostępny na Google Cloud przez zewnętrzny Application Load Balancer, a w tym samym miesiącu zyskał ścieżkę konfiguracji dla Amazon CloudFront. Jest więc zwykłą możliwością, a nie eksperymentem – i bywa zwykle opisywany jako lżejsza alternatywa dla tagowania serwerowego.

Alternatywą dla niego nie jest. Obydwa zmieniają co innego, a spojrzenie na samo żądanie uwidacznia różnicę w mniej więcej minutę.

Co się naprawdę przesuwa

Gateway to pośrednik odwrotny na ścieżce własnej domeny. Przechodzą przez niego zarówno skrypt, jak i trafienia pomiarowe – tag ładuje się z czegoś w rodzaju /metrics/gtag/js zamiast z googletagmanager.com, a trafienia idą do /metrics/g/collect na tym samym hoście. CDN, load balancer albo serwer WWW przepisuje ścieżkę i przekazuje żądanie do Google.

Z punktu widzenia przeglądarki każde z tych żądań jest teraz pierwszostronne. To cały mechanizm. Po drodze w ciele żądania nic się nie zmienia i nic zmieniać się nie ma: dokumentacja odnotowuje, że przechodzą wyłącznie ciasteczka pierwszej strony należące do Google, a wszystkie inne przekazywane tą drogą są odrzucane, a nie przetwarzane.

Czego świadomie nie robi

Tag nadal działa w przeglądarce, buduje ładunek w przeglądarce i wysyła ten ładunek, który zbudował. W tym układzie nie ma miejsca, w którym dałoby się usunąć parametr, którego w ogóle nie wolno było zbierać, odszukać wartość klienta w systemie wewnętrznym albo rozstrzygnąć na serwerze, że trafienie nie zostanie przekazane wcale. Dokładnie po to istnieje kontener serwerowy, a gateway nie ma o tym wszystkim żadnego zdania.

Sprawa ciasteczka i jak ją rozstrzygnąć

Twierdzenie najczęściej doczepiane do serwowania pierwszostronnego brzmi, że przywraca ono trwałość ciasteczka pod Safari. Zależy to wyłącznie od tego, który mechanizm zapisuje ciasteczko, a rozróżnienie jest ostre: ciasteczko zapisane przez JavaScript Intelligent Tracking Prevention ucina do siedmiu dni, obojętne, który host dostarczył skrypt, natomiast ciasteczko zapisane przez serwer w nagłówku odpowiedzi Set-Cookie zachowuje trwałość, o którą prosi.

Strona Google o obsłudze ciasteczek w Tag Gateway opisuje, które ciasteczka przechodzą, a które są odrzucane. Który z dwóch mechanizmów je zapisuje – tego nie mówi. To nie powód, by zgadywać w którąkolwiek stronę – to powód, by sprawdzić, a sprawdzenie kosztuje jedno żądanie.

# czego przegladarka teraz zada, na wskros pierwszostronnie
GET https://shop.example/metrics/gtag/js?id=G-XXXXXXX
GET https://shop.example/metrics/g/collect?v=2&tid=G-XXXXXXX&...

# pytanie, ktore dokumentacja zostawia otwarte
curl -sI 'https://shop.example/metrics/g/collect?v=2&tid=G-XXXXXXX' \
  | grep -i '^set-cookie'

# brak linii          → zapisuje skrypt, siedem dni pod ITP
# linia Set-Cookie    → zapisuje serwer, Max-Age obowiazuje

Ta sama odpowiedź stoi w przeglądarce w zakładce aplikacji, gdy sprawdzić, czy ciasteczko pojawia się przed uruchomieniem tagu, czy dopiero po nim. Jakkolwiek wypadnie – wynik jest faktem o tej instalacji, a nie ogólną własnością produktu, i należy do notatek dla tego, kto tę konfigurację odziedziczy.

Blokady widzą ścieżkę, nie tylko host

Ścieżka pierwszostronna pokonuje najprostszą postać blokady, czyli listę nazw hostów. Nie pokonuje reguły dopasowanej do odcinka ścieżki, treści skryptu albo kształtu ciała żądania – a rozpowszechnione listy filtrów dostały reguły oparte na ścieżce dla dokładnie tego wzorca wkrótce po jego pojawieniu się.

Spodziewać się więc należy odzysku, a nie przywrócenia: część wcześniej blokowanego ruchu wraca, udział zależy od tego, jakie listy prowadzi publiczność, i topnieje z każdą aktualizacją. Niepozorna nazwa ścieżki kupuje trochę czasu i nie jest strategią.

Gdzie stoi obok kontenera serwerowego

Własne zalecenie Google brzmi: zrobić obydwa, a powód jest taki, że rozwiązują sąsiadujące problemy. Gateway porządkuje drogę dostawy, kontener porządkuje to, co nią jedzie. Witryna z kontenerem serwerowym i bez gatewaya nadal ładuje swój tag z obcego hosta, o ile kontener sam nie dostarcza skryptów Google. Witryna z gatewayem i bez kontenera ma ścieżkę pierwszostronną, którą niesprawdzony ładunek jedzie prosto do Google.

Jeśli da się zbudować tylko jedno, kolejność wynika z tego, czego witryna naprawdę potrzebuje. Gdy problem leży w ochronie danych – parametr, który nie może wyjść, wartość, którą trzeba wcześniej zahaszować – rozwiąże go wyłącznie kontener, a gateway przed niefiltrowanym ładunkiem nie rozwiązuje niczego. Gdy problem leży w utracie pomiaru na witrynie bez niczego wrażliwego w ładunku, gateway jest znacznie tańszy i załatwia całą sprawę.

Liczba przyrostu jest twierdzeniem, nie pomiarem

Dostawcy podają po wdrożeniu gatewaya przyrosty konwersji rzędu dziewięciu do osiemnastu procent. Liczby te pochodzą od tych, którzy wdrożenie sprzedają, są średnimi po niewymienionych witrynach i zlewają trzy zgodnie skierowane skutki: mniej blokowanych żądań, dłuższą trwałość ciasteczek tam, gdzie zapisuje je serwer, oraz zwykły sezonowy dryf porównywanego okresu.

Uczciwą próbą jest grupa kontrolna: część ruchu zostaje na dawnej drodze, obie działają dwa tygodnie obok siebie, a porównuje się obie grupy, a nie dwa okresy. To więcej pracy niż lektura studium przypadku i jedyna wersja tej liczby, która przetrwa dopytanie.

Konfiguracja ręczna: co musi zawierać reguła przekazywania

Integracje dla Cloudflare i Google Cloud same ustawiają trasę. Gdy gateway jest konfigurowany ręcznie na innym CDN lub load balancerze, instrukcja Google wymienia kilka wymagań, a brak każdego z nich psuje coś konkretnego.

• Źródło. Host docelowy wynika z identyfikatora tagu: G-12345.fps.goog dla tagu Google, gtm-abcdef.fps.goog dla kontenera Tag Managera. Nagłówek Host przekazywanego żądania zostaje nadpisany tą nazwą, a ciasteczka i parametry zapytania przechodzą w całości.
• Ścieżka. Ścieżka jest dowolna w pewnych granicach: nie może to być katalog główny /, nie może przekraczać 100 znaków i nie może być już zajęta w domenie.
• Lokalizacja. Bez gatewaya Google ustala lokalizację na podstawie adresu IP odwiedzającego. Za gatewayem backend Google otrzymuje zamiast niego adres CDN, dlatego CDN musi dołączyć lokalizację w nagłówkach: najlepiej X-Forwarded-CountryRegion z kodem ISO 3166-2, na przykład US-CA, a w przeciwnym razie X-Forwarded-Country razem z X-Forwarded-Region. Jeśli dotrą oba warianty, pierwszeństwo ma nagłówek łączony. Prawdziwy adres IP klienta trafia bez zmian do standardowego nagłówka, takiego jak X-Forwarded-For.

Brak nagłówków lokalizacji nie zatrzymuje pomiaru. Trafienia nadal docierają, a szkoda wychodzi na jaw dopiero później jako niedokładna geografia w raportach. Dlatego sprawdzenie ma sens zaraz po uruchomieniu, a nie dopiero przy miesięcznym raporcie:

# przy poprawnej trasie oba adresy odpowiadają tekstem "ok"
https://shop.example/metrics/healthy
https://shop.example/metrics/?validate_geo=healthy

Pierwszy adres potwierdza trasę, drugi to, że nagłówki lokalizacji docierają. W Tag Assistant wysłane trafienia powinny następnie pokazywać własną ścieżkę witryny. Jeden element zostaje poza gatewayem: fragment <noscript> Tag Managera nie jest obsługiwany i nadal wskazuje na www.googletagmanager.com.