Server side tagging – czym jest i jak działa?

Z pewnością nie możemy narzekać na stagnację w świecie analityki internetowej w ostatnich miesiącach. W świetle reflektorów znajdowały się kwestie prywatności oraz “propozycji nie do odrzucenia” ze strony Google’a w temacie migracji z Universal Analytics’a na GA4. We wspomnianych zagadnieniach chyba już wszystko zostało powiedziane. Dlatego dzisiaj na warsztat weźmiemy rozwiązanie, o którym ucichło w ostatnim czasie i nadal nie jest wykorzystywane na większą skalę. Mowa tutaj o Google Tag Manager Server-Side.

Co znajdziesz w tym artykule?
Czym jest GTM Server-Side?
GTM Client-Side vs. Server-Side
Przypadki użycia GTM Server Side
Quo Vadis, GTM?
Nie wszystko złoto, co się świeci… – kilka wad Google Tag Managera Sever-Side
Etapy, przez które musimy przejść w celu uzyskania nowych supermocy
Narzędzie GTM Server-Side – podsumowanie

Czym jest GTM Server-Side?

GTM Server-Side to rozwiązanie od Google’a w zakresie menadżera tagów, które wyprowadza standard śledzenia oraz przekazywanie danych na znacznie wyższy poziom, dając nam tym samym nowe możliwości. W jaki sposób i o co w tym wszystkim chodzi? Tego dowiesz się z tego artykułu!

GTM Client-Side vs. Server-Side

“Nie dość, że muszę się przesiąść na nowy Google Analytics to to samo czeka mnie w przypadku GTM-a?”. Na wstępie uspokajamy – klasyczny Google Tag Manager (client-side) nadal będzie potrzebny, bo to właśnie jego należy zintegrować z GTM Server-Side. Oczywiście, o ile się na to zdecydujesz.

Na początek w skrócie wyjaśnijmy sobie różnice pomiędzy sposobami tagowania: client-side (na nim opiera się klasyczny GTM) oraz server-side. Dotychczas działało to w taki sposób, że mieliśmy ustawiony jakiś tag np. zdarzenie pixela Meta (dawniej Facebook). Po wywołaniu takiego tagu, request zawierający dane o zdarzeniu był przesyłany bezpośrednio do Meta. Poniżej zamieszczamy schemat, który powinien ułatwić zrozumienie opisanej sytuacji.

Tradycyjna konfiguracja strony – GTM Client-Side. Źródło: developers.google.com

W przypadku GTM-a Server-side pojawia się dodatkowy podmiot, który jest odpowiedzialny za zbieranie danych z wywołanych tagów na poziomie kontenera webowego i rozdysponowanie ich do innych narzędzi m.in Google Analytics, Google Ads, czy Meta. Można powiedzieć, że kontener serwerowy to nasz “anioł stróż”, który odpowiada za bezpieczeństwo naszych danych.

Konfiguracja strony przy użyciu GTM Server-Side. Źródło: developers.google.com

Na powyższym schemacie pojawił się “Client” w serwerowym kontenerze. Służy on do odbierania sygnałów (wywołanych tagów) z kontenera webowego. To wszystko może brzmieć dość skomplikowanie, ale wbrew pozorom takie nie jest. Jednak zanim pomyślimy o wdrożeniu tego rozwiązania, warto wiedzieć, dlaczego powinniśmy je rozważyć…

Przypadki użycia GTM Server Side

GTM Server Side sprawdza się tam, gdzie klasyczne tagi przestają wystarczać – np. do konsolidacji wielu źródeł danych (web, CRM, backend) w jednym miejscu, zanim rozdzielisz je do narzędzi analitycznych. Dzięki temu zyskujesz większą elastyczność w transformacji i filtrowaniu danych, a także możliwość sterowania, które fragmenty informacji trafią dalej, a które zatrzymasz lub usuniesz. To użyteczne zwłaszcza w środowiskach wielokanałowych.

Optymalizacja śledzenia konwersji

W kontekście konwersji, server-side tagging pozwala ominąć blokady typu ad blocker czy ograniczenia przeglądarkowe (ITP), co często skutkuje nawet 5-30% wzrostem liczby zarejestrowanych zdarzeń. Dodatkowo możesz wprowadzać logikę atrybucji lub „odświeżać” cookies na serwerze, co wydłuża okno atribucji i umożliwia lepsze przypisanie sprzedaży zwłaszcza w kampaniach z długim cyklem decyzyjnym.

Integracja z narzędziami analitycznymi

Po stronie serwera łatwiej jest integrować różne systemy – na przykład przekazywać dane z GTM do GA4, Meta (przez Conversion API), Piwik PRO czy nawet własnych systemów raportowych – z jednego punktu kontrolnego. W praktyce możesz zbudować logiczne „switchboard” danych: filtruj, wzbogacaj, anonimizuj – i kieruj odpowiednie zestawy danych do właściwych narzędzi, bez dublowania kodów po stronie klienta.

Quo Vadis, GTM?

Na początek zastanówmy się dlaczego powstał taki produkt, jak GTM Server-Side. Z pewnością nowa odsłona Google Tag Manager jest odpowiedzią na coraz większe ograniczeniach w śledzeniu użytkowników po stronie przeglądarek np. ITP (Intelligent Tracking Prevention) w Safari. Zmiany obejmują również blokowanie tzw. ciasteczek obcych (third-party cookies), co będzie skutkowało ograniczeniem śledzenia po stronie narzędzi zewnętrznych m.in. wspomniana już wcześniej Meta. Problem ten zostaje rozwiązany w taki sposób, że wysyłane request’y do naszego serwera są traktowane jako first-party cookie. Oczywiście, aby tak się stało należy skonfigurować customową domenę (temat zostanie poruszony w dalszej części artykułu).

Rozwiązanie opisanych ograniczeń, które pojawiły się wraz ze zwiększoną troską o prywatność użytkowników to nie jedyna zaleta. Poniżej przedstawiamy inne plusy tego rozwiązania:

• Zwiększona kontrola nad przesyłanymi danymi – zyskujemy możliwość decydowania o tym, jakie informacje zostaną dalej przesłane. Przykładowo GTM Server-Side odbiera request, który zawiera wrażliwy parametr, którego nie chcemy udostępniać podmiotom trzecim. Omawiane rozwiązanie pozwala usunąć lub zmodyfikować niepożądany parametr przed przesłaniem danych do kolejnych dostawców.
• Obrona przed Adblock’ami – wraz ze wzrostem świadomości użytkowników możemy zaobserwować popularyzację rozwiązań blokujących śledzenie użytkowników. Standardowo te produkty są nastawione na blokowanie third-party cookies, dlatego gdy nasze żądania są traktowane jako first-party, takowy AdBlock nie zatrzyma naszego śledzenia.
• Poprawa czasu wczytywania strony – zdajemy sobie sprawę jakim jest to istotnym aspektem pod kątem user-experience. Poprzez ograniczenie skryptów podmiotów trzecich nasza strona będzie mniej obciążona, co może korzystnie wpłynąć na czas wczytywania strony. Dodatkowo, dużym atutem GTM-a Server-Side jest to, że możemy na podstawie odebranego, jednego request’a rozdysponować dane do kilku innych podmiotów.
• Wzbogacanie danych – oprócz modyfikowania na danych na poziomie jednego źródła, możemy je łączyć z danymi z innego źródła przed ostatecznym przesłanie ich do jakiegoś dostawcy. Przykładem może być połączenie danych z Google Analytics z danymi z CRM, a następnie przesłanie pełniejszego obrazu do danego dostawcy.

Nie wszystko złoto, co się świeci… – kilka wad Google Tag Managera Sever-Side

Można się zastanawiać “skoro to rozwiązanie rozstrzyga tych kilka bieżących problemów to dlaczego jest tak stosunkowo mało popularne pod kątem wdrożeń”? Produkt jest już na rynku od około dwóch lat, a fazę beta opuścił na przełomie września i października 2021 r. Pomimo tego, rzadko możemy spotkać zaimplementowane to rozwiązanie nawet u dużych klientów. Z czego to wynika? Omówmy kilka wad/trudności związanych z tym rozwiązaniem:

• • Koszty utrzymania – jak mówi słynne przysłowie “jeśli nie wiadomo, o co chodzi to chodzi o pieniądze”. O ile samo utworzenie GTM Server-Side nic nie kosztuje, o tyle utrzymanie serwerów w środowisku chmurowym Google już tak. Standardowa implementacja opierająca się na App Engine to koszt 30-40$ miesięcznie za instancję. Zazwyczaj rekomendowane jest włączenie minimum 3 instancji (domyślnie 3-6 z autoscaling’iem), co potraja ten wydatek. Oczywiście, można na własną rękę przetestować mniejszą liczbę instancji i sprawdzić, jak będzie się ona sprawdzać pod kątem wydajność i wyrzucanych błędów.
    Jeżeli powyższe koszty Cię przestraszyły to na ratunek przychodzi alternatywne rozwiązanie oparte o Cloud Run. Ta opcja wyróżnia się możliwością skalowania, która zazwyczaj przekłada się na niższe koszty. Rozwiązanie jest polecane zwłaszcza dla stron cechujących się mniejszym obciążeniem (ilością przesyłanych hitów). W przypadku serwisów, na których “sporo się dzieje” może okazać się, że “stałe koszty” App Engine mogą być bardziej opłacalne niż koszty Cloud Run za rzeczywiste wykorzystanie zasobów.
  • Ograniczona liczba zasobów partnerów – jeżeli jesteśmy zaznajomieni z klasycznym GTM-em to patrząc na listę dostępnym template’ów pod konfigurację tagów w Server-Side, możemy stwierdzić, że jest ona dość uboga i tak naprawdę zawiera tylko zasoby od Google’a (oprócz HTTP Request).
    Jednak po wejściu do “Community Template Gallery” mamy dostęp do zasobów, które pozwalają przesyłać dane m.in. do Facebook’a, czy TikTok’a. Należy tutaj wykazywać się ostrożnością… Zanim skorzystamy z danego rozwiązania powinniśmy je zweryfikować np. poprzez sprawdzenie, kto zrealizował dany projekt.

Lista dostępnych template’ów pod konfigurację tagów. Źródło: developers.google.com

• Ograniczona wiedza techniczna – nie ma co się oszukiwać, że to środowisko jest bardziej skomplikowane niż GTM Client-Side. Zwłaszcza, że do starszego rozwiązania już się przyzwyczailiśmy i co niektórzy mogliby je “wyklikiwać” z zamkniętymi oczami. Tutaj na barki analityków są wkładane nowe obowiązki, takie jak konfiguracja środowiska chmurowego, ustawienie i zmapowanie nowej subdomeny, czy nowy standard konfiguracji z poziomu GTM-a, z którym trzeba się zaznajomić.
  Na pocieszenie mamy dostęp do szczegółowej dokumentacji od Google’a oraz do przynajmniej kilku wartościowych tutoriali, które znacznie ułatwią wejście w ten nowy świat.

Etapy, przez które musimy przejść w celu uzyskania nowych supermocy

1. Utworzenie kontenera GTM Server-Side

Ten etap możemy uznać za zdecydowanie najłatwiejszy. W momencie, w którym zdecydujemy się na utworzenie nowego kontenera wystarczy przejść na zakładkę “Administracja” i na poziomie kontenera kliknąć “+”. Po takiej interakcji pojawi się okno, w którym możesz wybrać rodzaj kontenera.

Jak utworzyć kontener GTM Server-Side?

Następnie możesz skorzystać z automatycznego skonfigurowania serwera tagowania. Po wybraniu tej opcji pojawi się zapytanie o konto rozliczeniowe na Google Cloud Platform, co oznacza rozpoczęcie 2. etapu…

2. Utworzenie konta GCP oraz konfiguracja sposobu płatności

Jeżeli jeszcze nie masz konta Google Cloud Platform, co oznacza, że nie było możliwości podłączenia płatności w poprzednim kroku i tym samym utworzenia projektu to będziesz zmuszony zrobić to teraz. W Internecie znajduje się wiele poradników jak to zrobić, dlatego w tym artykule nie będziemy tego zgłębiać.

Po utworzeniu konta i podłączeniu płatności możesz dokończyć konfigurację GTM-a Server-Side.

Jak utworzyć konto GCP oraz skonfigurować płatności?

Proces tworzenia po stronie systemu może zająć co najmniej kilka minut, dlatego zanim go przetestujesz musisz uzbroić się w cierpliwość.

3. Przygotowanie i przetestowanie pierwszych tagów

Jeżeli już masz ustawione odpowiednie tagi w GTM-ie Client-Side to proces możesz zacząć od stworzenia odpowiedniego Client’a z poziomu Server-Side, który będzie odbierał sygnały z klasycznego GTM-a. Zostanie on również wykorzystany w regule wywoływania tagów przekazujących dane do konkretnych narzędzi.

Tak wygląda lista dostępnych domyślnych Client’ów:

Lista dostępnych domyślnych Client’ów z poziomu GTM Server-Side.

Przykładowo możemy wybrać GA4. Jako regułę wywoływania tagu możemy ustawić “Niestandardowe”, a następnie ustawić warunek “Client Name” zawiera/równa się “GA4”

Konfiguracja Clienta w GTM Server-Side.

W tym przykładzie ostatnim elementem będzie utworzenie tagu.

Tworzenie tagów w GTM Server-Side.

Teraz musimy wrócić do naszego GTM-a Client-Side i włączyć przesyłanie danych do serwerowego kontenera:

Włączenie opcji przesyłanie danych.

Oprócz tego, podstawiamy URL dla serwera kontenerowego. Jeżeli jeszcze nie działałeś w kwestii zmiany customowej domeny to możesz podstawić domyślny URL wygenerowany przy tworzeniu kontenera – tryb testowy w App Engine. Możesz go znaleźć w głównym widoku swojego Server-Side po kliknięciu ID kontenera (GTM-xxx) na pasku nawigacyjnym. Tam znajduje się pole o nazwie “Domyślny adres URL”. Po podstawieniu tego URL-a w tagu na kontenerze Client-Side możemy go zapisać i rozpocząć debuggowanie, poprzez włączenie trybu podglądu na obu kontenerach. Dodatkowo, możesz to zweryfikować po stronie konsoli oraz w request’ach na poziomie App Engine.

Warto dodać, że taka konfiguracja pozwala na przechwytywanie wszystkich zdarzeń z Google Analytics 4.

4. Włączenie instancji produkcyjnych oraz konfiguracja customowej domeny

W przypadku włączenia instancji produkcyjnych będziemy musieli skorzystać z konsoli na poziomie GCP zwanej “Cloud Shell”. Po wprowadzeniu kilku komend będziemy mogli uruchomić nasze instancje produkcyjne. Pojawią się pytania m.in czy chcemy włączyć autoscalling oraz w przypadku wyrażenia zgody o minimalną i maksymalną liczbę instancji. W witrynie Google Developers znajduje się dokładny opis, jakie komendy należy wprowadzić: https://developers.google.com/tag-platform/tag-manager/server-side/script-user-guide

Na poziomie ustawień App Engine możemy również skonfigurować customową domenę (o zaletach wspominaliśmy już wcześniej). Będziemy musieli ustawić nazwę subdomeny, do której będą wysyłane request’y. Wymagana będzie również weryfikacja własności do danej subdomeny. Na sam koniec należy zaktualizować rekordy DNS, zgodnie z instrukcją występującą podczas konfiguracji.

Narzędzie Server side tagging od Google – podsumowanie

W rzeczywistości, w której spotykamy się z coraz większymi restrykcjami pod kątem śledzenia użytkowników, wydaje się, że to narzędzie może nas wynieść na wyższy poziom analityczny. Oczywiście, wiąże się ono z dodatkowymi kosztami. Jednak sam musisz zdecydować, czy wartość, którą wnosi jest godna poniesionych “strat”. Z pewnością będziemy oczekiwać na nowe udoskonalenia np. template’y, które pozwolą bezpośrednio przekazywać dane do innych systemów.
Zachęcam również do zainteresowania się tym tematem, aby obyło się bez niepotrzebnych stresów, kiedy obudzimy się w świecie totalnie odciętym od third-party cookies.

Mamy nadzieję, że udało mi się przekonać Cię do przetestowania tego rozwiązania! Jeśli zastanawiasz jak wykorzystać te narzędzia w Twojej firmie – pogadajmy!