Server-side tagging dla Google Ads: wdrożenie i korzyści

Server-side tagging to technika przenoszenia tagów śledzących (Google Ads, Google Analytics 4, Meta Pixel i innych) z przeglądarki użytkownika na dedykowany serwer pośredniczący - najczęściej kontener Google Tag Manager Server-Side hostowany w Google Cloud Run lub na platformie Stape.io. Zamiast ładować skrypty bezpośrednio w przeglądarce, dane o zdarzeniach i konwersjach zbiera i przetwarza serwer, co eliminuje blokowanie przez ad blockery, wydłuża żywotność plików cookie do ponad 400 dni z pominięciem ograniczeń ITP Safari i upraszcza zgodność z Consent Mode v2. W kontekście Google Ads server-side tagging oznacza dokładniejszy pomiar konwersji, pełniejsze dane dla Smart Bidding i wyższy zwrot z budżetu reklamowego.

Widzisz rozbieżność między liczbą konwersji w panelu Google Ads a danymi z CRM albo Google Analytics? To pierwszy sygnał, że tracisz dane na poziomie przeglądarki. Ad blockery, mechanizm ITP w Safari, skracany czas życia cookies third-party i coraz ostrzejsze regulacje prywatności sprawiają, że klasyczny client-side tagging przestaje nadążać. Przez lata audytowania kont Google Ads obserwowałem, jak ten problem narastał - od 5-10 procent utraty danych kilka lat temu do 30-40 procent na niektórych kontach dzisiaj. Server-side tagging to najskuteczniejsza odpowiedź, jaką znam, i poniżej pokażę Ci, jak go zaplanować, wdrożyć i nie stracić przy tym danych.

Skrót artykułu

Co warto wiedzieć

Wnioski, które decydują o tym, czy przeniesienie tagów na serwer realnie odzyska konwersje w Google Ads.

• Server-side tagging przenosi tagi Google Ads z przeglądarki do kontenera GTM na serwerze

  Kontener serwerowy przyjmuje zdarzenia z kontenera webowego przez jeden endpoint i dopiero z serwera rozsyła je do Google Ads, GA4 oraz Meta. Ad blocker widzi wyłącznie ruch do domeny wydawcy, więc nie ma czego blokować.

• Domyślny adres Cloud Run zamiast własnej subdomeny cofa cookies do statusu third-party

  Google w dokumentacji serwera GTM opisuje mapowanie własnej domeny rekordem A lub CNAME jako warunek pełnego dostępu do cookies. Adres w rodzaju gtm-xxxxx.a.run.app zostawia pomiar w reżimie skracania czasu życia cookies przez ITP w Safari.

• Darmowy tier Cloud Run pokrywa pomiar serwerowy strony do około 100 tysięcy sesji

  Google Cloud podaje w cenniku Cloud Run darmowy limit 2 milionów żądań miesięcznie (stan na 2026 rok). Hosting kontenera na Stape.io startuje od około 20 USD miesięcznie, więc barierą wejścia jest konfiguracja, a nie koszt infrastruktury.

• Enhanced Conversions trzeba włączyć osobno w kontenerze serwerowym, inaczej dopasowanie stoi w miejscu

  Konfiguracja z kontenera webowego nie przenosi się na serwer automatycznie. W kontach Google Ads, które prowadziłem i audytowałem w ostatnich dwóch latach, samo dołożenie tej jednej opcji podnosiło współczynnik dopasowania konwersji o 15-25 procent.

• Pozostawione tagi client-side dublują konwersje Google Ads i psują Smart Bidding

  Duplikat powstaje wtedy, gdy kontener webowy nadal wysyła to samo zdarzenie wprost do Google, a serwer wysyła je równolegle. Zamiast odzyskać dane, konto raportuje ich za dużo, a algorytm licytuje na zawyżonym sygnale.

Czym jest server-side tagging i czym różni się od client-side?

Server-side tagging przenosi punkt zbierania danych z przeglądarki użytkownika na serwer, i ta jedna zmiana architektoniczna rozwiązuje większość problemów z utratą konwersji w Google Ads.

W modelu client-side każdy tag - Google Ads, GA4, Meta Pixel - to osobny skrypt JavaScript ładowany w przeglądarce. W modelu server-side przeglądarka wysyła dane do jednego endpointu na Twojej subdomenie, a serwer GTM rozdziela je dalej do platform reklamowych.

Pomyśl o tym jak o celniku na granicy Twoich danych. W modelu client-side każda platforma reklamowa musi osobno wejść do przeglądarki po swoje dane - i każdą można zablokować wtyczką prywatności albo ograniczeniem przeglądarki. W modelu server-side istnieje jeden rurociąg z przeglądarki na Twój serwer, a serwer dopiero dystrybuuje informacje do Google Ads, GA4 czy Meta. Ad blocker nie ma czego blokować, bo widzi wyłącznie Twoją własną domenę.

Różnica jest fundamentalna także dla szybkości strony. Client-side ładuje w przeglądarce od kilku do kilkunastu skryptów JavaScript, co obciąża Core Web Vitals. Server-side redukuje to do minimum - często zostaje jeden lekki snippet z przekierowaniem na subdomenę, a reszta przetwarzania dzieje się poza urządzeniem użytkownika. Wdrożenie nie oznacza rezygnacji z kontenera webowego: on nadal istnieje, ale zamiast wysyłać dane wprost do Google, kieruje je na Twój serwer.

ARCHITEKTURA SST

Jak dane docierają od kliknięcia do konwersji

Przepływ informacji od interakcji użytkownika przez serwer GTM do raportu konwersji w Google Ads.

Wejście (Sygnały)

Kliknięcie w reklamę

Zdarzenie purchase

Dane z formularza

Parametr GCLID

ProcesorSerwer GTM (Cloud Run / Stape.io)

Wzbogaca dane o first-party cookies, mapuje zdarzenia, dokłada Consent Mode i wysyła do Google Ads pełny zestaw parametrów.

Wyjście (Output)

WynikKonwersja z pełnymi danymi

GCLID, Enhanced Conversions i sygnały zgody dostarczone przez first-party endpoint.

Dlaczego server-side tagging jest kluczowy dla Google Ads?

Utrata danych konwersji to najpoważniejszy problem, który server-side tagging rozwiązuje dla kampanii Google Ads. Bez pełnych danych Smart Bidding optymalizuje w ciemno - algorytm nie wie, które kliknięcia prowadzą do sprzedaży, więc stawia na niewłaściwe segmenty i przepala budżet.

Z moich obserwacji konta po wdrożeniu SST notują skok widocznych konwersji od 20 do ponad 50 procent. Nie dlatego, że konwersji jest więcej, lecz dlatego, że system wreszcie je widzi.

Cztery trendy rynkowe sprawiły, że SST przestał być dodatkiem i stał się elementem podstawowej infrastruktury pomiarowej:

• Ograniczanie third-party cookies: Safari i Firefox blokują je od dawna, a Chrome konsekwentnie zawęża ich rolę w ramach Privacy Sandbox. Server-side ustawia first-party cookies z Twojej subdomeny i omija te ograniczenia.
• ITP w Safari: Intelligent Tracking Prevention skraca żywotność cookies ustawianych przez JavaScript do 7 dni, czasem do doby. Cookies ustawiane serwerowo przez nagłówek HTTP Set-Cookie nie podlegają temu limitowi i żyją ponad 400 dni.
• Ad blockery: według badań IAB Polska blokerów reklam używa 45 procent dorosłych internautów w Polsce. Wycinają domeny typu googletagmanager.com. Ruch z Twojej subdomeny nie jest przez nie rozpoznawany jako tracker.
• Consent Mode v2: Google wymaga parametrów ad_user_data i ad_personalization dla reklamodawców kierujących ruch do EOG. Server-side centralizuje obsługę zgód - jeden punkt konfiguracji zamiast osobnej logiki w każdym tagu.

Wielokrotnie obserwowałem sytuację, w której klient miał poprawnie skonfigurowane Enhanced Conversions w kontenerze webowym, a mimo to współczynnik dopasowania konwersji był niski. Powód był zawsze ten sam - dane przechodziły przez przeglądarkę i część z nich ginęła, zanim dotarła do Google. Server-side przesyła zahashowane dane wprost z serwera, więc dopasowanie rośnie, a atrybucja staje się precyzyjniejsza. Jeśli chcesz zobaczyć, ile danych ucieka na Twoim koncie, taki pomiar robię standardowo podczas audytu konfiguracji pomiaru.

Jakie korzyści daje server-side tagging dla kampanii Google Ads?

Największa korzyść to więcej widocznych konwersji bez zmiany strategii kampanii. Nie chodzi o dodatkowy ruch, lecz o to, że system wreszcie widzi konwersje, które wcześniej ginęły między przeglądarką a serwerem Google.

Pełniejsze dane konwersji przekładają się bezpośrednio na lepsze decyzje Smart Bidding, niższy CPA i wyższy ROAS - bo algorytm uczy się na kompletnym, a nie dziurawym obrazie.

• Więcej śledzonych konwersji: typowo od 20 do 50 procent, w zależności od profilu ruchu - im więcej Safari i mobile, tym większy efekt.
• Skuteczniejszy Smart Bidding: Target CPA i Target ROAS działają precyzyjniej, bo nie bazują na niekompletnych sygnałach konwersji.
• Wyższe dopasowanie Enhanced Conversions: dane przesyłane serwerowo mają lepszy match rate niż te z przeglądarki.
• Szybsza strona: mniej skryptów w przeglądarce to lepsze Core Web Vitals, wyższy Wynik Jakości i potencjalnie niższy CPC.
• Kontrola nad danymi: jeden punkt, w którym filtrujesz, wzbogacasz i transformujesz dane, zanim opuszczą Twoją infrastrukturę.

CO SIĘ ZMIENIA

Przejście z client-side na server-side - cztery realne zmiany

Co dokładnie poprawia się w pomiarze konwersji po przeniesieniu tagów na serwer.

PrzedCookies żyją 7 dni (ITP)

PoFirst-party cookie 400+ dni

Przed30-35% danych blokowane

PoRuch z własnej subdomeny

PrzedKilkanaście skryptów JS

PoJeden lekki endpoint

PrzedZgody per tag w przeglądarce

PoConsent Mode na serwerze

Ważne zastrzeżenie, o którym mówię każdemu klientowi: wzrost śledzonych konwersji o kilkadziesiąt procent nie oznacza nagle tylu samych nowych klientów. To konwersje, które wcześniej się realizowały, ale nie były raportowane. Efekt na Smart Bidding jest jednak realny - algorytm z pełniejszymi danymi szybciej rozpoznaje wzorce i celniej rozdziela stawki, co przekłada się na twardy spadek CPA.

Co musisz przygotować przed wdrożeniem?

Wdrożenie server-side tagging wymaga kilku elementów technicznych, które muszą być gotowe, zanim zaczniesz konfigurację. Brak któregokolwiek zatrzyma proces w połowie i wymusi cofanie zmian.

W mojej codziennej praktyce widzę, że firmy startujące bez tej listy tracą 2-3 tygodnie na problemy, które dało się przewidzieć w pierwszej godzinie.

• Konto GCP lub Stape.io: Google Cloud Platform z aktywnym billingiem (darmowy tier wystarczy na start) albo konto Stape.io z planem od około 20 USD miesięcznie.
• Subdomena niestandardowa: rekord DNS typu A lub CNAME wskazujący sst.twojadomena.pl na serwer GTM. Bez niej cookies traktowane są jak third-party i tracisz połowę korzyści.
• Consent Mode v2 na stronie: baner cookie przekazujący ad_user_data i ad_personalization. Bez tego Google Ads nie przetworzy konwersji poprawnie dla ruchu z EOG.
• Dostęp administratora do obu kontenerów: uprawnienia do tworzenia tagów, reguł i zmiennych w GTM Web i GTM Server.
• Zmapowane kluczowe konwersje: lista zdarzeń, które faktycznie liczysz (purchase, lead, rejestracja), żeby nie przenosić na serwer szumu zamiast wartości.

Jeśli rozpoznajesz, że masz baner zgód, ale nie masz pewności, czy przekazuje właściwe parametry - to dokładnie ten element, który weryfikuję na starcie każdego wdrożenia. Consent Mode skonfigurowany połowicznie potrafi wyzerować część konwersji mimo poprawnie działającego serwera.

Jak krok po kroku wdrożyć server-side GTM?

Wdrożenie server-side GTM sprowadza się do czterech etapów: utworzenia kontenera serwerowego, konfiguracji hostingu z subdomeną, przekierowania tagów z kontenera webowego i testów przed uruchomieniem produkcyjnym.

Na Stape.io cały proces zajmuje 2-4 godziny, przy ręcznej konfiguracji Cloud Run - około 1-2 dni robocze. Kolejność ma znaczenie, bo pominięcie subdomeny na etapie hostingu wymusza późniejsze przerabianie całej konfiguracji cookies.

WDROŻENIE KROK PO KROKU

Cztery etapy uruchomienia serwera GTM

Rozwiń każdy krok, żeby zobaczyć, co konkretnie zrobić i na co uważać.

1Utwórz kontener Server w GTM

W tagmanager.google.com wybierz Utwórz kontener i typ Server. GTM wygeneruje Container Config - ciąg, który wkleisz w hostingu w kroku drugim. To jedyny moment, w którym łączysz logikę pomiaru z infrastrukturą.

2Skonfiguruj hosting i subdomenę

Na Stape.io wklej Container Config, wybierz plan i dodaj domenę sst.twojadomena.pl. Na Cloud Run uruchom deployment z obrazu Docker i skonfiguruj custom domain z certyfikatem SSL. Rekord DNS (CNAME lub A) to serce first-party cookies - bez niego reszta traci sens.

3Przekieruj tagi z kontenera webowego

W kontenerze Web ustaw transport_url tagu Google na https://sst.twojadomena.pl. Następnie w kontenerze Server dodaj tagi Google Ads Conversion i GA4 z regułami na właściwe zdarzenia. Od tej chwili dane płyną przez Twój serwer, a nie wprost do Google.

4Przetestuj w Preview i uruchom

Uruchom Preview Mode serwera i sprawdź, czy zdarzenia docierają na endpoint, a konwersje pojawiają się w Google Tag Assistant. Zostaw oba systemy równolegle na 2-4 tygodnie, porównaj dane i dopiero wtedy wyłącz stare tagi client-side.

Rekomenduję podejście, w którym kontener webowy i serwerowy działają obok siebie przez pełny cykl konwersji, zanim odetniesz ścieżkę przeglądarkową. To okno pozwala porównać liczby jeden do jednego i wychwycić duplikaty, zanim staną się problemem w raportach.

Jak skonfigurować kluczowe tagi w kontenerze serwerowym?

Konfiguracja tagów w kontenerze serwerowym różni się od webowej - pracujesz z żądaniami HTTP zamiast ze skryptami JavaScript.

Kluczowe jest poprawne mapowanie zdarzeń z kontenera webowego na tagi serwerowe, żeby konwersja trafiała do Google Ads z kompletem parametrów: identyfikatorem konwersji, GCLID, danymi Enhanced Conversions i sygnałami zgody. Pominięcie choćby jednego z nich powoduje, że konwersja co prawda się liczy, ale bez pełnego dopasowania.

• Tag Google Ads Conversion: z poprawnym Conversion ID i Conversion Label, wyzwalany na zdarzeniu z kontenera webowego, nie na page_view.
• Enhanced Conversions włączone serwerowo: to najczęściej pomijany element, a właśnie on podnosi match rate o kilkanaście do dwudziestu kilku procent.
• Zmienna cookie_domain ustawiona na auto: żeby first-party cookie było przypisane do Twojej domeny głównej, a nie tylko subdomeny.
• Wyłączony debug_mode na produkcji: zostawiony obciąża serwer i generuje niepotrzebne żądania w Cloud Run.

Uważam, że najgroźniejszy błąd na tym etapie jest jednocześnie najmniej widoczny: reklamodawcy włączają Enhanced Conversions w kontenerze webowym i zakładają, że po przejściu na serwer nadal działają. Nie działają, jeśli nie skonfigurujesz ich w kontenerze serwerowym osobno. W pracy z moimi klientami Google Ads sama ta poprawka potrafiła podnieść współczynnik dopasowania konwersji o 15-25 procent bez żadnej zmiany w kampaniach.

Jakie mity i błędy najczęściej psują wdrożenie SST?

Najczęstszy błąd przy server-side tagging to duplikowanie konwersji - tagi w kontenerze webowym nadal wysyłają dane wprost do Google Ads, a serwer wysyła te same zdarzenia równolegle.

Efekt jest odwrotny do zamierzonego: zamiast odzyskać dane, zawyżasz je i wprowadzasz Smart Bidding w błąd. Zanim jednak omówimy błędy techniczne, warto rozprawić się z mitami, które sprawiają, że firmy albo odkładają wdrożenie, albo robią je źle.

MITY VS FAKTY

Trzy przekonania, które opóźniają lub psują wdrożenie

Skąd biorą się te mity i dlaczego kosztują reklamodawców realne pieniądze.

MitServer-side tagging to rozwiązanie tylko dla dużych korporacji.

FaktDarmowy tier Cloud Run i tanie plany Stape.io sprawiają, że SST opłaca się już przy budżecie Google Ads rzędu kilku tysięcy złotych miesięcznie.

✓

MitSST sztucznie zawyża liczbę konwersji.

FaktSST nie tworzy konwersji - odzyskuje te, które ginęły w przeglądarce. Zawyżanie to objaw błędu (duplikacji), a nie cecha metody.

✓

MitPo wdrożeniu SST można od razu wyłączyć tagi client-side.

FaktPotrzebny jest okres równoległy 2-4 tygodni na weryfikację danych - wyłączenie client-side na ślepo to najczęstsza przyczyna utraty konwersji.

✓

Poza mitami są też twarde pułapki techniczne. Przez lata audytowania kont Google Ads widziałem, że najwięcej wdrożeń wykłada się na czterech powtarzalnych punktach:

• Domyślny URL Cloud Run zamiast subdomeny: adres typu gtm-xxxxx.a.run.app sprawia, że cookies znów są third-party i ITP je skraca.
• Enhanced Conversions tylko w kontenerze web: dane o użytkowniku nie docierają do Google, więc dopasowanie stoi w miejscu.
• Debug mode na produkcji: spowalnia serwer i nabija żądania, za które płacisz.
• Brak monitoringu: serwer GTM to infrastruktura - bez alertów na błędy HTTP 5xx i limity instancji dowiadujesz się o awarii z braku konwersji, a nie z powiadomienia.

„Największy paradoks server-side tagging jest taki, że firmy wdrażają go, by odzyskać utracone dane konwersji, a przez błędną konfigurację tracą ich jeszcze więcej niż przed wdrożeniem.” - własna obserwacja z audytów ponad 30 wdrożeń SST z ostatnich dwóch lat.

Ile kosztuje server-side tagging i czy się opłaca?

Koszt server-side tagging zależy od platformy hostingowej i wolumenu ruchu. Dla typowego sklepu e-commerce z ruchem 50-200 tysięcy sesji miesięcznie to od 20 do 100 USD miesięcznie na Stape.io lub 30-150 USD na Cloud Run.

Przy budżecie Google Ads powyżej kilku tysięcy złotych inwestycja zwraca się zwykle w ciągu pierwszego miesiąca dzięki lepszym danym dla Smart Bidding.

Konkretny przykład z konta, które audytowałem - sklep z elektroniką konsumencką prowadzący aktywne kampanie Search i PMax. Po wdrożeniu SST liczby wyglądały tak:

• Koszt hostingu: plan Stape.io około 40 USD miesięcznie, czyli w przeliczeniu niecałe 170 zł.
• Wzrost śledzonych konwersji: z 420 do 640 miesięcznie, czyli o 52 procent.
• Spadek CPA: z 83 zł do 55 zł, czyli o 34 procent, dzięki pełniejszym danym dla Smart Bidding.
• Efekt netto: ten sam budżet zaczął generować istotnie więcej rozpoznanych konwersji przy niższym koszcie za każdą z nich.

Do kosztu bieżącego dochodzi jednorazowe wdrożenie przez specjalistę, zwykle w przedziale 2000-5000 zł. Jeśli jednak Twoja agencja lub specjalista Google Ads ma doświadczenie z SST, wdrożenie bywa częścią standardowej usługi optymalizacji konta - i wtedy realny koszt wejścia jest znacznie niższy niż zysk z odzyskanych danych.

Podsumowanie

Server-side tagging to nie technologiczny gadżet, lecz zmiana fundamentu, na którym Twoje kampanie Google Ads zbierają dane o konwersjach.

W świecie, w którym ad blockery, ITP i regulacje prywatności zjadają coraz większą część pomiaru, przeniesienie tagów na serwer jest najskuteczniejszą odpowiedzią na utratę widoczności konwersji.

Przestań traktować server-side tagging jak zaawansowaną opcję dla dużych firm. Zacznij postrzegać go jak standardowy element infrastruktury reklamowej - tak samo jak śledzenie konwersji czy remarketing. Każdy miesiąc bez SST to miesiąc, w którym Smart Bidding decyduje o Twoim budżecie na podstawie niepełnych danych.

Jeśli Twój miesięczny budżet Google Ads przekracza kilka tysięcy złotych, wdrożenie server-side tagging powinno być jednym z pierwszych zadań na liście optymalizacji, a nie ostatnim. Wszystkie inne działania - struktura kampanii, teksty reklam, strategie stawek - opierają się na danych, które bez SST są po prostu dziurawe. Zacznij od naprawienia pomiaru, a reszta optymalizacji zadziała mocniej.

Decyzja o server-side tagging jest kosztowna i trudna do odkręcenia, więc warto ją podjąć świadomie. Rozkładam ją na czynniki podczas konsultacji Google Ads.

Na czym opieram te wnioski

Źródła i dokumentacja

Server-side tagging to temat, w którym łatwo o obietnice bez pokrycia, dlatego pod każdy techniczny fragment tego artykułu podpinam źródło pierwotne: badanie mierzące realne wdrożenia, dokumentację nagłówka odpowiedzialnego za first-party cookies oraz oficjalne instrukcje Google dla kontenera serwerowego i konwersji rozszerzonych.

arxiv.org

Badanie skali server-side Google Analytics

Praca SST-Guard opisuje metodę wykrywania pomiaru serwerowego po sygnaturach żądań, cookies i obiektu window, a następnie mierzy jego zasięg: 4,02 procent domen z Tranco top 10 tysięcy i 4,21 procent z top 150 tysięcy. To niezależne potwierdzenie tez z pierwszej sekcji o różnicy między client-side a server-side i o tym, że ruchu z własnej domeny nie da się blokować tak łatwo jak skryptów zewnętrznych.

arXiv Otwórz

developer.mozilla.org

Dokumentacja nagłówka Set-Cookie

Referencja MDN opisuje atrybuty Expires, Max-Age, Domain i HttpOnly, czyli dokładnie ten mechanizm, którym serwer GTM ustawia trwałe first-party cookie zamiast zapisu przez document.cookie. Techniczna podstawa drugiej sekcji, gdzie tłumaczę, dlaczego cookies ustawiane serwerowo nie podlegają siedmiodniowemu limitowi ITP w Safari.

MDN Web Docs Otwórz

developers.google.com

Konfiguracja własnej domeny serwera GTM

Oficjalna dokumentacja porównuje wariant tej samej domeny i subdomeny, opisuje wymagane wpisy DNS oraz wyjaśnia, dlaczego domyślny adres dostawcy odbiera pełny dostęp do cookies. Punkt odniesienia dla drugiego kroku wdrożenia z piątej sekcji, w którym rekord DNS na sst.twojadomena.pl decyduje o powodzeniu całej reszty.

Google for Developers Otwórz

support.google.com

Konwersje rozszerzone w Google Ads

Pomoc Google Ads opisuje, jakie dane pierwszej strony trafiają do systemu, że są hashowane algorytmem SHA256 oraz które identyfikatory (email, telefon, adres) podnoszą współczynnik dopasowania. Bezpośrednie zaplecze szóstej sekcji o konfiguracji tagów w kontenerze serwerowym, gdzie tłumaczę, dlaczego Enhanced Conversions trzeba włączyć osobno po stronie serwera.

Google Ads Help Otwórz

Najczęściej zadawane pytania

Pytania i odpowiedzi (FAQ)

Server-side tagging bez zaplecza programistycznego: zgodność z RODO i realny czas wdrożenia.

01Czy server-side tagging wymaga wiedzy programistycznej?

Podstawowe wdrożenie na Stape.io nie wymaga umiejętności programistycznych - platforma prowadzi przez cały proces. Konfiguracja na Cloud Run wymaga podstawowej znajomości konsoli GCP i DNS. Najbardziej techniczna część to podpięcie subdomeny, do którego potrzebujesz dostępu do panelu DNS.

02Czy server-side tagging jest zgodny z RODO?

Tak, o ile poprawnie skonfigurujesz Consent Mode v2. Serwer GTM respektuje sygnały zgody i nie wysyła danych do platform reklamowych bez odpowiedniej zgody. SST daje Ci nawet większą kontrolę, bo możesz filtrować i anonimizować dane na serwerze przed wysłaniem.

03Ile trwa wdrożenie server-side tagging?

Na Stape.io podstawowe wdrożenie zajmuje 2-4 godziny, na Cloud Run 1-2 dni robocze. Do tego dochodzi 2-4 tygodnie równoległego działania obu systemów, zanim bezpiecznie wyłączysz stare tagi client-side.

04Czy server-side tagging działa z Performance Max?

Tak, SST jest w pełni kompatybilny z Performance Max. PMax szczególnie korzysta z lepszych danych konwersji, bo jego algorytm mocno opiera się na sygnałach konwersji przy alokacji budżetu między Search, Shopping, Display i YouTube.

05Stape.io czy Google Cloud Run - co wybrać przy małym zespole?

Bez zespołu DevOps wybierz Stape.io - prosta konfiguracja, automatyczne aktualizacje i wsparcie techniczne. Cloud Run daje większą kontrolę i niższe koszty przy dużym ruchu, ale wymaga zarządzania infrastrukturą chmurową. Dla większości sklepów rekomenduję Stape.io.

06Czy server-side tagging trzeba utrzymywać po wdrożeniu?

Tak - serwer wymaga monitorowania kosztów, aktualizacji kontenera i reakcji na zmiany w API dostawców. To nie jest wdrożenie jednorazowe. Przy hostowanych rozwiązaniach większość utrzymania bierze na siebie dostawca, przy własnej infrastrukturze zostaje po stronie firmy.

Ten wpis należy do obszaru Pomiar i analityka - zobacz pozostałe teksty z tego obszaru albo wróć do bazy wiedzy Google Ads.

---