Tutorial: Migracja analityki e-commerce z Client-Side na Server-Side GTM

Każdy sklep ze śledzeniem po stronie klienta raportuje mniej zakupów, niż faktycznie realizuje. Ta luka nie jest błędem do wytropienia: żądania do znanych hostów analitycznych figurują na listach filtrów, ochrona przed śledzeniem skraca życie identyfikującego pliku cookie, a osoba zamykająca kartę, zanim strona potwierdzenia skończy się renderować, w ogóle nie wysyła zdarzenia. Kontener serwerowy zmienia to, którędy biegną dane, i pokrywa tym część problemu — przeniesienie zdarzenia zakupu poza przeglądarkę pokrywa resztę.

Poniższy przewodnik traktuje to jako migrację, a nie budowę od zera: dotychczasowa konfiguracja client-side pozostaje aktywna przez cały czas, obie działają równolegle wystarczająco długo, by dało się je porównać, a przełączenie następuje dopiero wtedy, gdy uzasadniają je liczby.

Krok 1: Uruchomić obie, przełączyć później

Najbezpieczniejsza kolejność wysyła dane do kontenera serwerowego, podczas gdy konfiguracja client-side nadal raportuje do tej samej albo do równoległej usługi. Nic nie jest usuwane, żadne tagi nie są wstrzymywane, a porównanie działa na realnym ruchu, a nie w trybie podglądu.

Druga usługa GA4 jako cel migracji utrzymuje produkcyjne liczby w czystości na czas nakładania się — zdublowany zbiór danych w usłudze produkcyjnej trudniej później rozplątać, niż wyrzucić tymczasową drugą usługę. Dwa do czterech tygodni nakładania obejmuje wzorce dni roboczych i weekendów oraz co najmniej jeden pełny cykl zakupowy.

Krok 2: Postawienie serwera tagującego

W interfejsie GTM kontener serwerowy powstaje jako osobny typ kontenera, a jego ustawienia oferują automatyczne udostępnienie w Google Cloud Run. Droga automatyczna jest wygodna i daje działające wdrożenie; ręczne wdrożenie tego samego publicznego obrazu daje większą kontrolę nad regionem i skalowaniem:

gcloud run deploy sgtm \
  --image=gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --region=europe-central2 \
  --platform=managed \
  --allow-unauthenticated \
  --set-env-vars=CONTAINER_CONFIG='<config string z ustawien kontenera>'

Domyślne ustawienia są skrojone pod testy, a nie pod ruch produkcyjny; flagi instancji i pamięci to ta część, do której warto wrócić, gdy pojawi się realny wolumen. Każde środowisko uruchomieniowe kontenerów sprawdzi się tak samo — Cloud Run jest udokumentowanym domyślnym wyborem, a nie wymogiem.

Tym, co nie jest opcjonalne, jest nazwa hosta. Serwer tagujący dostępny wyłącznie pod wygenerowanym adresem chmurowym jest hostem zewnętrznym jak każdy inny; korzyść z kontekstu first-party pojawia się dopiero, gdy odpowiada on na subdomenie własnej domeny sklepu, na przykład sgtm.shop.example.com, ze wskazującym na usługę wpisem DNS i przypisanym certyfikatem.

Krok 3: Klient GA4

Kontener serwerowy nie robi nic, dopóki jakiś klient nie przejmie przychodzących żądań. Wbudowany klient GA4 nasłuchuje na ścieżkach używanych przez tag Google, rozbiera przychodzący hit i zamienia go w zdarzenie, które mogą odczytać tagi serwerowe — bez niego kontener przyjmuje żądania i je odrzuca.

Dwa ustawienia zasługują na decyzję zamiast wartości domyślnej. Klient może przejąć wystawianie identyfikującego pliku cookie zamiast zostawiać to JavaScriptowi — i to właśnie czyni ten plik odpornym na ograniczenia przeglądarek — a włączenie tego bez towarzyszącej opcji migracji resetuje tożsamość każdego powracającego odwiedzającego, więc należy to do osobnej zmiany z własną weryfikacją. Drugie dotyczy ścieżek: pozostawienie domyślnych ścieżek bez zmian jest tym, co pozwala kontenerowi webowemu wysyłać hity bez konfigurowania własnego endpointu.

Krok 4: Skierowanie kontenera webowego na serwer

Po stronie przeglądarki ruch przekierowuje jedno pole. W tagu Google w kontenerze webowym adres kontenera serwerowego ustawia się jako parametr konfiguracji; w czystej implementacji gtag.js odpowiednikiem jest transport_url:

// Parametr konfiguracji tagu Google (kontener webowy)
server_container_url: 'https://sgtm.shop.example.com'

// Odpowiednik w czystej implementacji gtag.js
gtag('config', 'G-XXXXXXXXXX', {
  server_container_url: 'https://sgtm.shop.example.com'
});

Od tego momentu przeglądarka adresuje własną subdomenę sklepu, a kontener serwerowy przekazuje dane do GA4. Kontener serwerowy ma własny tryb podglądu, pokazujący przychodzące żądanie, klienta, który je przejął, oraz każdy odpalony z niego tag — to miejsce, w którym źle skierowany hit staje się widoczny natychmiast, a nie dobę później w raportach.

Krok 5: Przeniesienie zakupu poza przeglądarkę

Kierowanie ruchu przez własną subdomenę ogranicza blokowanie; nie kończy go, a wobec odwiedzającego, który nigdy nie dociera do strony potwierdzenia, nie pomaga wcale. Dopiero zdarzenie wysłane przez backend, po potwierdzeniu zamówienia w systemie sklepu, jest całkowicie niezależne od przeglądarki.

To żądanie potrzebuje identyfikatorów, które znajdują się w przeglądarce. Client id z pliku cookie analityki trzeba odczytać w checkoucie i zapisać przy zamówieniu razem z identyfikatorem sesji, inaczej zakup dotrze bez sesji, do której mógłby się przypiąć, i wyląduje w raportach jako ruch bez źródła:

POST https://sgtm.shop.example.com/g/collect

v=2
&tid=G-XXXXXXXXXX
&cid=1234567890.1690000000     // odczytane w checkoucie z pliku cookie analityki
&sid=1789000000                // identyfikator sesji z tej samej wizyty
&en=purchase
&ep.transaction_id=ORD-10432
&epn.value=149.00
&ep.currency=PLN

Jeśli ten sam zakup jest wysyłany zarówno z przeglądarki, jak i z backendu, identyfikator transakcji musi być zgodny, żeby duplikat dało się rozpoznać i usunąć dalej w łańcuchu — alternatywą jest sklep, którego dane o przychodzie są zawyżone dokładnie o te zdarzenia, które migracja miała odzyskać.

Krok 6: Porównanie przed wyłączeniem czegokolwiek

Porównanie rozstrzygające o przełączeniu nie brzmi client-side kontra server-side, tylko każde z nich kontra liczba zamówień w sklepie. Konfiguracja serwerowa raportująca więcej zakupów niż wcześniej jest poprawą tylko wtedy, gdy dodatkowe zakupy odpowiadają realnym zamówieniom — a tabela zamówień jest punktem odniesienia, który to rozstrzyga.

Typowe obserwacje w okresie nakładania: liczby zakupów rosną o margines silnie zależny od odbiorców i miksu urządzeń, sesje zyskują na długości, bo identyfikujący plik cookie żyje dłużej, a kilka tagów okazuje się zależnych od zmiennych dostępnych wyłącznie w przeglądarce, których kontener serwerowy nie ma. To właśnie te tagi są właściwą pracą migracyjną; sam kontener jest częścią łatwą.

Pozostając w granicach

Kontener serwerowy przenosi przetwarzanie, a nie obowiązek. Stan zgody musi podróżować razem z żądaniem i zostać oceniony, zanim odpali jakikolwiek tag, oraz musi być zapisany przy zamówieniu, żeby zdarzenie backendowe również mogło go sprawdzić — żądanie wysłane z serwera nie jest zwolnione dlatego, że przeglądarka przestała brać udział. Kontener staje się też systemem z bieżącymi kosztami i dostępnością, od której zależy teraz raportowanie, a wystawiany przez niego identyfikujący plik cookie pozostaje danymi osobowymi na tych samych zasadach co wcześniej, tylko ustawianymi z innego miejsca.