Server-side tracking: czym jest i co zmienia w pomiarze

Server-side tracking przenosi wysyłkę danych pomiarowych z przeglądarki użytkownika na serwer pośredniczący, którym zarządza sklep. Zmienia się miejsce, z którego dane są wysyłane, nie zakres tego, co jest zbierane. To rozróżnienie jest źródłem większości nieporozumień wokół tego rozwiązania, bo pomiar serwerowy bywa mylnie przedstawiany jako sposób na zbieranie danych, na które użytkownik nie wyraził zgody.

Jak działa pomiar po stronie przeglądarki i gdzie się psuje

W standardowym modelu client-side każde narzędzie ma własny skrypt działający w przeglądarce użytkownika. GA4 ma swój, Meta swój, Google Ads swój, do tego dochodzą narzędzia do map ciepła, czatu i testów A/B. Każdy z nich zbiera dane samodzielnie i wysyła je bezpośrednio do własnego serwera.

Ten model ma jedną cechę, która przy rosnących ograniczeniach prywatności staje się problemem: każdy skrypt jest osobnym punktem awarii. Wystarczy, że jeden z nich nie zostanie wykonany, i dane z tego narzędzia znikają, niezależnie od tego, czy pozostałe zadziałały.

• Blokery treści i rozszerzenia prywatności. Wiele z nich blokuje żądania do znanych domen analitycznych i reklamowych na podstawie list.
• Mechanizmy ochrony prywatności w przeglądarkach. Ograniczają czas życia identyfikatorów zapisywanych skryptem.
• Przerwanie sesji przed wysłaniem zdarzenia. Zamknięcie karty tuż po zatwierdzeniu płatności oznacza, że zdarzenie zakupu nigdy się nie wywoła.
• Błędy w wykonaniu skryptów. Konflikt między skryptami, błąd JavaScript wcześniej na stronie, wolne ładowanie na słabym połączeniu.
• Obciążenie strony. Kilkanaście skryptów zewnętrznych to kilkanaście osobnych połączeń, co przekłada się na czas ładowania, a ten na współczynnik konwersji.

Suma tych czynników daje różnicę między liczbą transakcji w sklepie a liczbą transakcji w narzędziach analitycznych. Ta różnica sama w sobie nie jest błędem. Problemem staje się wtedy, gdy rośnie i gdy nie wiadomo, jaka jej część wynika z mechaniki pomiaru, a jaka z błędu, który da się naprawić.

Jak wygląda przepływ danych w modelu serwerowym

1. Przeglądarka wysyła dane w jedno miejsce. Zamiast do kilkunastu zewnętrznych domen, żądanie trafia do jednego endpointu, zwykle w subdomenie serwisu sklepu.
2. Kontener serwerowy odbiera dane. Działa na serwerze kontrolowanym przez sklep.
3. Dane są przetwarzane w kontrolowanej warstwie. Można je wzbogacić informacjami z zaplecza sklepu, przefiltrować albo zatrzymać, jeśli nie ma podstawy do wysłania.
4. Kontener rozsyła dane do narzędzi docelowych. Do GA4, do interfejsów platform reklamowych, do hurtowni danych.

Trzeci punkt jest tym, który najczęściej umyka w dyskusji o pomiarze serwerowym, a to on daje najwięcej. Pojawia się warstwa, którą kontroluje sklep, a nie dostawca narzędzia.

Czym jest własna domena pomiarowa i dlaczego ma znaczenie

Własna domena pomiarowa oznacza, że endpoint odbierający dane działa w subdomenie serwisu sklepu, a nie w domenie zewnętrznego dostawcy. Konsekwencja jest techniczna: identyfikatory zapisywane w kontekście tej domeny mają status ustawionych przez pierwszą stronę, co w części przeglądarek oznacza dłuższy czas życia i mniejsze ryzyko zablokowania.

Pomiar serwerowy bez własnej domeny pomiarowej rozwiązuje część problemów, ale nie ten. Efekt daje dopiero połączenie obu elementów.

Co server-side tracking realnie poprawia

Efekty przewidywalne, niezależne od profilu odbiorców:

• Mniejsze obciążenie strony — zamiast kilkunastu skryptów zewnętrznych działa jeden.
• Kontrola nad danymi opuszczającymi infrastrukturę.
• Możliwość wzbogacania zdarzeń danymi z zaplecza: marża, status klienta, kategoria, koszt produktu.
• Jedno miejsce zmian — dodanie nowego narzędzia to konfiguracja w kontenerze, nie kolejny skrypt na stronie.

Efekty, których skala zależy od profilu ruchu:

• Wyższa kompletność zarejestrowanych zdarzeń.
• Dłuższe utrzymanie identyfikatorów użytkownika.
• Mniejsza utrata zdarzeń przy przerwanych sesjach.

Dlatego nie da się rzetelnie podać, ile konwersji odzyskasz. Każda liczba podana jako uniwersalna jest liczbą z cudzego wdrożenia w cudzej branży.

Czego server-side tracking nie naprawi

• Nie zwalnia z respektowania zgód użytkownika. Podstawa prawna przetwarzania nie zależy od tego, z którego serwera wychodzi żądanie.
• Nie usuwa rozbieżności wynikających z definicji metryk.
• Nie naprawia błędów w warstwie danych — przetransportuje je sprawniej i pewniej niż wcześniej.
• Nie zastępuje modelu danych i konwencji nazewnictwa.
• Nie rozwiązuje problemu atrybucji. Każda platforma nadal liczy konwersje według własnego modelu i własnego okna.

Co wchodzi w koszt wdrożenia i utrzymania

Największym kosztem długoterminowym nie jest serwer, tylko utrzymanie. Kontener, którego nikt nie aktualizuje, po kilku miesiącach zaczyna gubić zdarzenia w sposób trudny do zauważenia.

Kiedy wdrożenie ma sens, a kiedy jest przedwczesne

Wdrażaj, jeśli:

• Rozbieżność między danymi analitycznymi a systemem sklepowym jest wysoka i rośnie.
• Duża część ruchu pochodzi z urządzeń mobilnych albo segmentów o wysokim udziale blokerów.
• Potrzebujesz wzbogacać zdarzenia danymi z zaplecza, np. marżą.
• Masz uporządkowaną warstwę danych.
• Jest wskazana osoba, która będzie utrzymywała konfigurację.

Od czego zacząć, jeśli decyzja jest na tak

1. Zmierz i zapisz obecną rozbieżność. Zestaw dzień po dniu transakcje w narzędziu analitycznym z zamówieniami w systemie sklepowym za ostatnie trzy miesiące.
2. Zaudytuj warstwę danych. Sprawdź, czy zdarzenia wywołują się konsekwentnie dla wszystkich metod płatności.
3. Zdecyduj o modelu hostingu. Kontener zarządzany, własna chmura, rozwiązanie hostowane jako usługa.
4. Skonfiguruj własną domenę pomiarową.
5. Przenieś jedno zdarzenie, nie wszystkie naraz. Zacznij od zdarzenia zakupu, puść równolegle w obu modelach przez co najmniej dwa tygodnie.
6. Ustaw monitorowanie i alerty.

Najczęstsze pytania

Czy server-side tracking jest zgodny z RODO?

Sama architektura pomiaru nie decyduje o zgodności. Decyduje podstawa prawna przetwarzania, respektowanie zgód użytkownika i zakres przekazywanych danych.

Ile kosztuje utrzymanie kontenera serwerowego?

Koszt infrastruktury skaluje się z liczbą żądań. Do tego dochodzi koszt utrzymania konfiguracji, zwykle większy niż sama infrastruktura.

Czy server-side eliminuje rozbieżności między GA4 a sklepem?

Ogranicza je, ale nie eliminuje, bo część rozbieżności wynika z różnych definicji metryk i momentu pomiaru.

Czy da się wdrożyć pomiar serwerowy tylko dla części zdarzeń?

Tak, i to zalecane podejście przy pierwszym wdrożeniu.

Zmierz rozbieżność między swoim narzędziem analitycznym a systemem sklepowym za ostatnie trzy miesiące. Bez tej liczby decyzja o wdrożeniu pomiaru serwerowego jest decyzją bez danych.

TRIVERO Team