Jak wykonać aktualizację kontenera GTM Server-Side?

07.2024 | Google Tag Manager | Server-Side | App Engine

Wykorzystanie kontenera GTM Server-Side nakłada na analityka dodatkowy obowiązek, związany z monitoringiem kolejnych wersji kontenera i cyklicznym wykonywaniem aktualizacji. Te aktualizacje wykonujemy poprzez interfejs Google Cloud Platform, co może stwarzać pewne trudności, ale też regularna dbałość o aktualizacje, daje nam gwarancję optymalnego wykorzystania i działania GTM Server-Side. W niniejszym artykule przedstawiam proces samodzielnej aktualizacji kontenera serwerowego, opartego o App Engine.
 

Spis treści

• Jak zweryfikować czy nasz tag powinien być zaktualizowany?
• Proces aktualizacji kontenera
• Podsumowanie

Kontener GTM Server-Side pozwala przenieść mechanizm odpalania tagów z poziomu przeglądarki na poziom serwera, co pozwala poprawić nasz status implementacji web analityki np. poprzez poprawę wydajności serwisu czy dodatkowy mechanizm kontroli nad danymi.

Implementacja kontenera serwerowego, to jednak nie tylko korzyści, ale też i obowiązki, szczególnie jeżeli do tej implementacji wykorzystujemy Google Cloud Platform i usługi typu App Engine czy Cloud Run.

Otóż, obowiązek jaki na nas spoczywa, to obowiązek aktualizacji serwera, który odpowiada z hosting tagu serwerowego GTM.

W niniejszym poście przedstawię proces tej aktualizacji.
 

Jak zweryfikować czy nasz tag powinien być zaktualizowany?

Logujemy się do naszego kontenera serwerowego i następnie przechodzimy do sekcji Admin:

W sekcji Admin, klikamy pozycję Container Settings i jako rezultat zobaczymy następujący widok:

Interesująca nas sekcja jest opisana jako Tagging Server Version - w sekcji tej znajdziemy informację o tym jaka jest nasza aktualna wersja kontenera i jaka jest wersja najnowsza.

W omawianym przypadku widzimy, że najnowsza wersja jest oznaczona jako 2.1.0 a wersja wykorzystywana na stronie surowiecki.org, to wersja 2.1.0.

W tym przypadku aktualizacja nie jest konieczna, ale dla celów czysto edukacyjnych, w kolejnych krokach, pokażę jak dokonać aktualizacji naszego kontenera do wersji 2.3.0.
 

Proces aktualizacji kontenera

Proces aktualizacji kontenera jest realizowany z poziomu interfejsu Google Cloud Platform. Aby zatem rozpocząć ten proces, zalogujmy się do naszego konta GCP.
 

1. Wybór odpowiedniego projektu

Wybierzmy odpowiedni projekt, w którym jest nasz kontener.

2. Otwieramy konsolę, czyli Google Platform Cloud Shell

Należy odczekać chwilę, podczas której następuje aktywacja konsoli.

3. Cloud Shell. Komendy aktualizacji

Komendy aktualizacji, jakie wpisujemy w konsoli Cloud Shell, to kolejno:

gcloud config set project gtm-pkrwgfd9-zdlmn

gdzie:

gtm-pkrwgfd9-zdlmn ⇒ ID naszego projektu (ID można pobrać ze strony startowej projektu tzn. https://console.cloud.google.com/home/dashboard, czyli Cloud Overview > Dashboard)

Następnie wpisujemy:

bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"

Ten kod wykonuje następujące czynności:

A. Pobiera skrypt:

curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh pobiera skrypt powłoki Bash (setup.sh) z serwera Google Tag Manager.

fsSL to flagi dla curl:

• f (fail silently): nie wyświetla komunikatów o błędach HTTP
• s (silent mode): nie wyświetla paska postępu
• S (show error): wyświetla komunikaty o błędach
• L (location): podąża za przekierowaniami

B. Wykonuje skrypt:

bash -c "..." uruchamia powłokę Bash i przekazuje jej pobrany skrypt jako polecenie do wykonania.

Po uruchomieniu w/w skryptu zobaczymy kreator, który poprosi nas o potwierdzenie lub zmianę kluczowych ustawień, dotyczących naszego kontenera.

Kolejne operacje jakie są tutaj wykonywane to:

• Container Config: Jest to unikalny identyfikator Twojego kontenera serwerowego GTM. Zwykle nie musisz go zmieniać, chyba że masz konkretny powód.
• Policy Script URL (Optional): To pole pozwala na określenie adresu URL skryptu, który będzie kontrolował dostęp do Twojego kontenera serwerowego. Jest to opcjonalne ustawienie zaawansowane i zwykle nie jest wymagane.
• Request Logging (Current: on): Określa, czy żądania wysyłane do kontenera serwerowego będą rejestrowane. Rejestrowanie żądań może być przydatne do debugowania, ale może również generować dodatkowe koszty.
• Deployment Type (Current: testing): możliwość zmiany na wersję produkcyjną, poprzez wpisanie słowa "production". Zmienia to typ wdrożenia z "testing" na "production". Wdrożenie testowe jest przeznaczone do testowania i nie jest skalowane automatycznie. Wdrożenie produkcyjne jest skalowane automatycznie i jest przeznaczone do obsługi ruchu na żywo.
• Autoscaling (Recommended: on): Włącza automatyczne skalowanie. Oznacza to, że Google Cloud Platform automatycznie zwiększy lub zmniejszy liczbę serwerów obsługujących Twój kontener serwerowy GTM w zależności od obciążenia.
• Minimum Number of Servers (Recommended: 3): 1: Określa minimalną liczbę serwerów, które będą zawsze działać, nawet przy niskim obciążeniu.
• Maximum Number of Servers (Recommended: 6): 3: Określa maksymalną liczbę serwerów, które mogą być używane do obsługi Twojego kontenera serwerowego.
• CPU Target Utilization (Recommended: 0.6): Określa docelowy poziom wykorzystania procesora, przy którym automatyczne skalowanie będzie działać. Na przykład, jeśli ustawisz ten parametr na 0.6, automatyczne skalowanie będzie się uruchamiać, gdy wykorzystanie procesora przekroczy 60%.

Po wprowadzeniu wszystkich ustawień i ich zatwierdzeniu, zobaczymy kolejne kroki konfiguracji i deploy-u naszego nowego kontenera. Całość będzie trwała około 10 minut.

Nasz proces aktualizacji zakończył się pomyślnie, aczkolwiek wymagane jest około 2-3 dni, aby ta informacja również pojawiła się w panelu Google Tag Managera.
 

Podsumowanie

Google Tag Manager Server-Side wymaga dbałości nie tylko ze strony samego kontenera, ale też wymaga opieki ze strony Google Cloud Platform, gdzie hostowany jest nasz tag poprzez usługę App Engine czy Cloud Run.

Niniejszy artykuł przedstawił proces aktualizacji dla tagu GTM opartego o App Engine.