• W projekcie dla klienta z globalnego marketplace’u e-commerce Conversion przeprowadził wdrożenie analityczne skoncentrowane na odzyskaniu widoczności powracających użytkowników na Safari i iOS, gdzie standardowy pomiar zniekształcał obraz retencji i skuteczności marketingu.
• Kluczowym wyzwaniem były ograniczenia prywatności przeglądarek Apple, w tym Intelligent Tracking Prevention, które skracały żywotność cookies analitycznych i powodowały, że użytkownicy wracający po kilku lub kilkunastu dniach byli często rozpoznawani jako nowi.
• Przy ponad 50% ruchu mobilnego pochodzącego z iOS prowadziło to do zaburzeń w ocenie nowych użytkowników, retencji, ścieżek konwersji oraz skuteczności kanałów marketingowych.
• Zespół wdrożył rozwiązanie oparte na Cloudflare reverse proxy oraz server-side Google Tag Managerze, konfigurując środowisko tak, aby żądania narzędzi marketingowych były traktowane jako 1st party i były mniej podatne na ograniczenia przeglądarek.
• Następnie, na bazie eksportu danych z GA4 do BigQuery, porównano zachowanie użytkowników przed i po wdrożeniu, analizując m.in. powroty po ponad 7 dniach, liczbę sesji na użytkownika oraz różnice między przeglądarkami i urządzeniami.
• Efektem było odzyskanie widoczności realnych powrotów użytkowników na urządzeniach Apple: liczba rozpoznanych powrotów po 8 lub więcej dniach wzrosła z 33 do 451.
• Jednocześnie nie oznaczało to nagłego wzrostu liczby powracających użytkowników, lecz to, że system analityczny zaczął wreszcie poprawniej rozpoznawać zachowania, które wcześniej były ukryte przez ograniczenia technologiczne Safari i iOS.
• Projekt potwierdził, że w globalnym e-commerce poprawa jakości identyfikacji użytkowników może mieć bezpośredni wpływ na wiarygodność decyzji marketingowych.

Punkt wyjścia

Nasz klient działa w modelu globalnego marketplace’u e-commerce. Sprzedaje klucze do gier i oprogramowania klientom indywidualnym na wielu rynkach, współpracując jednocześnie z wieloma partnerami.

Przy takiej skali dane marketingowe są jednym z kluczowych elementów zarządzania biznesem. To na ich podstawie zespół podejmuje decyzje o budżetach reklamowych, kanałach, retargetingu i ocenie skuteczności działań performance.

Problem polegał na tym, że część tych danych mogła nie pokazywać rzeczywistości.

Szczególnie dotyczyło to użytkowników korzystających z urządzeń Apple’a iOS odpowiadał za ponad 50% całego ruchu mobilnego na stronie klienta.

Problem: powracający użytkownicy wyglądali jak nowi

Klient korzystał z danych w GA4 do oceny skuteczności marketingu. Jednak w przypadku Safari i przeglądarek na iOS pojawiał się istotny problem technologiczny.

Mechanizmy ochrony prywatności, w tym Intelligent Tracking Prevention, ograniczają żywotność cookies analitycznych. W praktyce oznacza to, że użytkownik, który odwiedził stronę, a następnie wrócił po kilku lub kilkunastu dniach, mógł zostać rozpoznany jako zupełnie nowa osoba.

Dla biznesu to nie jest techniczny detal. Jeśli system nie rozpoznaje użytkowników powracających, zaczyna zniekształcać podstawowe wnioski o marketingu.

Nowych użytkowników wydaje się być więcej, niż jest w rzeczywistości. Retencja wygląda gorzej, niż powinna. Ścieżki konwersji na iOS i Safari stają się mniej wiarygodne. Kanały, które skutecznie przyciągają użytkowników z powrotem, mogą być niedoceniane. A działania nastawione na pozyskanie nowych klientów mogą wyglądać na skuteczniejsze, niż są w rzeczywistości.

W efekcie decyzje o budżetach, retargetingu i ocenie kanałów były podejmowane na danych, które w przypadku istotnej części ruchu mobilnego mogły być zaburzone.

Nasze zadanie: dane powinny lepiej oddawać rzeczywiste zachowanie użytkowników

Celem projektu było poprawienie jakości identyfikacji użytkowników na Safari i iOS. Nie chodziło o „wyprodukowanie” lepszych wyników w raportach. Chodziło o to, żeby klient mógł zobaczyć to, co faktycznie działo się na stronie: że część osób wracała po kilku, kilkunastu lub ponad dwudziestu dniach – tylko wcześniej system analityczny nie zawsze potrafił ich poprawnie rozpoznać.

Wdrożyliśmy rozwiązanie oparte na Cloudflare reverse proxy oraz server-side Google Tag Managerze.

W uproszczeniu: skonfigurowaliśmy środowisko tak, aby żądania narzędzi marketingowych były traktowane jako 1st party, czyli jako bliżej powiązane z domeną klienta. Dzięki temu ograniczenia przeglądarek miały mniejszy wpływ na trwałość identyfikatorów analitycznych.

Architektura rozwiązania wyglądała następująco:

strona klienta → Cloudflare i konfiguracja DNS → server-side GTM na Cloud Run → GA4

Do analizy wykorzystaliśmy eksport danych z GA4 do BigQuery. Dzięki temu mogliśmy porównać sytuację przed i po wdrożeniu nie tylko na poziomie ogólnych metryk, ale przede wszystkim na poziomie zachowania użytkowników.

Sprawdzaliśmy między innymi:

• ilu użytkowników wracało po więcej niż 7 dniach,
• jak wyglądała liczba sesji na użytkownika,
• jak zmieniała się powracalność według przeglądarki,
• jak różniły się dane dla urządzeń mobilnych i desktopowych,
• czy Safari i iOS zaczęły pokazywać bardziej realistyczny obraz powrotów.

Wyniki analizy zostały przedstawione w Google Sheets, w formie pozwalającej zespołowi klienta łatwo porównać dane przed i po wdrożeniu.

Największe wyzwanie: tego efektu nie widać na pierwszy rzut oka w GA4

Reverse proxy nie jest typem wdrożenia, którego efekt można łatwo ocenić po jednym wykresie w standardowym panelu GA4.

Jeśli po wdrożeniu rośnie liczba sesji, użytkowników albo zdarzeń, nie oznacza to automatycznie, że odpowiada za to reverse proxy. Ruch może wzrosnąć z wielu powodów: kampanii reklamowych, sezonowości, promocji, zmian w budżetach czy naturalnych wahań popytu.

Dlatego kluczowe było zejście głębiej – do danych w BigQuery – i sprawdzenie konkretnego zachowania: czy użytkownicy wracający po okresie dłuższym niż 7 dni są lepiej rozpoznawani jako te same osoby.

To właśnie tam było widać realny efekt projektu.

Efekt: klient zobaczył powroty, których wcześniej nie widział

Przed wdrożeniem, gdy użytkownik korzystający z Safari lub iOS odwiedził stronę, a następnie wrócił na przykład po 10 dniach, GA4 często nie rozpoznawało go jako tej samej osoby. Cookie zdążyło wygasnąć, więc użytkownik dostawał nowy identyfikator.

W analizowanym okresie przed wdrożeniem zarejestrowano tylko 33 rozpoznane powroty użytkowników po 8 lub więcej dniach.

Po wdrożeniu reverse proxy takich powrotów było już 451.

To bardzo ważne: nie oznacza to, że nagle pojawiło się kilkanaście razy więcej powracających użytkowników.

Oznacza to, że ci użytkownicy najprawdopodobniej wracali już wcześniej, ale GA4 ich nie rozpoznawało. Po wdrożeniu system zaczął widzieć zachowania, które wcześniej były ukryte przez ograniczenia technologiczne przeglądarki.

Dzięki temu klient uzyskał bardziej wiarygodny obraz retencji, powracalności i ścieżek użytkowników na urządzeniach Apple.

Co zmieniło się biznesowo?

Po wdrożeniu klient może podejmować decyzje marketingowe na podstawie danych, które lepiej pokazują realne zachowania użytkowników. Zespół marketingu ma większą pewność, że osoba wracająca po 10, 15 czy 23 dniach na Safari lub iOS nie zostanie automatycznie potraktowana jako nowy użytkownik.

To przekłada się na lepszą ocenę:

• które kanały rzeczywiście pozyskują nowych użytkowników,
• które kanały wspierają powroty i konwersję w dłuższym czasie,
• jak wygląda retencja na urządzeniach Apple,
• jak interpretować ścieżki konwersji dla dużej części ruchu mobilnego,
• jak planować budżety reklamowe i retargeting.

Najważniejsza zmiana nie polegała więc na poprawieniu jednego wskaźnika w raporcie. Najważniejsze było odzyskanie zaufania do danych, na podstawie których podejmowane są decyzje marketingowe.

Podsumowanie

W globalnym e-commerce nawet niewielkie zniekształcenie danych może prowadzić do dużych konsekwencji biznesowych. Szczególnie wtedy, gdy dotyczy kanałów i urządzeń odpowiadających za znaczącą część ruchu.

W tym przypadku problemem nie było to, że użytkownicy nie wracali.

Problemem było to, że analityka nie zawsze była w stanie ich rozpoznać.

Dzięki wdrożeniu Cloudflare reverse proxy i server-side GTM klient zaczął widzieć znacznie więcej realnych powrotów użytkowników na Safari i iOS. Liczba rozpoznanych powrotów po 8+ dniach wzrosła z 33 do 451.

To dało zespołowi marketingu solidniejszą podstawę do oceny retencji, kanałów, remarketingu i alokacji budżetów.

Bo w analityce marketingowej nie chodzi tylko o to, żeby mieć dane.
Chodzi o to, żeby dane pokazywały rzeczywistość, a nie ograniczenia technologii.

The post Case Study – Jak odzyskaliśmy widoczność powracających użytkowników na iOS i Safari first appeared on Conversion.

• W projekcie dla klienta z branży Health & Beauty / FMCG Conversion wykorzystał wcześniej wdrożoną architekturę server-side GTM, aby uruchomić dodatkowy pomiar konwersji zakupowych dla wybranych marek promowanych w aplikacji mobilnej.
• Kluczowym wyzwaniem była potrzeba szybkiego wdrożenia nowej logiki analitycznej bez angażowania zespołu IT, bez zmian w kodzie aplikacji i bez czekania na release oraz aktualizacje po stronie użytkowników.
• Dodatkowo pierwsze próby budowy zdarzenia po stronie aplikacji nie dawały kompletnych danych.
• Zespół przeanalizował dane przesyłane z aplikacji, opracował logikę identyfikującą transakcje dla wskazanych marek i przygotował dodatkowe zdarzenie zakupowe w warstwie server-side GTM, dbając o poprawność danych i zgodność z wymaganiami ekosystemu Google.
• Całość wdrożono bez angażowania zespołu developerskiego klienta.
• Efektem było znaczące skrócenie czasu wdrażania zmian analitycznych, większa elastyczność przy działaniach promocyjnych i partnerskich oraz mniejsze uzależnienie marketingu i analityki od backlogu IT.
• Klient zyskał możliwość uruchamiania nowych konwersji zakupowych w aplikacji bez każdorazowego wydawania nowej wersji aplikacji.
• Projekt potwierdził, że dobrze zaprojektowana architektura server-side GTM może nie tylko poprawiać jakość pomiaru, ale też realnie zwiększać szybkość działania biznesu i przewagę operacyjną w środowisku retailowym.

Punkt wyjścia

W retailu i marketingu cyfrowym sama dostępność danych to za mało. Równie ważna jest możliwość szybkiego reagowania na potrzeby biznesu. Problem zaczyna się wtedy, gdy nawet drobna zmiana w analityce wymaga zaangażowania zespołu IT, publikacji nowej wersji aplikacji i czekania, aż użytkownicy ją zaktualizują.

W tym przypadku klient potrzebował uruchomić dodatkowy pomiar konwersji zakupowych dla wybranych marek promowanych w aplikacji mobilnej. Na pierwszy rzut oka była to niewielka modyfikacja. W praktyce mogła jednak oznaczać długi proces po stronie developmentu i znacznie ograniczyć tempo działania biznesu.

Dzięki temu, że wcześniej wdrożyliśmy server-side GTM, mogliśmy podejść do tego inaczej – szybciej, sprawniej i bez konieczności wprowadzania zmian w kodzie aplikacji.

Wyzwanie: nowa konwersja, stary problem

Klient działa na polskim rynku w modelu retail, w segmencie Health & Beauty / FMCG. W projekcie współpracowaliśmy bezpośrednio z osobą odpowiedzialną za analitykę online w obszarze Marketingu, MarTech & Own Media.

Potrzeba biznesowa była jasna: uruchomić dodatkowe konwersje zakupowe dla transakcji obejmujących wybrane marki, tak aby dokładniej mierzyć skuteczność działań promocyjnych prowadzonych w aplikacji mobilnej. Wydawałoby się proste, a jednak.

W tym projekcie pojawiły się dwa kluczowe ograniczenia. Po pierwsze, dostępność zespołu IT była ograniczona, co utrudniało szybkie wdrażanie zmian. Po drugie, pierwsze próby przygotowania dodatkowego zdarzenia po stronie aplikacji nie dały oczekiwanego efektu — zdarzenia były niekompletne i nie zawierały wszystkich parametrów potrzebnych do dalszego wykorzystania.

To oznaczało realne ryzyko, że zmiana, która biznesowo powinna być szybka i operacyjna, utknie w procesie developmentu, testów, publikacji nowej wersji aplikacji i oczekiwania na aktualizacje po stronie użytkowników

Rozwiązanie: więcej z danych, mniej pracy po stronie aplikacji

Klient miał już wcześniej wdrożony server-side GTM dla aplikacji mobilnej, który zrealizowaliśmy w ramach naszej współpracy. Dzięki temu mieliśmy solidną bazę do kolejnych działań.

Zamiast ingerować w kod aplikacji, zaproponowaliśmy wykorzystanie istniejącej architektury server-side, która daje pełną kontrolę nad danymi jeszcze zanim trafią one na serwery Google. Dzięki temu nie trzeba było przebudowywać aplikacji — wykorzystaliśmy istniejącą warstwę pośredniczącą, by przetworzyć i rozszerzyć dane, które już były zbierane z aplikacji.

Po naszej stronie zakres prac obejmował:

• analizę danych przesyłanych z aplikacji,
• opracowanie logiki identyfikującej transakcje dotyczące wskazanych marek,
• przygotowanie dodatkowego zdarzenia zakupowego w warstwie server-side GTM,
• zadbanie o poprawność i zgodność danych z wymaganiami ekosystemu Google.

Całość wdrożyliśmy bez konieczności angażowania zespołu developerskiego klienta.

W praktyce oznaczało to, że zamiast przebudowywać aplikację, wykorzystaliśmy istniejącą warstwę pośredniczącą do przetworzenia i rozszerzenia danych, które były już zbierane z aplikacji.

Klasyczny model vs. nasze podejście

Klasyczny model:

• angażuje zespół IT i zwiększa koszty implementacji,
• wymaga zmian w kodzie aplikacji,
• oznacza testy i nowy release,
• zależy od aktualizacji aplikacji przez użytkowników,
• utrudnia szybkie reagowanie na potrzeby biznesu.

Nasze podejście:

• wykorzystuje istniejącą architekturę server-side,
• nie wymaga zmian w kodzie aplikacji,
• pozwala wdrażać logikę po stronie GTM,
• uruchamia zmiany bez czekania na aktualizację aplikacji,
• daje większą elastyczność i krótszy time-to-market.

To podejście okazało się szczególnie wartościowe także dlatego, że w trakcie projektu pojawiła się potrzeba zmiany listy marek objętych dodatkową logiką. W klasycznym modelu oznaczałoby to kolejny cykl developmentu i następny release aplikacji. W naszym modelu mogliśmy zareagować znacznie szybciej.

Efekt: szybsze wdrożenia, większa elastyczność, mniej zależności od IT

Najważniejsza zmiana polegała na tym, że Klient zyskał możliwość uruchamiania nowych konwersji zakupowych w aplikacji bez każdorazowego angażowania developerów i bez wydawania nowej wersji aplikacji.

Biznesowo przełożyło się to na:

• krótszy czas wdrażania zmian analitycznych,
• większą elastyczność przy działaniach promocyjnych i partnerskich,
• mniejsze uzależnienie marketingu i analityki od backlogu IT,
• możliwość szybszego uruchamiania pomiaru pod konkretne potrzeby kampanijne.

W środowisku retailowym, gdzie okna decyzyjne są krótkie, a działania promocyjne wymagają szybkiej reakcji, to realna przewaga operacyjna. Dzięki server-side GTM klient nie musiał wybierać między jakością danych a tempem działania.

Big Picture: więcej niż jednorazowe wdrożenie

Ten case nie był jednorazowym obejściem problemu. Potwierdził wartość wcześniej wdrożonej architektury ssGTM – zarówno po stronie webu, jak i aplikacji mobilnej.

I właśnie to jest najważniejszy wniosek z całego projektu: dobrze zaprojektowana architektura analityczna nie tylko zbiera dane. Daje biznesowi większą kontrolę, skraca czas reakcji i pozwala szybciej przekładać potrzeby marketingowe na konkretne działania.

The post Case Study – Gdy analityka musi nadążać za biznesem first appeared on Conversion.

Branża: Platforma medyczna
Klient: House-Med S.A. (Kraków, Polska)
Strona: www.upacjenta.pl

Punkt wyjścia

W dojrzałym marketingu dane nie mogą być „w przybliżeniu poprawne”. Muszą być wystarczająco precyzyjne, by dało się na nich oprzeć decyzje dotyczące budżetu, efektywności kanałów i wzrostu.

Właśnie z takim wyzwaniem zmierzył się upacjenta.pl – dynamicznie rozwijający się serwis z obszaru medycznego i e-commerce, działający w środowisku, w którym kluczowe znaczenie mają zarówno jakość pomiaru, jak i kontrola nad prywatnością danych.

Dotychczasowy model śledzenia opierał się na klasycznym podejściu client-side. W praktyce oznaczało to rosnącą podatność na blokowanie przez przeglądarki, adblocki i mechanizmy ochrony prywatności.

Efekt był prosty: część danych nie docierała do narzędzi analitycznych, a część traciła swoją wartość przez błędy atrybucji i niespójność sesji.

Dlatego celem projektu nie było wyłącznie wdrożenie nowej technologii, ale przede wszystkim przywrócenie wiarygodności danych i zbudowanie pomiaru gotowego na współczesne realia digitalu.

Wyzwania

Przed wdrożeniem zidentyfikowaliśmy kilka problemów, które bezpośrednio wpływały na jakość analityki i skuteczność działań marketingowych.

Znacząca część zdarzeń była blokowana po stronie przeglądarki, co ograniczało widoczność konwersji w GA4. Jednocześnie aż 22% sesji trafiało do kategorii (not set), co istotnie utrudniało ocenę, które kanały marketingowe realnie generują wartość.

Dodatkowym problemem było zrywanie sesji i zaburzone łączenie ścieżek użytkownika – m.in. na styku zgód CMP, architektury SPA oraz działania zewnętrznych narzędzi. W efekcie raportowanie nie zawsze odzwierciedlało rzeczywiste zachowanie użytkowników.

W środowisku medycznym równie ważny był aspekt compliance. Klient potrzebował większej kontroli nad tym, jakie dane opuszczają jego ekosystem i w jakiej formie trafiają do zewnętrznych platform.

Nasze podejście

Zaprojektowaliśmy i wdrożyliśmy architekturę server-side Google Tag Manager, która przejęła kluczowe elementy pomiaru, atrybucji i kontroli danych.

Zakres prac objął:

• migrację tagów Google Ads do kontenera serwerowego,
• uruchomienie modelu hybrydowego dla Meta i TikToka: pixel + Conversion API z pełną deduplikacją zdarzeń,
• przygotowanie infrastruktury pod przyszłą optymalizację kampanii w oparciu o marżę, a nie wyłącznie przychód.

To podejście pozwoliło nie tylko uszczelnić pomiar, ale też zbudować architekturę, która daje klientowi większą niezależność od ograniczeń przeglądarek i platform.

Projekt był realizowany w elastycznym modelu współpracy, dopasowanym do organizacji i potrzeb klienta. Część działań była realizowana po naszej stronie, a część po stronie upacjenta.pl.

To pokazuje, że potrafimy prowadzić wdrożenia zarówno kompleksowo, jak i w modelu partnerskim, ściśle współpracując z zespołem klienta.

Efekty

Analiza danych z okresu testowego pokazała wyraźną poprawę jakości pomiaru i atrybucji.

Odzyskane transakcje

W modelu server-side raportowanie transakcji było wyższe o od 1% do 14% dziennie względem wcześniejszego modelu client-side.

Naprawiona atrybucja

Udział ruchu Google / organic wzrósł z 46% do 61%, co pokazało, że wcześniejszy model nie odzwierciedlał w pełni rzeczywistego źródła wizyt.

Stabilniejsze sesje

Liczba raportowanych sesji spadła o 2–4%, co było pozytywnym sygnałem – oznaczało lepsze łączenie hitów w ramach jednej wizyty i eliminację sztucznych resetów sesji.

Czystszy model pomiarowy

Odsetek sesji bez zdarzenia session_start spadł do 0,2–0,5%, co potwierdziło poprawę w obszarze session stitching i spójności danych.

Co ten projekt zmienił biznesowo?

Największą wartością tego wdrożenia nie była sama zmiana technologii. Kluczowe było to, że upacjenta.pl odzyskało większą kontrolę, większą precyzję i większe zaufanie do danych.

Dzięki temu:

• raportowanie sprzedaży lepiej odzwierciedla rzeczywistość,
• atrybucja daje solidniejszą podstawę do decyzji mediowych,
• systemy reklamowe mogą uczyć się na pełniejszych danych konwersyjnych,
• klient ma większą kontrolę nad prywatnością i zakresem przekazywanych informacji,
• architektura analityczna jest gotowa na dalszy rozwój.

W praktyce oznacza to nie tylko lepszy pomiar „tu i teraz”, ale również gotowość do bardziej zaawansowanych scenariuszy optymalizacji i aktywacji danych.

Fundament pod kolejne etapy rozwoju

Wdrożenie server-side GTM stworzyło bazę pod dalsze inicjatywy z obszaru data-driven growth.

Ta architektura otwiera drogę do:

• optymalizacji kampanii w oparciu o marżę,
• personalizacji doświadczenia użytkownika w czasie rzeczywistym,
• budowy modeli predykcyjnych, takich jak pLTV.

To właśnie dlatego patrzymy na server-side tracking nie jak na pojedyncze wdrożenie techniczne, ale jak na element infrastruktury wzrostu.

Podsumowanie

Ten projekt pokazał, że problemy z jakością danych bardzo często nie wynikają z braku ruchu czy słabszych kampanii, ale z ograniczeń samego modelu pomiarowego.

W przypadku upacjenta.pl przejście na server-side GTM pozwoliło odzyskać część utraconych danych sprzedażowych, uporządkować atrybucję i zbudować znacznie bardziej odporną architekturę analityczną.

Bo kiedy dane stają się dokładniejsze, marketing może działać pewniej. A kiedy pomiar zaczyna nadążać za biznesem, łatwiej skalować to, co naprawdę działa.

The post uPacjenta.pl – Jak uPacjenta.pl odzyskało utracone dane sprzedażowe dzięki Server-side GTM? first appeared on Conversion.

Google Tag Manager jako podstawa marketingu
Różnica pomiędzy GTM Server-side a Client-side
GTM Server-side – zalety
Jak wdrożyć GTM server-side?
Ile kosztuje GTM Server-side?
Czy GTM Server-side różni się od Measurement Protocol?
Co jest potrzebne do wdrożenia GTM Server-side?
Jakie narzędzia można wdrożyć za pomocą GTM Server Side?
Jak GTM Server Side wpływa na zbieranie danych?
Czy GTM Server Side można wdrożyć poza Google Cloud Platform?
Ile trwa wdrożenie ssGTM?
Czy GTM server-side działa w przypadku aplikacji mobilnych?
Podsumowanie

Google Tag Manager jako podstawa marketingu

Google Tag Manager to niezwykle istotne w marketingu online narzędzie. Efektywny marketing online opiera się na danych. Dane to skrypty i narzędzia, które instalujemy oraz wdrażamy w ramach marketingu online. Narzędzia te najczęściej wdrażamy za pomocą skryptów i tagów, które osadzamy w kodzie źródłowym naszej strony. Alternatywą dla wdrażania kodu źródłowego poszczególnych narzędzi jest wykorzystanie GTM, który jest systemem zarządzania treścią dla skryptów. Efektywny marketing powinien opierać się na Google Tag Manager (GTM). Po wdrożeniu skryptów za pomocą GTM lub bezpośrednio w kodzie źródłowym strony, użytkownik wchodząc na nasz serwis, wczytuje jego zawartość. Skrypty te wchodzą w interakcję z narzędziami zewnętrznymi, pobierając dane z przeglądarki, systemu oraz interakcji użytkownika na stronie. Następnie dane te są wysyłane do serwerów narzędzi trzecich.

Odwiedzając dowolną stronę internetową, możemy zobaczyć, jakie informacje są pobierane i wysyłane do stron trzecich. Korzystając z narzędzi dla deweloperów, dostępnych w menu przeglądarki, w zakładce „Network” znajdziemy podsumowanie wszystkich skryptów, w szczególności skryptów JavaScript, które są wczytywane. W ramach analityki online możemy monitorować, jakie skrypty są wczytywane w przeglądarce. Na przykład, używając funkcji Collect, można zobaczyć, jakie informacje są wysyłane z przeglądarki do narzędzi trzecich. Te dane pozwalają na generowanie metryk dotyczących zachowania użytkowników oraz optymalizację marketingu. 

Różnice pomiędzy GTM Server-side a Client-side

W przypadku GTM Client-Side, wszystkie skrypty wdrożone po stronie klienta wysyłają informacje bezpośrednio z przeglądarki do narzędzi trzecich. Natomiast kontener Server-Side to narzędzie instalowane na serwerze. Komunikacja przeglądarki z tym kontenerem odbywa się w taki sposób, że zamiast wielu nawiązań komunikacji z różnymi narzędziami, jedna paczka informacji jest wysyłana do serwera. Na serwerze dane są dzielone na porcje, a odpowiednie informacje są przesyłane dalej do narzędzi trzecich. Całe obciążenie, które do tej pory było podejmowane przez komputer i przeglądarkę, przejmuje serwer. Oczywiście za to obciążenie będziemy płacić w postaci utrzymania serwera, ponieważ musi on wykonać operacje, aby rozesłać poszczególne informacje do wszystkich wdrożonych narzędzi. Dzięki temu, że ciężar obsługi interakcji przejmuje serwer z skonfigurowanym GTM Server-side, działanie naszej strony przyspieszy.

GTM Server-side – zalety

W konsoli przeglądarki można zauważyć, że wczytywanych skryptów jest bardzo dużo, co zajmuje moc obliczeniową komputera i przeglądarki. Po wdrożeniu GTM Server-side i wysłaniu jednej paczki informacji z przeglądarki do serwera, eliminujemy dziesiątki innych komunikacji. Całość obciążenia przejmuje serwer, który rozsyła informacje dalej. Dzięki temu nasza witryna przyspiesza, ponieważ komputer ma więcej zasobów do wczytania treści. Treść jest dostarczana użytkownikowi szybciej, co wpływa na metryki Core Web Vitals. To z kolei ma pozytywny wpływ na ranking w wyszukiwaniach organicznych. Dodatkowymi zaletami wykorzystania GTM Server-side jest możliwość wzbogacenia informacji, które trafiają do serwera, o dane, których nie chcielibyśmy ujawniać użytkownikowi na poziomie przeglądarki. Mogą to być informacje o marży czy koszcie zakupu produktu. Tak wzbogacone dane, wraz z informacjami o użytkowniku, wysyłamy do narzędzi takich jak Google Ads. Dzięki temu możemy nałożyć kryteria optymalizacji reklam w oparciu o bardziej zaawansowane dane, np. związane z marżowością naszych produktów.

Oprócz dodawania informacji na poziomie serwera, możemy również usuwać pewne dane. Jeżeli nie chcemy przesyłać personalnie identyfikowanych informacji do narzędzi trzecich, co jest zgodne z RODO, możemy je usunąć z paczki danych, zanim zostaną rozesłane do innych narzędzi. 

Jak wdrożyć GTM server-side?

Ponieważ paczka informacji trafia do serwera, który najczęściej jest skonfigurowany na naszej subdomenie, mamy mniejszy poziom blokowania tych nawiązań przez adblocki i różnego rodzaju narzędzia. Narzędzia te działają w ten sposób, że rozpoznają, dokąd wychodzą poszczególne sygnały. Jeśli sygnał znajduje się na liście rzeczy do zablokowania, nie jest przekazywany dalej. Zastosowanie GDPR zwiększa liczbę rejestrowanych konwersji, ponieważ ad-doki nie działają na tego typu informacje, które trafiają do naszego serwera. Proces ten można podzielić na trzy kroki:

1. Konfiguracja serwera, na którym będzie umieszczony kontener.
2. Konfiguracja tagów w kontenerze serwerowym.
3. Przekierowanie wysyłania informacji z kontenera client-side, aby nie trafiały bezpośrednio do narzędzi, ale do naszego serwera. Serwer, na podstawie konfiguracji z kroku drugiego, będzie wiedział, gdzie te informacje rozesłać.

W praktyce, w ramach realizowanych projektów, sprawdzamy obciążenie serwera, aby zoptymalizować koszty. Podstawowe narzędzia Google Platform do postawienia kontenera serwerowego to App Engine i Cloud Run. Przed wyborem pierwszego kroku i konfiguracją kontenera serwerowego, analizujemy ruch, aby oszacować koszty obsługi kontenera i zoptymalizować je. Drugim krokiem, już po wdrożeniu kontenera, jest ocena jego odporności na adblocki. GTM Server Side jest generalnie odporny na działanie adblocków, jednak można to jeszcze dopracować. W związku z tym przeprowadzamy analizy sprawdzające tę odporność. Jeśli jest na odpowiednim poziomie, pozostawiamy konfigurację bez zmian.

Dodatkowo optymalizujemy śledzenie po stronie klienta, ponieważ nie zawsze wszystko powinno być śledzone przez rozwiązanie client-side. Często zdarza się, że firmy same wdrażające GTM Server-Side mają zdublowane śledzenie, co oznacza, że te same informacje są wysyłane z obu kontenerów. Przy wdrożeniu GTM Server-Side zawsze zwracamy na to uwagę. Razem z konfiguracją warto zastanowić się nad możliwością wzbogacenia danych. Często u klientów, którzy mają takie potrzeby, dodajemy informacje o koszcie wytworzenia danego produktu. Dzięki temu kampanie mogą być optymalizowane na podstawie rzeczywistej marży i zysku bezpośredniego z produktu, a nie jedynie na podstawie przychodu. To istotne, ponieważ różne produkty mogą mieć różne marże.

W przypadku większych organizacji, które mają wiele kontenerów, przeprowadzamy analizę, aby zoptymalizować ich liczbę. Często okazuje się, że duża liczba kontenerów nie jest konieczna. Dotyczy to szczególnie organizacji z wieloma stronami, gdzie struktura przy wdrażaniu kontenerów Client Side często nie była przemyślana.

Ile kosztuje GTM Server-side?

Jednym z najczęstszych pytań, jakie zadają klienci zainteresowani GTM Server-Side, jest koszt takiego rozwiązania. Koszt ten należy podzielić na dwa czynniki. Pierwszym aspektem jest koszt wdrożenia, a drugim koszt obsługi. Koszt obsługi obejmuje zarządzanie wdrożeniami kolejnych narzędzi oraz obsługę serwera, na którym znajduje się kontener. W przypadku liczby żądań na sekundę, jeśli serwery muszą obsłużyć około 4-5 żądań na sekundę, koszt wynosi około 400 złotych. Przy mniejszych serwisach, koszty te mogą wynosić maksymalnie do 1000 złotych, a często zamykają się w kwocie 100 złotych miesięcznie. 

Należy również uwzględnić koszt wdrożenia i obsługi, jeśli chodzi o wdrażanie nowego śledzenia. 

Czy GTM Server-side różni się od Measurement Protocol?

Measurement Protocol to funkcja Google Analytics, za pośrednictwem której można wysyłać dane do GA4 bez konieczności obecności użytkownika w serwisie. Jeśli mamy urządzenia, które nie obsługują przeglądarki ani nie są aplikacjami mobilnymi, na przykład kioski w sklepach stacjonarnych, możemy bezpośrednio wysyłać informacje do GA4 za pomocą Measurement Protocol. Measurement Protocol często jest wykorzystywany do dosyłania transakcji, które normalnie nie zostałyby zarejestrowane przez GA4.

Google Tag Manager (GTM) nie służy wyłącznie do GA4. GTM jest używany do wysyłania danych do różnych narzędzi. GTM działa jak kieszonka, która zbiera informacje z przeglądarki, a następnie rozdziela je do odpowiednich narzędzi. Niezależnie od tego, czy dane mają trafić do GA4, Google Ads, czy innego narzędzia, z poziomu GTM można je wysłać do wybranego systemu. Measurement Protocol nie zastąpi Google Tag Manager Server-Side i odwrotnie, ponieważ są to dwa zupełnie różne narzędzia. 

Co jest potrzebne do wdrożenia GTM Server-side?

Przede wszystkim konieczny jest skonfigurowany serwer. Oznacza to, że musimy mieć przestrzeń, na której zainstalujemy kontener serwerowy. Klienci najczęściej wybierają przestrzeń w ramach Google Cloud Platform, korzystając z narzędzi takich jak App Engine lub Cloud Run. Obecnie coraz częściej wybierany jest Cloud Run, ponieważ jest bardziej skalowalny, co pozwala lepiej kontrolować koszty. W przypadku App Engine musimy z góry określić liczbę maszyn, które będą obsługiwać ruch. Cloud Run oferuje opcje skalowania, co oznacza, że maszyny będą się automatycznie dostosowywać do zapotrzebowania. Możemy również wybrać inne środowisko, takie jak Azure lub AWS. Z naszego doświadczenia wynika, że największym problemem jest stworzenie odpowiedniej przestrzeni. Pozostałe kwestie, takie jak konfiguracja na serwerze i konfiguracja przekazywania danych z GTM Client-Side do Server-Side, mogą być wykonane przez nas lub przez analityka internetowego odpowiedzialnego za wdrożenie.

Jakie narzędzia można wdrożyć za pomocą GTM Server Side?

U jednego z klientów mamy listę około 36 narzędzi, z których kilka będzie wdrażanych za pośrednictwem GTM Server-Side. Google oferuje wiele rozwiązań, takich jak Analytics, śledzenie adresów, Floodlight oraz inne narzędzia z grupy Marketing Platform. Wśród nich znajdują się piksele do Criteo, Pinteresta, TikToka, Twittera, LinkedIna i innych, które polegają na wdrażaniu skryptów wysyłających informacje bezpośrednio do tych narzędzi. Wszystko, co wdrażamy na client-side, możemy również wdrożyć po stronie serwera, czyli Server-Side.

Jak GTM Server Side wpływa na zbieranie danych?

Można to podsumować w dwóch aspektach. Po pierwsze, uszczelnia zbieranie danych. Śledzenie realizowane za pomocą GTM Server Side jest bardziej odporne na blokowanie przez adblock, co zwiększa poziom rejestrowanych danych i konwersji. Po drugie, modyfikuje dane. Może to oznaczać zarówno wzbogacanie danych poprzez dodanie dodatkowych informacji, jak i usuwanie informacji, których nie chcemy przekazywać do narzędzi trzecich.

Czy GTM Server Side można wdrożyć poza Google Cloud Platform?

Jak najbardziej. Alternatywą w przypadku Microsoft Azure jest Azure App Service. W przypadku Amazon i jego AWS jest to Elastic Beanstalk, które jest bardzo podobne do App Engine w Google Cloud Platform. Elastic Container Service jest z kolei odpowiednikiem Cloud Run. W ten sposób można wykorzystać inne chmury do obsługi kontenera server-side.

Ile trwa wdrożenie ssGTM?

Proces można podzielić na dwie części. Pierwsza dotyczy konfiguracji samego serwera i kontenera na tym serwerze. Druga część związana jest z przenoszeniem śledzenia z client-side na server-side i jest uzależniona od aktualnej konfiguracji GTM Client-Side. Im bardziej rozbudowana jest konfiguracja i im więcej danych tam przekazujesz, tym dłużej potrwa ten etap. Średnio takie wdrożenia trwają od 3 do 6 miesięcy, obejmując przepięcie śledzenia z Client-Side na Server-Side.

Czy GTM server-side działa w przypadku aplikacji mobilnych?

Obecnie nie, choć w przyszłości może się to zmienić. W przeciągu 1-2 lat ssGTM stanie się standardem śledzenia w marketingu online. Im wcześniej wdrożysz ssGTM, tym szybciej skorzystasz z jego zalet, takich jak przyspieszenie strony internetowej i wzbogacenie danych przekazywanych dalej. ssGTM pozwala również na rejestrowanie większej ilości danych, unikając np. adblocków. Warto więc jak najszybciej zainteresować się tym tematem. 
Podsumowanie

Wdrożenie GTM server-side ma wiele korzyści i pozytywnie wpływa na wiele aspektów marketingu online, takich jak Core Web Vitals czy kwestie związane z RODO. Jestem przekonany, że ssGTM jest przyszłością śledzenia i zbierania danych w internecie. Warto więc już teraz zadbać o odpowiednie wdrożenie i poprawić działania związane ze zbieraniem danych w swoim serwisie.

The post GTM Server-Side – jak pomaga w marketingu? first appeared on Conversion.