Hosting server-side GTM: Cloud Run, Stape czy własny serwer – koszty i wydajność

Jakie są opcje hostingu server-side GTM

Masz trzy realne możliwości: Google Cloud Run, dostawcę zarządzanego albo własną infrastrukturę. Wybór zależy głównie od tego, kto w firmie będzie odpowiadał za serwer.

Google Cloud Run to domyślna ścieżka Google. Kreator kontenera serwerowego może automatycznie utworzyć usługę w regionie us-central1, ale według dokumentacji służy ona do testów. Produkcję uruchamiasz ręcznie, w wybranym regionie – dla ruchu z Polski naturalnym wyborem jest europe-central2 w Warszawie. Rozliczenie odbywa się w ramach konta Google Cloud, a usługa skaluje się automatycznie między ustaloną minimalną i maksymalną liczbą instancji. Pełną procedurę uruchomienia opisujemy w poradniku server-side tagging w praktyce.

Dostawcy zarządzani, tacy jak Stape czy TAGGRS, utrzymują serwer za Ciebie. W panelu wklejasz ciąg konfiguracji kontenera, wybierasz lokalizację i podpinasz własną domenę. W zamian płacisz abonament i polegasz na infrastrukturze dostawcy. Zaletą są dodatki, np. ładowanie skryptów pod niestandardową ścieżką, funkcje związane z ciasteczkami czy wbudowany podgląd logów.

Własny serwer to obraz Dockera od Google uruchomiony na maszynie wirtualnej, w klastrze Kubernetes albo w innej chmurze. Masz pełną kontrolę, ale bierzesz na siebie wszystko: certyfikaty, skalowanie, aktualizacje i ciągłość działania.

Ile kosztuje hosting server-side GTM na Cloud Run

Głównym kosztem Cloud Run są stale działające instancje. Google szacuje koszt jednej instancji z 1 vCPU i 0,5 GB pamięci, w modelu ze stale przydzielonym procesorem, na ok. 45–50 USD miesięcznie.

Minimalny rachunek to liczba stałych instancji pomnożona przez tę kwotę, a realny zakres wyznacza maksymalna liczba instancji, do której pozwolisz usłudze się skalować. Do tego dochodzą: ruch wychodzący, który rośnie, gdy serwer serwuje skrypty, globalny load balancer, jeśli z niego korzystasz przy własnej domenie, oraz logi. Te ostatnie przy ponad milionie żądań miesięcznie potrafią stanowić zauważalną część rachunku, dlatego warto wyłączyć logowanie każdego żądania. Poniższe wyliczenie jest hipotetyczne.

Przy założonym kursie 3,70 zł daje to ok. 390–430 zł miesięcznie. Dokładne kwoty dla swojego ruchu policzysz w kalkulatorze cen Google Cloud, a przed sezonem ustaw w Cloud Billing alerty budżetowe – podobnie jak przy kontroli wydatków na hurtownię danych, którą opisujemy w tekście o kosztach BigQuery w marketingu.

Stape i inni dostawcy zarządzani: co dostajesz za abonament

Dostawca zarządzany sprzedaje gotowy serwer tagowania z panelem, wsparciem i dodatkami. Cena zależy zwykle od miesięcznego limitu żądań, a najniższe plany służą do testów.

Cenniki zmieniają się często, dlatego przed decyzją sprawdź aktualne warunki u dostawcy. Zwróć uwagę na pięć rzeczy:

• Limit żądań i jego przekroczenie. Ustal, czy po przekroczeniu limitu dostawca odrzuca żądania, spowalnia je, czy automatycznie podnosi plan. Pierwsza możliwość oznacza utratę danych w najgorszym momencie, np. w Black Friday.
• Lokalizacja serwerów. Dla polskiego sklepu najlepiej wybrać serwery w Unii Europejskiej.
• Umowa powierzenia przetwarzania danych. Przez serwer dostawcy przechodzą m.in. adresy IP i identyfikatory użytkowników, więc dostawca działa jako podmiot przetwarzający. Więcej o podstawach prawnych piszemy w artykule o RODO w reklamie online; w konkretnej sprawie warto skonsultować się z prawnikiem.
• Wysoka dostępność. Sprawdź, czy plan obejmuje kilka serwerów lub stref, czy jeden.
• Dodatki i uzależnienie. Funkcje specyficzne dla dostawcy ułatwiają pracę, ale utrudniają późniejszą przeprowadzkę. Zapisz, z których korzystasz.

Dostawca zarządzany jest dobrym wyborem, gdy w zespole nie ma osoby znającej Google Cloud, a sklep potrzebuje serwera głównie do GA4, Google Ads i Meta Conversions API.

Własny serwer: Docker na maszynie wirtualnej lub w Kubernetes

Własny hosting wykorzystuje ten sam obraz, który działa w Cloud Run. Potrzebujesz dwóch usług: serwera podglądu i serwera tagowania, połączonych zmiennymi środowiskowymi.

docker run -d --name sgtm-preview -p 8081:8080 \
  -e CONTAINER_CONFIG="TWOJ_CIAG_KONFIGURACJI" \
  -e RUN_AS_PREVIEW_SERVER=true \
  gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

docker run -d --name sgtm -p 8080:8080 \
  -e CONTAINER_CONFIG="TWOJ_CIAG_KONFIGURACJI" \
  -e PREVIEW_SERVER_URL="https://podglad.sgtm.twojsklep.pl" \
  gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

To tylko punkt wyjścia. Na produkcji potrzebujesz co najmniej dwóch instancji za load balancerem, terminacji HTTPS z certyfikatem dla własnej domeny, kontroli stanu przez ścieżkę /healthz oraz procedury aktualizacji obrazu, bo Google regularnie publikuje nowe wersje. Dochodzą też monitoring, rotacja logów i plan na szczyty ruchu. Sam serwer bywa tani, ale godziny pracy osoby odpowiedzialnej za infrastrukturę szybko przewyższają różnicę w cenie względem Cloud Run.

Porównanie opcji hostingu: koszty, wydajność, kontrola

Każda opcja wygrywa w innym obszarze. Zestawienie pomaga dopasować wybór do zasobów zespołu.

Jeśli planujesz wzbogacać zdarzenia danymi z Firestore lub BigQuery, Cloud Run w tym samym projekcie Google Cloud upraszcza uprawnienia – przykłady takich konfiguracji znajdziesz w tekście o wzbogacaniu zdarzeń po stronie serwera. Gdy zależy Ci wyłącznie na tagach Google w domenie sklepu, rozważ rozwiązanie bez serwera, opisane w porównaniu Google Tag Gateway i server-side GTM.

Jak oszacować liczbę żądań i dobrać plan

Liczba żądań decyduje o planie u dostawcy zarządzanego i o liczbie instancji w Cloud Run. Oszacujesz ją z danych GA4 w kilka minut.

1. Sprawdź liczbę sesji. W GA4 odczytaj liczbę sesji z ostatnich 12 miesięcy i wybierz najmocniejszy miesiąc.
2. Policz zdarzenia na sesję. Podziel liczbę zdarzeń przez liczbę sesji w tym samym okresie.
3. Pomnóż. Iloczyn to przybliżona liczba żądań GA4. Tag Google potrafi łączyć kilka zdarzeń w jednym żądaniu, więc taki wynik jest szacunkiem z zapasem.
4. Dodaj skrypty. Jeśli serwer ma serwować gtm.js lub gtag.js, dolicz żądania skryptów na odsłonę.
5. Dodaj inne źródła. Zdarzenia wysyłane z backendu sklepu, webhooki z CRM czy płatności.
6. Policz szczyt. Przelicz najbardziej obciążoną godzinę na żądania na sekundę i dodaj 30–50% zapasu.

Załóżmy, że sklep ma 200 000 sesji miesięcznie, średnio 12 zdarzeń na sesję i 3 odsłony na sesję, a serwer serwuje też skrypt kontenera. Daje to ok. 2,4 mln żądań zdarzeń i 0,6 mln żądań skryptów, razem ok. 3 mln miesięcznie, czyli średnio nieco ponad 1 żądanie na sekundę. Nawet przy dziesięciokrotnie większym ruchu w szczycie mieści się to w przepustowości dwóch instancji, bo Google podaje, że zakres 2–10 instancji obsługuje ok. 35–350 żądań na sekundę. Przed sezonem podnieś jednak minimalną liczbę instancji – planowanie szczytu opisujemy w tekście o budżecie na Black Friday i Q4.

Wydajność i niezawodność: na co zwrócić uwagę

Wydajność serwera tagowania zależy głównie od regionu, liczby stałych instancji i czasu odpowiedzi dostawców, do których wysyłasz dane. Każdy z tych elementów możesz kontrolować.

Region blisko użytkowników skraca czas odpowiedzi – dla Polski to Warszawa lub inny region europejski. Minimalna liczba instancji chroni przed tzw. zimnymi startami, czyli opóźnieniem przy uruchamianiu nowej instancji podczas skoku ruchu. Tagi czekające na odpowiedź zewnętrznego API wydłużają przetwarzanie, więc sprawdzaj w podglądzie czasy żądań wychodzących.

Po uruchomieniu obserwuj liczbę żądań, opóźnienia i odsetek błędów 5xx, a po stronie danych – liczbę zdarzeń w GA4. Alerty o nagłych spadkach opisujemy w tekście o monitoringu tagów na produkcji, a przegląd konfiguracji przed sezonem – w audycie tagów przed Black Friday. Serwer tagowania to inwestycja w dane first-party, więc jego niezawodność warto traktować jak niezawodność samego sklepu. Opis narzędzia znajdziesz na stronie Google Tag Manager, a pozostałe poradniki – w podtemacie server-side tagging.