Google Tag Gateway nie zastępuje server-side Google Tag Manager. Zmienia to sposób, w jaki obsługiwane skrypty Google i żądania pomiarów docierają do Google. sGTM odbiera zdarzenia w kontrolowanym przez Ciebie kontenerze serwera, a następnie umożliwia klientom, wyzwalaczom, zmiennym i tagom sprawdzanie, przekształcanie i kierowanie tych zdarzeń. Wspólny język własny sprawia, że produkty wydają się wymienne, ale ich zadania są różne.
Krótka odpowiedź: dostawa nie jest przetwarzana
W standardowej konfiguracji tagu Google przeglądarka ładuje skrypt z domeny Google i wysyła pomiar bezpośrednio do produktu Google. Google Tag Gateway przenosi obsługiwane ścieżki skryptów i żądań do domeny Twojej witryny, a Twoja sieć CDN, moduł równoważenia obciążenia lub serwer WWW przekierowują ruch do Google.
GTM po stronie serwera dodaje środowisko wykonawcze do przetwarzania zdarzeń. Przychodzące żądania HTTP są odbierane przez klienta, konwertowane na zdarzenia i oceniane przez kontener serwera. Ty decydujesz, które tagi zostaną uruchomione, które pola opuszczą serwer i które miejsca docelowe otrzymają zdarzenie. To znacznie szersze pojęcie niż przekazywanie obsługiwanego ruchu Google.
Co Google Tag Gateway może, a czego nie może zrobić
GTG może ograniczyć interakcje stron trzecich w przeglądarce i odzyskać niektóre sygnały, które zawodzą tylko dlatego, że znana nazwa hosta Google jest zablokowana. Umożliwia także Google wykorzystanie wybranych własnych plików cookie Google w przypadku przekazanego żądania; Google twierdzi, że własne pliki cookie innych firm są usuwane.
Nie tworzy brakujących zdarzeń e-commerce, nie naprawi słabej warstwy danych, nie sprawdza przychodów, nie wzbogaca zdarzenia z Twojego CRM ani nie wysyła żądań Meta CAPI i TikTok Events API. Nie znosi również obowiązku uzyskania zgody. Tag Google nadal działa w przeglądarce, a awarie po stronie przeglądarki, stan zgody i błędy implementacji nadal mają znaczenie.
Co dodaje server-side GTM
sGTM jest przydatny, gdy serwer musi wykonać pracę, zanim dostawca otrzyma zdarzenie. Przykłady obejmują usuwanie niezatwierdzonych parametrów, normalizację nazw zdarzeń, uzyskiwanie ładunków specyficznych dla miejsca docelowego, ustawianie plików cookie serwera, stosowanie logiki zgody i rejestrowanie odpowiedzi wychodzących w celu rozwiązywania problemów.
Kompromisem jest własność. Kontener serwera wymaga hostingu, konfiguracji produkcji i podglądu, monitorowania, kontroli dostępu, przeglądu szablonów i osoby, która może zdiagnozować pełną ścieżkę. sGTM tworzy kontrolę, a nie automatyczną poprawność.
Dlaczego mit o zastąpieniu wciąż istnieje
Obydwa produkty korzystają z własnego punktu końcowego i oba są opisane jako poprawiające jakość sygnału. Z poziomu panelu marketera każdy z nich może wyglądać jak sposób na zwiększenie trwałości pomiarów Google. Różnica architektoniczna kryje się za podobnym językiem wyników.
Przydatnym testem jest pytanie, co się stanie, gdy żądanie dotrze do Twojej domeny. Jeśli ścieżka po prostu przekazuje obsługiwane żądanie Google do Google, jest to zachowanie bramy. Jeśli Twój kontener przejmie żądanie, zbuduje zdarzenie i zdecyduje, które tagi i miejsca docelowe zostaną uruchomione, czyli server-side GTM.
Który wybrać?
Wybierz sam GTG, gdy Twój zakres obsługuje głównie pomiary Google, korzystasz już z kompatybilnego CDN lub modułu równoważenia obciążenia i nie potrzebujesz współdzielonej warstwy danych po stronie serwera. Jest to mniejsze zaangażowanie operacyjne.
Wybierz sGTM, jeśli potrzebujesz interfejsów API konwersji innych niż Google, transformacji, minimalizacji danych, zarządzania zdarzeniami lub danych wejściowych zaplecza. Jeśli już uruchomiłeś sGTM, Google poinstruuje Cię, jak włączyć zachowanie bramy w konfiguracji po stronie serwera. Produkty mogą zatem uzupełniać się, nie stając się dwoma konkurencyjnymi źródłami wydarzeń.
Własny adres URL nie jest dowodem przetwarzania po stronie serwera
Sprawdź całą trasę. Żądanie przeglądarki skierowane do Twojej domeny może nadal stanowić przeskok proxy bezpośrednio do Google. Może to być cenne, ale nie jest tym samym, co zdarzenie przetwarzane przez kontener serwera.
Wybierz odpowiednią architekturę w sześciu kontrolach
Skorzystaj z tych kontroli przed wymianą istniejącej konfiguracji lub zatwierdzeniem nowej.
- 01
Wypisz wszystkie miejsca docelowe
Obejmuje GA4, Google Ads, Floodlight, Meta, TikTok, LinkedIn, systemy CRM i magazyny. GTG nie jest routerem ogólnym na tej liście.
- 02
Wymień wymagane przetwarzanie
Przed dostawą zaznacz każde zdarzenie, które wymaga walidacji, wzbogacenia, redakcji, zmiany nazewnictwa, zasad zgody lub deduplikacji.
- 03
Narysuj rzeczywiste ścieżki żądań
Pokaż, gdzie ładują się skrypty, gdzie docierają zdarzenia przeglądarki i backendu, który komponent je przetwarza i który punkt końcowy je ostatecznie odbiera.
- 04
Przypisz jednego właściciela do wydarzenia
Dla każdego miejsca docelowego określ, czy przeglądarka, ścieżka GTG czy tag sGTM mają wysyłać zdarzenie. Dwóch właścicieli tworzy duplikaty.
- 05
Testuj stany zgody i niepowodzenia
Testuj zgodę udzieloną i odrzuconą, blokery, nieprawidłowe ładunki, zduplikowane identyfikatory transakcji i niedostępne miejsce docelowe.
- 06
Pogódź się z prawdą źródłową
Porównaj zaakceptowane konwersje i przychody z rekordami e-commerce lub CRM. Pomyślne żądanie sieciowe nie jest dowodem na to, że liczby są prawidłowe.
GTG to skupiona warstwa dostarczania, a nie sGTM lite
Google Tag Gateway rozwiązuje prawdziwy, ale węższy problem: obsługę obsługiwanych skryptów Google i pomiary za pośrednictwem infrastruktury własnej. GTM po stronie serwera to środowisko przetwarzania i routingu zdarzeń. Jedno nie wymazuje potrzeby drugiego.
Zacznij od wymagań, a nie od etykiet produktów. Jeśli wymagana jest własna dostawa Google, wystarczy GTG. Jeśli wymaganie dotyczy pomiarów po stronie serwera w wielu miejscach docelowych, nadal potrzebujesz sGTM lub innej warstwy przetwarzania.
Google Tag Gateway vs sGTM: często zadawane pytania
Czy Google Tag Gateway zastępuje server-side GTM?
Nie. GTG przekazuje obsługiwane tagi i żądania Google za pośrednictwem własnej infrastruktury. sGTM przetwarza zdarzenia w programowalnym kontenerze serwerowym i może kierować je na kilka platform.
Czy Google Tag Gateway śledzi po stronie serwera?
Wykorzystuje infrastrukturę serwerową jako bramę, ale zdarzenie przeglądarki nie jest przetwarzane we własnym programowalnym kontenerze. Nazywanie go zamiennikiem server-side GTM jest zatem mylące.
Czy GTG może wysyłać zdarzenia do Meta lub TikTok?
Nie. GTG skupia się na obsługiwanych tagach i miejscach docelowych Google. Użyj sGTM lub innej integracji po stronie serwera dla interfejsów API konwersji innych niż Google.
Czy GTG eliminuje potrzebę uzyskania zgody?
Nie. Własna trasa nie zmienia celu przetwarzania ani wyboru użytkownika. Skonfiguruj i przetestuj zachowanie polegające na wyrażeniu zgody dla każdego regionu, w którym działasz.
Czy mogę używać razem GTG i sGTM?
Tak. Google dokumentuje łączną konfigurację, w której obsługa skryptów własnej firmy i ścieżka gromadzenia danych sGTM mają oddzielne obowiązki.