Pułapki konfiguracji GTM server-side w technologii Google Cloud Run

Server - side tracking staje się coraz popularniejszym rozwiązaniem i słusznie bo niesie ze sobą wiele plusów o czym piszemy w innych artykułach na naszym blogu. W tym artykule chciałbym przedstawić najpopularniejsze pułapki, jakie mogą na nas czychać decydując się na konfigurację GTM server - side z wykorzystaniem Google Cloud Platform jako dostawca technologi serwerowej.

1. Region przetwarzania

Decydując się na konfigurację GTM server-side z wykorzystaniem Google Cloud w większości przypadków skorzystamy z technologi Cloud Run, dla której musimy wybrać region przetwarzania danych i wbrew pozorom jest to dość istotne ustawienie. Co ważne po skonfigurowaniu usługi tego ustawienia nie będziemy mogli później zmienić. Dlatego, żeby oszczędzić sobie dodatkowej pracy warto dobrze przemyśleć, która lokalizacja dla naszego serwera będzie najbardziej optymlana

Wybierając region musimy wziąć pod uwagę kilka czynników.

Wymogi prawne

w dobie tak dużego nacisku na prywatność użytkowników, musimy pamiętać czy usługa, dla której wdrażamy technologię dotyczy kraju, który wymaga przetwarzania danych w konkretnej lokalizacji, np kraje UE powinny korzystać z infrastruktury zlokalizowanej na terenie UE.

Aspekt kosztowy

obecnie lokalizacje podzielone są na dwa poziomy cenowe - Tier 1 i Tier 2. Przy małej skali obsługiwanych żądań, różnice nie będą zbytnio zauważalne, ale przy większych usługach będzie to już miało istotny wpływ. Warto zapamiętać, że Tier 1 jest opcją tańszą. Podział lokalizacji na poziomy znajdziemy tutaj: https://cloud.google.com/run/docs/locations a dokładny opis różnic cenowych w tym miejscu: https://cloud.google.com/run/pricing#tables

Aspekt ekologiczny

Niektóre z lokalizacji są oznaczone przez Google jako low CO2. Oznacza to, że lokalizacje mają wskaźnik CFE na poziomie 75% lub więcej.

Wskaźnik CFE jest wyrażany w procentach i określa jaki procent czasu infrastruktura Google w danej lokalizacji operuje na emisyjności wolnej od dwutlenku węgla. Warto pamiętać, że nie jest to żaden oficjalny wskaźnik, tylko metryka stworzona i dostarczana przez Google.

Natomiast, jeżeli nasza organizacja jest organizacją, której zależy na minimalizacji śladu węglowego, warto to również wziąć pod uwagę dokonując wyboru

Aspekt wydajnościowy

W zależności od odległości infrastruktury Cloud Run od lokalizacji w której operujemy może wystąpić różnej wielkości opóźnienie sieciowe - mimo, że różnice będą wynosiły raczej milisekundy to można przyjąć uproszczenia, że im bliżej nas tym wydajniej. Warto tutaj wspomnieć, że od 2021 mamy dostępny Polski region w GCP - europe-central2

Skoro już wiemy na co zwracać uwagę przy wyborze regionu to na koniec tej sekcji najważniejsze - przy wyborze automatycznej konfiguracji serwera tagowania nie mamy możliwości ustawienia innego regionu jak us-central1, dlatego zawsze powinniśmy konfigurować serwer manualnie.

2. Przydział procesora

Konfigurując serwer Cloud Run jednym z ustawień jest przydział procesora i ceny

Przy ręcznej konfiguracji domyślnym ustawieniem jest opcja zaznaczona na grafice powyżej i w większości przypadków jest to rekomendowane ustawienie, z wyjątkiem sytuacji, w których zależy nam na maksymalnej minimalizacji opóźnień obsługi żądań.

Ustawienie to oznacza, że nasz serwer uruchamia się dopiero w momencie otrzymania żądania i za ten czas naliczana jest dla nas opłata.

Pułapka czai się, gdy mamy skonfigurowany Cloud Run metodą automatyczną (chociaż już wiemy żeby tego nie robić), gdyż wtedy domyślnie wybrana jest opcja przydzielania procesora przez cały czas, a co za tym idzie również koszty naliczane są cały czas.

Oczywiście w konkretnych przypadkach i dla stron z dużym ruchem ma to swoje zastosowanie, natomiast dla mniejszych podmiotów, będzie to jedynie generowanie kosztów, np nocą, gdy prawie żadne żądania z naszej strony nie są otrzymywane.

Jeżeli już korzystasz z usługi Cloud Run skonfigurowanej automatycznie to rekomenduje sprawdzić i zmienić to ustawienie do momentu utworzenia nowej instancji w prawidłowym regionie.

3. Cloud Logging

Cloud logging jest to usługa polegająca na rejestrowaniu wszystkich żądań jakie są obsługiwane przez nasz serwer.

Jest to ustawienie włączone domyślnie, które możemy jednak wyłączyć, bo może istotnie wpłynąć na koszty, a z mojego doświadczenia wynika, że z funkcji tej nie korzysta się.

Musimy otworzyć router logów:

A następnie dla zasobnika _Default z menu dodatkowego wybrać opcję edycji ujścia.

W edytorze musimy zaktualizować filtr uwzględnienia dodając poniższą instrukcję:

Tak zaktualizowany filtr możemy zapisać i zaktualizować ujście.

Od teraz ta usługa nie powinna występować na naszym rozliczeniu GCP

Na pewno będziemy opisywać więcej rekomendacji dotyczących tagowanie serwer-side, optymalizacji kosztów GCP oraz nowości w GTM server-side także gorąco zachęcam do zapisania się do newslettera.

Jeżeli chciałbyś wdrożyć tagowanie server side w swojej firmie, a nie wiesz jak się do tego zabrać to zapraszam do kontaktu. Na pewno znajdziemy rozwiązanie.