{"id":10136,"date":"2026-09-13T18:24:00","date_gmt":"2026-09-13T16:24:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10136"},"modified":"2026-09-09T13:23:44","modified_gmt":"2026-09-09T11:23:44","slug":"tutorial-migracja-analityki-e-commerce-z-client-side-na-server-side-gtm","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/tutorials-pl\/tutorial-migracja-analityki-e-commerce-z-client-side-na-server-side-gtm\/","title":{"rendered":"Tutorial: Migracja analityki e-commerce z Client-Side na Server-Side GTM"},"content":{"rendered":"

Ka\u017cdy sklep ze \u015bledzeniem po stronie klienta raportuje mniej zakup\u00f3w, ni\u017c faktycznie realizuje. Ta luka nie jest b\u0142\u0119dem do wytropienia: \u017c\u0105dania do znanych host\u00f3w analitycznych figuruj\u0105 na listach filtr\u00f3w, ochrona przed \u015bledzeniem skraca \u017cycie identyfikuj\u0105cego pliku cookie, a osoba zamykaj\u0105ca kart\u0119, zanim strona potwierdzenia sko\u0144czy si\u0119 renderowa\u0107, w og\u00f3le nie wysy\u0142a zdarzenia. Kontener serwerowy zmienia to, kt\u00f3r\u0119dy biegn\u0105 dane, i pokrywa tym cz\u0119\u015b\u0107 problemu \u2014 przeniesienie zdarzenia zakupu poza przegl\u0105dark\u0119 pokrywa reszt\u0119.<\/p>\n

Poni\u017cszy przewodnik traktuje to jako migracj\u0119, a nie budow\u0119 od zera: dotychczasowa konfiguracja client-side pozostaje aktywna przez ca\u0142y czas, obie dzia\u0142aj\u0105 r\u00f3wnolegle wystarczaj\u0105co d\u0142ugo, by da\u0142o si\u0119 je por\u00f3wna\u0107, a prze\u0142\u0105czenie nast\u0119puje dopiero wtedy, gdy uzasadniaj\u0105 je liczby.<\/p>\n

\n\"Trzy
Przeniesienie kontenera czyni dane sterowalnymi; przeniesienie zakupu poza przeglądarkę czyni je kompletnymi.<\/figcaption><\/figure>\n

Krok 1: Uruchomi\u0107 obie, prze\u0142\u0105czy\u0107 p\u00f3\u017aniej<\/h2>\n

Najbezpieczniejsza kolejno\u015b\u0107 wysy\u0142a dane do kontenera serwerowego, podczas gdy konfiguracja client-side nadal raportuje do tej samej albo do r\u00f3wnoleg\u0142ej us\u0142ugi. Nic nie jest usuwane, \u017cadne tagi nie s\u0105 wstrzymywane, a por\u00f3wnanie dzia\u0142a na realnym ruchu, a nie w trybie podgl\u0105du.<\/p>\n

Druga us\u0142uga GA4 jako cel migracji utrzymuje produkcyjne liczby w czysto\u015bci na czas nak\u0142adania si\u0119 \u2014 zdublowany zbi\u00f3r danych w us\u0142udze produkcyjnej trudniej p\u00f3\u017aniej rozpl\u0105ta\u0107, ni\u017c wyrzuci\u0107 tymczasow\u0105 drug\u0105 us\u0142ug\u0119. Dwa do czterech tygodni nak\u0142adania obejmuje wzorce dni roboczych i weekend\u00f3w oraz co najmniej jeden pe\u0142ny cykl zakupowy.<\/p>\n

Krok 2: Postawienie serwera taguj\u0105cego<\/h2>\n

W interfejsie GTM kontener serwerowy powstaje jako osobny typ kontenera, a jego ustawienia oferuj\u0105 automatyczne udost\u0119pnienie w Google Cloud Run. Droga automatyczna jest wygodna i daje dzia\u0142aj\u0105ce wdro\u017cenie; r\u0119czne wdro\u017cenie tego samego publicznego obrazu daje wi\u0119ksz\u0105 kontrol\u0119 nad regionem i skalowaniem:<\/p>\n

gcloud run deploy sgtm \\\n  --image=gcr.io\/cloud-tagging-10302018\/gtm-cloud-image:stable \\\n  --region=europe-central2 \\\n  --platform=managed \\\n  --allow-unauthenticated \\\n  --set-env-vars=CONTAINER_CONFIG='<config string z ustawien kontenera>'<\/code><\/pre>\n
Domy\u015blne ustawienia s\u0105 skrojone pod testy, a nie pod ruch produkcyjny; flagi instancji i pami\u0119ci to ta cz\u0119\u015b\u0107, do kt\u00f3rej warto wr\u00f3ci\u0107, gdy pojawi si\u0119 realny wolumen. Ka\u017cde \u015brodowisko uruchomieniowe kontener\u00f3w sprawdzi si\u0119 tak samo \u2014 Cloud Run jest udokumentowanym domy\u015blnym wyborem, a nie wymogiem.<\/p>\n
Tym, co nie jest opcjonalne, jest nazwa hosta. Serwer taguj\u0105cy dost\u0119pny wy\u0142\u0105cznie pod wygenerowanym adresem chmurowym jest hostem zewn\u0119trznym jak ka\u017cdy inny; korzy\u015b\u0107 z kontekstu first-party pojawia si\u0119 dopiero, gdy odpowiada on na subdomenie w\u0142asnej domeny sklepu, na przyk\u0142ad sgtm.shop.example.com<\/code>, ze wskazuj\u0105cym na us\u0142ug\u0119 wpisem DNS i przypisanym certyfikatem.<\/p>\n
Krok 3: Klient GA4<\/h2>\n
Kontener serwerowy nie robi nic, dop\u00f3ki jaki\u015b klient nie przejmie przychodz\u0105cych \u017c\u0105da\u0144. Wbudowany klient GA4 nas\u0142uchuje na \u015bcie\u017ckach u\u017cywanych przez tag Google, rozbiera przychodz\u0105cy hit i zamienia go w zdarzenie, kt\u00f3re mog\u0105 odczyta\u0107 tagi serwerowe \u2014 bez niego kontener przyjmuje \u017c\u0105dania i je odrzuca.<\/p>\n
Dwa ustawienia zas\u0142uguj\u0105 na decyzj\u0119 zamiast warto\u015bci domy\u015blnej. Klient mo\u017ce przej\u0105\u0107 wystawianie identyfikuj\u0105cego pliku cookie zamiast zostawia\u0107 to JavaScriptowi \u2014 i to w\u0142a\u015bnie czyni ten plik odpornym na ograniczenia przegl\u0105darek \u2014 a w\u0142\u0105czenie tego bez towarzysz\u0105cej opcji migracji resetuje to\u017csamo\u015b\u0107 ka\u017cdego powracaj\u0105cego odwiedzaj\u0105cego, wi\u0119c nale\u017cy to do osobnej zmiany z w\u0142asn\u0105 weryfikacj\u0105. Drugie dotyczy \u015bcie\u017cek: pozostawienie domy\u015blnych \u015bcie\u017cek bez zmian jest tym, co pozwala kontenerowi webowemu wysy\u0142a\u0107 hity bez konfigurowania w\u0142asnego endpointu.<\/p>\n
Krok 4: Skierowanie kontenera webowego na serwer<\/h2>\n
Po stronie przegl\u0105darki ruch przekierowuje jedno pole. W tagu Google w kontenerze webowym adres kontenera serwerowego ustawia si\u0119 jako parametr konfiguracji; w czystej implementacji gtag.js odpowiednikiem jest transport_url<\/code>:<\/p>\n
\/\/ Parametr konfiguracji tagu Google (kontener webowy)\nserver_container_url: 'https:\/\/sgtm.shop.example.com'\n\n\/\/ Odpowiednik w czystej implementacji gtag.js\ngtag('config', 'G-XXXXXXXXXX', {\n  server_container_url: 'https:\/\/sgtm.shop.example.com'\n});<\/code><\/pre>\n
Od tego momentu przegl\u0105darka adresuje w\u0142asn\u0105 subdomen\u0119 sklepu, a kontener serwerowy przekazuje dane do GA4. Kontener serwerowy ma w\u0142asny tryb podgl\u0105du, pokazuj\u0105cy przychodz\u0105ce \u017c\u0105danie, klienta, kt\u00f3ry je przej\u0105\u0142, oraz ka\u017cdy odpalony z niego tag \u2014 to miejsce, w kt\u00f3rym \u017ale skierowany hit staje si\u0119 widoczny natychmiast, a nie dob\u0119 p\u00f3\u017aniej w raportach.<\/p>\n
Krok 5: Przeniesienie zakupu poza przegl\u0105dark\u0119<\/h2>\n
Kierowanie ruchu przez w\u0142asn\u0105 subdomen\u0119 ogranicza blokowanie; nie ko\u0144czy go, a wobec odwiedzaj\u0105cego, kt\u00f3ry nigdy nie dociera do strony potwierdzenia, nie pomaga wcale. Dopiero zdarzenie wys\u0142ane przez backend, po potwierdzeniu zam\u00f3wienia w systemie sklepu, jest ca\u0142kowicie niezale\u017cne od przegl\u0105darki.<\/p>\n
To \u017c\u0105danie potrzebuje identyfikator\u00f3w, kt\u00f3re znajduj\u0105 si\u0119 w przegl\u0105darce. Client id z pliku cookie analityki trzeba odczyta\u0107 w checkoucie i zapisa\u0107 przy zam\u00f3wieniu razem z identyfikatorem sesji, inaczej zakup dotrze bez sesji, do kt\u00f3rej m\u00f3g\u0142by si\u0119 przypi\u0105\u0107, i wyl\u0105duje w raportach jako ruch bez \u017ar\u00f3d\u0142a:<\/p>\n
POST https:\/\/sgtm.shop.example.com\/g\/collect\n\nv=2\n&tid=G-XXXXXXXXXX\n&cid=1234567890.1690000000     \/\/ odczytane w checkoucie z pliku cookie analityki\n&sid=1789000000                \/\/ identyfikator sesji z tej samej wizyty\n&en=purchase\n&ep.transaction_id=ORD-10432\n&epn.value=149.00\n&ep.currency=PLN<\/code><\/pre>\n
Je\u015bli ten sam zakup jest wysy\u0142any zar\u00f3wno z przegl\u0105darki, jak i z backendu, identyfikator transakcji musi by\u0107 zgodny, \u017ceby duplikat da\u0142o si\u0119 rozpozna\u0107 i usun\u0105\u0107 dalej w \u0142a\u0144cuchu \u2014 alternatyw\u0105 jest sklep, kt\u00f3rego dane o przychodzie s\u0105 zawy\u017cone dok\u0142adnie o te zdarzenia, kt\u00f3re migracja mia\u0142a odzyska\u0107.<\/p>\n
Krok 6: Por\u00f3wnanie przed wy\u0142\u0105czeniem czegokolwiek<\/h2>\n
Por\u00f3wnanie rozstrzygaj\u0105ce o prze\u0142\u0105czeniu nie brzmi client-side kontra server-side, tylko ka\u017cde z nich kontra liczba zam\u00f3wie\u0144 w sklepie. Konfiguracja serwerowa raportuj\u0105ca wi\u0119cej zakup\u00f3w ni\u017c wcze\u015bniej jest popraw\u0105 tylko wtedy, gdy dodatkowe zakupy odpowiadaj\u0105 realnym zam\u00f3wieniom \u2014 a tabela zam\u00f3wie\u0144 jest punktem odniesienia, kt\u00f3ry to rozstrzyga.<\/p>\n
Typowe obserwacje w okresie nak\u0142adania: liczby zakup\u00f3w rosn\u0105 o margines silnie zale\u017cny od odbiorc\u00f3w i miksu urz\u0105dze\u0144, sesje zyskuj\u0105 na d\u0142ugo\u015bci, bo identyfikuj\u0105cy plik cookie \u017cyje d\u0142u\u017cej, a kilka tag\u00f3w okazuje si\u0119 zale\u017cnych od zmiennych dost\u0119pnych wy\u0142\u0105cznie w przegl\u0105darce, kt\u00f3rych kontener serwerowy nie ma. To w\u0142a\u015bnie te tagi s\u0105 w\u0142a\u015bciw\u0105 prac\u0105 migracyjn\u0105; sam kontener jest cz\u0119\u015bci\u0105 \u0142atw\u0105.<\/p>\n
Pozostaj\u0105c w granicach<\/h2>\n
Kontener serwerowy przenosi przetwarzanie, a nie obowi\u0105zek. Stan zgody musi podr\u00f3\u017cowa\u0107 razem z \u017c\u0105daniem i zosta\u0107 oceniony, zanim odpali jakikolwiek tag, oraz musi by\u0107 zapisany przy zam\u00f3wieniu, \u017ceby zdarzenie backendowe r\u00f3wnie\u017c mog\u0142o go sprawdzi\u0107 \u2014 \u017c\u0105danie wys\u0142ane z serwera nie jest zwolnione dlatego, \u017ce przegl\u0105darka przesta\u0142a bra\u0107 udzia\u0142. Kontener staje si\u0119 te\u017c systemem z bie\u017c\u0105cymi kosztami i dost\u0119pno\u015bci\u0105, od kt\u00f3rej zale\u017cy teraz raportowanie, a wystawiany przez niego identyfikuj\u0105cy plik cookie pozostaje danymi osobowymi na tych samych zasadach co wcze\u015bniej, tylko ustawianymi z innego miejsca.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n