Adam Brzostek
19.03.2024
Czas czytania: 8:30

Praktyczny poradnik GTM server-side tagging - Google Analytics 4

Czym jest Google Tag Manager serve-side?

GTM server side jest nowym typem kontenera zlokalizowanym po stronie serwera, w związku z tym nie jest uruchamiany po stronie klienta ale właśnie na serwerze. Możemy porównać go do serwera proxy, który odbiera żądania ze strony klienta, a następnie na ich podstawie uruchamia tagi, które przesyłają informacje do wymaganych endpointów.

Żeby lepiej zrozumieć działanie GTM server-side posłużmy się przykładem. Przy klasycznym GTM client-side po uruchomieniu tagu GA informacje wysyłaliśmy bezpośrednio to Analyticsa. Z wykorzystaniem tagowania server-side informacje tą wysyłamy najpierw do naszego GTM’a na serwerze, a dopiero z serwera jest ona przesłana dalej do Analyticsa.

server-side schemat

Dlaczego warto wdrożyć śledzenie GTM server-side?

Więcej danych

W pracy analityka internetowego częstym problemem jest utrata danych na poziomie zbierania. Nie tylko z powodu odrzuconych zgód cookie consent, ale również przez różnego rodzaju ad blocki czy przeglądarki, które zwyczajnie blokują skrypty Google Analytics lub innego narzędzia analitycznego. Mechanizm blokowania zazwyczaj opiera się o wykrywanie żądań do konkretnych serwerów i blokowaniu ich.

Za pomocą GTM server-side możemy w pewien sposób “oszukać” ad block lub przeglądarkę, że komunikujemy się z własnym serwerem, co w teorii powinno przełożyć się na większą ilość zbieranych danych.

Kontekst 1st party

Wiedząc o zbliżającym się wielkimi krokami cookieless world warto wiedzieć, że przy tagowaniu server-side z wykorzystaniem własnej niestandardowej domeny zyskujemy kontekst 1st party i w ten sposób po raz kolejny “oszukujemy” naszą przeglądarkę. Przy odpowiedniej konfiguracji domeny, może okazać się to zbawienne szczególnie dla przeglądarki Safari

Większe bezpieczeństwo

Innym z powodów, dla których warto wykorzystać server-side tagging jest większe bezpieczeństwo, w przypadku, gdy chcemy wysłać dane do end pointu dla, którego musimy podać poświadczenia a nie chcemy ich eksponować po stronie klienta.

Optymalizacja obciążenia po stronie klienta

Serve-side tagging pozwala na optymalizacje tagowania po stronie klienta. Na podstawie jednego odebranego żądania na serwerze, możemy tą samą informacje przesłać do wielu miejsc, przez co zwiększamy zarówno kontrole jak i zmniejszamy ilość akcji (uruchamianych tagów) dziejących się po stronie klienta, co może podnieść wydajność naszej strony.

Konfiguracja GTM Server Side

Żeby zacząć przygodę z server-side tagging będzie nam potrzebny kontener GTM tegoż typu, ponieważ korzystanie z sGTM wiąże się z pewnymi niewielkimi opłatami musimy posiadać konto rozliczeniowe Google Cloud Project. Jeżeli nie posiadamy jeszcze konta rozliczeniowego GCP dobrze jest je stworzyć przed rozpoczęciem konfigurowania GTM, aczkolwiek będziemy mieli możliwość utworzenie go również w trakcie konfiguracji.

Mamy do wyboru dwa modele rozliczeń:

  • app engine - model, w którym na stałe rezerwujemy sobie wirtualną maszynę obsługującą nasze żądania. Opłata zależna jest od liczby maszyn, a koszt jednej zaczyna się od 45$. Ten model rekomenduje się dla stron z dużym ruchem, dla których ważny jest maksymalna minimalizacja czasu opóźnień przetwarzanych żądań. Liczbę potrzebnych wirtualnych maszyn dopasowuje się na podstawie ruchu
  • cloud run - model, w którym płacimy za faktyczne wykorzystanie wirtualnych maszyn a ich użyteczność jest nam przypisywana na podstawie odbieranych żądań

Możemy teraz przystąpić do konfiguracji kontenera GTM po stronie serwera. W kreatorze musimy podać nazwę, wybrać typ server oraz kliknąć przycisk utwórz.

sGTM type

W następnym kroku kreator poprosi nas o konfiguracje serwera tagowania. Zalecam wybranie konfiguracji automatycznej, gdyż wtedy utworzymy sGTM w modelu cloud run na którym nam zależy - wszystkie kroki w tym poradniku są opisane dla tej właśnie opcji.

sGTM method

W ostatnim kroku wybieramy konto rozliczeniowe do którego chcemy podłączyć projekt GCP naszego kontenera, który zostanie dla nas utworzony (jeżeli nie mamy konta rozliczeniowego to w tym momencie musimy je utworzyć)

sGTM billing

Po kilku chwilach nasz serwer tagowanie powinien zostać skonfigurowany

sGTM config

Wysłanie żądania do GTM server-side

Pierwszą częścią konfiguracji śledzenie server-side jest wysłanie żądania do naszego sGTM.

Zrobimy to wykorzystując tagi GA4. W tym celu musimy do naszego tag google dodać parametr server_container_url, który przyjmie wartość adresu url naszego serwera. Dla łatwiejszego zarządzania zalecam utworzenie zmiennej ustawień konfiguracji:

sGTM - config settings

Gdzie zmienna const - server-side url to stała przechowująca adres naszego serwera:

sGTM - const url
sGTM - config tag

Aby mieć pewność, że wszystkie zdarzenia wyślą się do naszego serwera powinniśmy w konfiguracji zdarzenia, również dodać parametr server_container_url. W celu łatwiejszego skalowania wysyłanych zdarzeń do serwera tym razem utworzymy zmienną konfiguracji zdarzeń:

sGTM - events config

Musimy teraz zadbać o to, żeby każde zdarzenie wykorzystywało tą zmienną:

sGTM - event tag

Odebranie zdarzenia przez serwer i przesłanie go do Google Analytics 4

Po opublikowaniu obszaru roboczego w Google Tag Managerze po stronie klienta nasze zdarzenia zaczną być odbierane przez nasz serwer tagowania. Możemy to łatwo sprawdzić w trybie podglądu.

Uruchamiamy go tak samo jak w standardowym kontenerze GTM. Żeby zobaczyć przychodzące żądania musimy uruchomić stronę i wykonać akcję powodującą oczekiwany event, lub w przypadku nieopublikowanego kontenera GTM po stronie klienta zrobić to w trybie podglądu również tegoż kontenera.

debug view gtm server side

Sam tryb podglądu jest bardzo podobny do GTM client side. Po lewej stronie widzimy przychodzące żądania, czyli te eventy, którch wysyłkę do serwera wcześniej skonfigurowaliśmy. Mamy dwie nowe istotne zakładki:

  • Request: przedstawiającą żądania otrzymane oraz wysłane z serwera
  • Event Data: dane zdarzenia odebranego przez serwer, które możemy wykorzystać.

Poza tym mamy do dyspozycji zakładki znane z debuggera client side: zmienne oraz tagi.

server side debug view event data

Chcą wysłać dane do Google Analytics 4 wystarczy nam skonfigurowanie tylko jednego tagu typu Google Analytics: GA4

Nie musimy nic zmieniać w jego konfiguracji - w takiej sytuacji do usługi GA4 zostaną przekazane wszystkie dane odebrane przez serwer przy danym zdarzeniu.

Oczywiście mamy wiele możliwości konfiguracji, m.in:

  • Zmienienie identyfikatora pomiaru, jeżeli chcemy wysłać dane do innej usługi niż zadeklarowaliśmy po stronie klienta - ta opcja może być przydatna jeżeli z poziomu serwera chcielibyśmy wysyłać dane do wielu różnych usług.
  • Całkowite usunięcie IP użytkowników, natomiast wiąże się to z brakiem dostępności danych geograficznych w interfejsie GA
  • Zmiana nazwy zdarzenia
  • Odbierane lub wykluczane parametry zdarzenia oraz użytkownika, w sytuacji, gdy chcemy zmienić zdarzenie odbierane przez serwer
konfiguracja tagu ga4 serwer side

Regułę uruchamiającą musimy skonfigurować jako wszystkie zdarzenia, ale oczywiście jak w przypadku konfiguracji po stronie klienta możemy być bardziej precyzyjni i dla bardziej zaawansowanych implementacji konkretnie określić dla jakich odbieranych żądań chcemy uruchomić dany tag.

reguła uruchamiająca gtm server side

Przed publikacją w trybie podglądu możemy sprawdzić czy nasz tag uruchamia się tak jak należy a następnie opublikować kontener.

tag ga4 w debug view server side

Tym sposobem udało nam się skonfigurować zbieranie danych za pomocą tagowania po stronie serwera.

Niestandardowa subdomena

Żeby maksymalnie wykorzystać potencjał tagowania server-side konieczne jest zintegrowanie naszego serwera z subdomeną niestandardową, która przyjmie rolę endpoint'u do którego wysyłamy dane.

Pierwsze czego potrzebujemy do skonfigurowana subdomena. Najlepiej na tym samym serwerze, a w idealnym świecie o przynajmniej takich samych pierwszych 4 znakach adresu IP zgodnych z adresem IP naszej domeny głównej. Dzięki temu nawet na nieprzyjaznych przeglądarkach typu Safari, póki co powinno udać nam się uzyskać kontekst first party i znacznie wydłużyć żywotność cookies'ów.

Żeby zintegrować naszą subdomenę musimy zajrzeć do naszego projektu GCP, a w nim z menu otworzyć Cloud Run, czyli usługę której używamy do obsługi naszego serwera. Przy domyślnej konfiguracji powinnym nam ukazać się dwa serwery - nas interesuje ten pierwszy, czyli główny, drugi wykorzystywany jest w trybie debug.

GCP - cloud run

Przechodzimy do zakładki Integracje i klikamy przycisk Dodaj Integrację

GCM - Cloud Run - Integracje

Z dostępnych opcji wybieramy Domeny nistandardowe - Równoważenie obciążenia w Google Cloud

Cloud Run - typy integracji domen

W następnym kroku musimy:

  • zadeklarować nazwę naszej subdomeny
  • włączyć potrzebne API
  • nadać domyślnemu kontu serwisowemu odpowiednie uprawnienia

A jak to wykonamy kliknąć przycisk Submit.

konfiguracja domeny nistandardowej w Cloud Run

Jeżeli, nasza subdomena została skonfigurowana prawidłowo to po kilku minutach wszystkie zasoby oprócz certyfikatu SSL zostaną prawidłowo wdrożone. Zostanie wygenerowany również dla nas rekord DNS, który będziemy musieli dodać do naszej subdomeny.

Jest to rekord typu A o określonym adresie IP. Po jego dodaniu należy odczekać kilka godzin i następnie uruchomić Update. Tym razem wszystkie zasoby powinny zostać wdrożone prawidłowo a certyfikat SSL zyska status aktywny tak jak nasza subdomena.

W tym momencie możemy dodać naszą subdomene do ustawień kontenera GTM server-side

Ostatnim krokiem jest podmiana adresu serwera w GTM po stronie klienta na adres nasze subdomeny i opublikowanie tych zmian.

Mam nadzieje, że dzięki temu artykułowi udało Ci się wdrożyć u siebie tagowanie server-side dla Google Analytics 4. Jeżeli Twoja implementacja jest bardziej skomplikowana i nie możesz sam sobie z nią poradzić to napisz do nas, a na pewno Ci pomożemy.

Powiązane artykuły