Server-side GTM najczęściej nie działa dlatego, że kontener nie ma własnej subdomeny z poprawnym certyfikatem, więc przeglądarka traktuje go jak zewnętrzną domenę i zjadają go te same blokady co wcześniej. Drugi klasyk to sytuacja, w której strona nadal wysyła dane bezpośrednio do GA4 obok kontenera, przez co zdarzenia liczą się podwójnie. Trzeci to brak przekazywania zgód, czwarty to źle ustawione ciasteczka pierwszej strony.
Co to jest server-side GTM i kiedy ma sens
Server-Side GTM to dodatkowy kontener GTM uruchomiony na Twoim serwerze (Cloud Run, App Engine, Vercel) – przyjmuje requesty z client-side GTM, przerabia je i wysyła do GA4, Google Ads, Meta CAPI itd. Daje większą kontrolę nad danymi (bypass cookie blokad, hashing po stronie serwera, własna domena dla cookies first-party).
Sprawdź to na swojej stronie
Darmowy audyt sprawdzi szybkość, technologię i pomiar ruchu na Twojej stronie, i pokaże wynik na konkretnych liczbach.
Chcesz od razu plan naprawy z wyceną? Audyt ekspercki za 900 zł, odliczany od realizacji.
Pierwsza przyczyna: brak własnej subdomeny dla server-side
Domyślnie sGTM działa na *.run.app albo *.appspot.com. Cookies z tej domeny są treated as third-party przez Safari/Brave i będą blokowane. Trzeba skonfigurować subdomenę typu sgtm.koderownia.pl wskazującą na Cloud Run + ustawić ją w preview/published container Settings.
Druga przyczyna: web-side wciąż wysyła do GA4 bezpośrednio
Po wdrożeniu sGTM trzeba ZMIENIĆ tag GA4 w web-side GTM, żeby wysyłał do server-side container endpoint, nie bezpośrednio do GA4. Jeśli web-side wciąż ma stary tag GA4 → mamy duplicate measurement (raz client-side bezpośrednio, raz przez server). To często widać jako podwojone konwersje.
Trzecia przyczyna: Cloud Run nie skalował się
sGTM zużywa zasoby na każdy request. Default Cloud Run config (1 vCPU, 256MB RAM) wystarcza dla małego ruchu. Powyżej 100k uu/mies. trzeba zwiększyć do min-instances=2 + 2 vCPU + 1GB RAM, inaczej sGTM odrzuca część requestów cold-start failures.
Czwarta przyczyna: CORS dla Meta CAPI / TikTok
Meta Conversions API i TikTok Events API wymagają specyficznych headers przy wysyłaniu requestów. sGTM template Conversions API z Galleria czasem nie ustawia poprawnie X-Forwarded-For lub User-Agent – efekt: Meta odrzuca eventy jako 'invalid request’. Trzeba customować template albo użyć stedi-template.
Checklista diagnostyczna
Krótki check-list do przejścia w 5 minut:
- sGTM container URL pokazuje Twoją własną subdomenę
- DNS subdomeny wskazuje na Cloud Run / App Engine
- SSL certificate active dla subdomeny
- Web-side GTM ma tag GA4 wysyłający do sGTM endpoint, nie *.google-analytics.com
- Cloud Run ma min-instances >= 1 dla produkcji
- Meta CAPI tag ma poprawny test_event_code
- Logs z sGTM pokazują 200 status dla większości requestów
Powiązane wpisy
Jeśli ten temat Cię interesuje, sprawdź też:
Checklista pomiaru 2026: GA4, GTM i Consent Mode
Wpisz adres email, dostaniesz link do pobrania na skrzynkę. Bez zapisu do newslettera, bez spamu.
Potrzebujesz wsparcia?
Jeśli problem dotyczy Twojej firmy i potrzebujesz pomocy z konfiguracją – sprawdź usługę specjalistyczną albo opisz problem w briefie.
Powiązane materiały
Jeśli ten temat Cię interesuje, sprawdź też:
- 📚 Google Ads – przewodnik performance marketing – pełny przewodnik z linkami do wszystkich powiązanych artykułów
- 🛠 Generator dataLayer dla GTM/GA4 – darmowe narzędzie self-hosted
Gotowy zrobić to z kimś, kto ma to opanowane?
W Koderowni dostarczam custom WordPress + performance marketing dla świadomych marek. Jeśli ten temat jest dla Ciebie istotny w konkretnym projekcie:
- 📋 Proces współpracy – pięć etapów od briefu do publikacji, cykle od 4 do 22 tygodni
- 💰 Widełki cenowe 2026 – orientacyjne stawki dla wszystkich obszarów + kalkulator
- 📝 Zakres usług – sześć obszarów: WordPress, GA4, Google Ads, GTM, Consent Mode, lokalne SEO