Purchase serwerem, scroll przeglądarką: hybrydowe tagowanie w GTM po zmianach z lata 2026

W październiku Anna pisała na tym blogu, dlaczego server-side GTM jest fundamentem pomiaru. Nie będę tego powtarzał. Piszę o tym, co przychodzi po wdrożeniu: fakturze za hosting, która rośnie z ruchem, i pytaniu, czy każde zdarzenie ze sklepu naprawdę musi przejść przez serwer. W DrTusz mamy sGTM od dłuższego czasu i odpowiedź, do której doszedłem, brzmi: nie. Lato 2026 przyniosło do tego kilka zmian w samym GTM, które warto sprawdzić przy okazji.

Za co płacisz w sGTM

Kontener serwerowy kosztuje od żądania, nie od sesji. Stape podaje na stronie hostingu: bezpłatnie do 10 tys. żądań miesięcznie, 20 dol. miesięcznie dla typowej strony i 100 dol. miesięcznie powyżej 500 tys. żądań. Na własnej infrastrukturze instrukcja Google dla Cloud Run szacuje „około 45 dol. miesięcznie" za serwer, zaleca minimum dwie instancje ze względu na ryzyko utraty danych i przewiduje, że 2–10 instancji obsłuży 35–350 żądań na sekundę. Do tego dochodzi czas osoby, która to utrzymuje.

Teraz arytmetyka sklepu. Sesja w e-commerce to nie jedno zdarzenie: page_view, view_item_list na każdej stronie kategorii, view_item, scroll, user_engagement, add_to_cart, begin_checkout, purchase. Kilkanaście żądań na sesję to norma, więc sklep z 50 tys. sesji miesięcznie wysyła do kontenera grubo ponad pół miliona żądań. Jeśli wszystkie idą przez serwer, płacisz pełną stawkę za scrolle, które niczego nie zmieniają w Twoich decyzjach. Kaloryczność tych żądań jest bardzo różna, a cena taka sama.

Zasada podziału: pieniężne serwerem, behawioralne przeglądarką

Podział, który stosuję, opiera się na jednym pytaniu: co się stanie, gdy to zdarzenie zginie?

Przez serwer idą zdarzenia, których utrata kosztuje pieniądze: purchase, refund, begin_checkout, add_to_cart, generate_lead, sign_up. To one zasilają Smart Bidding w Google Ads i Conversions API w Meta, więc każda dziura w nich to gorsze stawki. Są rzadkie (zakup to zwykle jeden do trzech procent sesji), więc tanie w hostingu. I tylko po stronie serwera mogę je wzbogacić o to, czego przeglądarka nie zna: marżę produktu, koszt dostawy, status klienta z bazy. Wpływ blokad reklam na tę warstwę jest realny: według raportu IAB Polska z marca 2024 odsetek dorosłych internautów z adblockiem w Polsce wzrósł z 36% w 2016 do 45% w 2023 roku (to dane sprzed dwóch lat, nie świeży pomiar), a wiele blokad tnie ruch do domen Google, nie do Twojej własnej.

Przez przeglądarkę idą zdarzenia, których strata boli statystycznie, ale nie finansowo: page_view, view_item_list, view_item, scroll, wideo, user_engagement. Są masowe i służą do raportów o zachowaniu, gdzie kilka procent braków nie zmienia wniosku. Wyjątek: jeśli budujesz w GA4 odbiorców do remarketingu z view_item, przenieś to jedno zdarzenie na serwer, bo tam listy tracą najwięcej.

Nie ma tu dogmatu. Sklep, który raportuje wyłącznie sprzedaż, może ograniczyć serwer do purchase i refund. Sklep, który liczy lejek do ostatniego kroku, dołoży begin_checkout i add_payment_info. Ważne, żeby lista była świadoma i zapisana, a nie wynikała z tego, że kiedyś ktoś włączył „wszystko przez serwer".

Jak to zrobić w GTM: jeden tag Google, dwa kanały wysyłki

Simo Ahava opisał 14 sierpnia metodę, która nie wymaga drugiej usługi GA4 ani dwóch tagów konfiguracyjnych. Wszystko kręci się wokół parametru server_container_url. W tagu Google ustawiasz go na adres kontenera serwerowego, więc domyślnie wszystkie zdarzenia, także zbierane automatycznie, idą przez sGTM. W tagach zdarzeń, które mają iść bezpośrednio do Google, dodajesz ten sam parametr z pustym ciągiem znaków. Simo zaznacza, że musi to być pusty ciąg albo null, nigdy undefined, bo undefined GTM czyta jako „zostaw poprzednie ustawienie". Dla bezpieczeństwa zaleca też zmienną ustawień zdarzenia z adresem serwera dla tagów, które mają iść serwerem, na wypadek gdyby tag zdarzenia odpalił się przed tagiem Google.

Jeden warunek jest krytyczny i łatwo go przeoczyć: klient GA4 w kontenerze serwerowym musi pracować w trybie tożsamości zarządzanej przez JavaScript. W trybie zarządzanym przez serwer zdarzenia z dwóch kanałów dostaną różne identyfikatory klienta i wylądują jako dwaj różni użytkownicy: jeden ogląda produkty, drugi kupuje, żaden nie ma pełnej ścieżki. Test jest prosty: w DebugView otwórz jedną sesję, w której jest view_item z przeglądarki i purchase z serwera, i sprawdź, czy mają ten sam client_id. Dopóki nie mają, nie publikuj.

Adres IP: co GA4 robi sam, co możesz zrobić w sGTM

Wokół IP narosło sporo mitów z czasów Universal Analytics. Pomoc Google mówi wprost, że w GA4 maskowanie IP nie jest potrzebne, bo adresy „nie są rejestrowane ani przechowywane", a osobna strona dodaje, że ruch z UE, Szwajcarii i Wielkiej Brytanii jest zbierany na serwerach w tych regionach, a IP służy wyłącznie do wyznaczenia lokalizacji i jest natychmiast odrzucany.

W sGTM jest inaczej, bo żądanie przechodzi przez Twój serwer i IP jest tam widoczne. Możesz je usunąć przed wysyłką do GA4 albo podmienić na adres reprezentujący tylko region, Stape opisał obie drogi 26 sierpnia, również w wariancie warunkowym, gdy użytkownik odmówił zgody. Koszt: bez IP GA4 nie wyznaczy miasta ani regionu, więc raporty geograficzne przestają działać. Ma to sens, gdy inspektor ochrony danych w firmie przyjął surowszą interpretację albo gdy sprzedajesz w krajach, w których organy nadzoru patrzą na analitykę ostrzej. Nie robiłbym tego „bo RODO", bez rozmowy z osobą, która za to odpowiada; to nie jest porada prawna.

Letnie zmiany w GTM: co sprawdzić w kontenerze sklepu

Notatki o wersjach GTM z lata 2026 mają cztery wpisy, które dotykają sklepów z sGTM.

• 22 czerwca, konwersje server-to-server. Google „odzyskuje konwersje, które wcześniej były niedoliczane w konfiguracjach server-to-server z braku kontekstu cookies przeglądarki": dane z serwera są łączone z równoległymi sygnałami z przeglądarki, gdy w żądaniu jest GCLID. Jeśli wysyłasz konwersje z backendu (np. potwierdzone płatności), liczba konwersji mogła wzrosnąć bez zmiany w sprzedaży. Dopisz adnotację do raportów.
• 9 lipca, nieobsługiwane ścieżki ładowania. Kontenery ładowane ścieżką w rodzaju /gtag/js lub /gtag/destination wcześniej przechodziły w tryb ograniczony, w którym działały tylko tagi Google. Teraz o zachowaniu decyduje wyłącznie identyfikator: kontener z ID GTM- nie jest ograniczany, a ID G- i AW- pozwalają uruchamiać tylko tagi dostarczane przez Google. Sprawdź w kodzie sklepu i w konfiguracji serwera, jakim ID i jaką ścieżką ładujesz kontener, zwłaszcza jeśli serwujesz go z własnej domeny.
• Fragment gtm.js i gtag('config'). Google zapowiada, że fragment GTM „wkrótce" przestanie rozpoznawać polecenia gtag('config'). Wdrażanie identyfikatorów G-, AW- czy DC- przez fragment gtm.js nazywa konfiguracją nieobsługiwaną. Poprawka to tagi w GTM albo osobny fragment gtag.js.
• Czerwiec, Google tag gateway. Google udostępnił opcję przepuszczania tagów przez własną infrastrukturę: load balancer w Google Cloud (1 czerwca) i Amazon CloudFront (3 czerwca). To nie jest sGTM i nie daje wzbogacania danych, ale dla sklepu, który chce tylko serwować tagi z własnej domeny, może być tańsze niż kontener serwerowy. Warto znać różnicę, zanim ktoś sprzeda Ci jedno jako drugie.

Co zrobić w najbliższym tygodniu

1. Policz żądania z ostatnich 30 dni w panelu hostingu lub logach sGTM, z podziałem na nazwy zdarzeń. Pięć najczęstszych to kandydaci do przeniesienia na przeglądarkę.
2. Spisz listę zdarzeń serwerowych i uzasadnienie dla każdego („zasila Smart Bidding", „wzbogacam o marżę"). Reszta idzie przeglądarką.
3. Wdróż podział w wersji roboczej kontenera według metody Simo i sprawdź w DebugView, czy view_item i purchase z jednej sesji mają ten sam client_id.
4. Sprawdź ID i ścieżkę ładowania kontenera oraz obecność gtag('config') we fragmencie gtm.js.
5. Podejmij decyzję o IP z osobą odpowiedzialną za ochronę danych; jeśli usuwasz IP, zapisz, że raporty geograficzne przestają działać.
6. Dodaj adnotację „22.06" do raportów konwersji, jeśli wysyłasz konwersje z backendu.

Server-side GTM ma sens tam, gdzie chroni pieniądze: konwersje, listy odbiorców, dane o marży. Wszędzie indziej jest kosztem, który rośnie razem z ruchem, a ruch, jak pisałem nie raz, ma różną kaloryczność. Jeśli chcesz przejrzeć swój kontener pod kątem tego, co naprawdę musi iść przez serwer, porozmawiajmy o Twoim sklepie.