Śledzenie po stronie serwera: definicja i sposób działania

Śledzenie po stronie serwera to praktyka zbierania i wysyłania zdarzeń marketingowych i analitycznych z serwera, którym kontrolujesz, zamiast polegać wyłącznie na skryptach działających w przeglądarce klienta, aby wyzwalać tagi i piksele. Zamiast przeglądarka ładowała tuzin zewnętrznych skryptów śledzących bezpośrednio, zdarzenia są najpierw przechwytywane przez własny backend lub kontener po stronie serwera, a następnie przekazywane do odpowiednich platform reklamowych i narzędzi analitycznych.

Dlaczego zastąpiło to śledzenie wyłącznie w przeglądarce#

Tagi i piksele śledzące oparte na przeglądarce zależą od tego, czy przeglądarka rzeczywiście wykona zewnętrzny kod JavaScript, co może być przerywane przez blokery reklam, funkcje zapobiegania śledzeniu w przeglądarce oraz wolne ładowanie stron. Konfiguracja po stronie serwera przenosi punkt zbierania danych poza przeglądarkę: własny serwer rejestruje zdarzenie w momencie jego wystąpienia, np. w systemie zamówień, i wysyła je dalej, co jest znacznie mniej kruche.

Popularne implementacje#

Domain śledzenia pierwszej strony kieruje żądania tagów przez własną subdomenę zamiast przez zewnętrzną, dzięki czemu blokery reklam na poziomie przeglądarki rzadziej oznaczają ruch. Kontener menedżera tagów po stronie serwera, najczęściej spotykany przykład to opcja serwerowa Google Tag Manager, zapewnia pojedynczy punkt końcowy serwera, który odbiera zdarzenia i rozsyła je do wielu docelowych miejsc. Specyficzne dla platform API zdarzeń wysyłają zdarzenia bezpośrednio do serwerów konkretnej sieci reklamowej. W konfiguracjach afiliacyjnych lub CPA, adres URL postback realizuje podobną funkcję, pozwalając serwerowi sieci powiadomić Twój serwer (lub odwrotnie) bezpośrednio w momencie zakończenia konwersji.

Co poprawia, a czego nie#

Śledzenie po stronie serwera zazwyczaj zwiększa kompletność śledzenia konwersji, ponieważ zdarzenia nie zależą już od integralnej sesji przeglądarki. Może także zmniejszyć wagę ładowania strony, gdyż mniej zewnętrznych skryptów musi być uruchamianych po stronie klienta. Nie rozwiązuje jednak samo w sobie problemu atrybucji w wielu kanałach; dobrze zarejestrowane zdarzenie nadal wymaga modelu decydującego, jaką część kredytu przyznać poszczególnym punktom kontaktu. Śledzenie po stronie serwera zapewnia jedynie, że zdarzenie istnieje. Nie decyduje, kto za nie otrzyma kredyt.

Rozważania przy wdrażaniu#

Przeniesienie śledzenia na serwer to rzeczywiście więcej pracy inżynieryjnej niż wstawienie fragmentu piksela na stronę: potrzebny jest niezawodny potok zdarzeń, sposób na deduplikację zdarzeń rejestrowanych zarówno po stronie klienta, jak i po stronie serwera dla tej samej konwersji, oraz bieżąca konserwacja w miarę aktualizacji API każdej platformy reklamowej. Większość zespołów zaczyna od najcenniejszego zdarzenia konwersji, czyli zakończonego zakupu, i rozwija rozwiązanie od tego punktu, zamiast migrować wszystkie tagi jednocześnie. Spójne identyfikatory śledzenia kliknięć we wszystkich sieciach znacznie ułatwiają ten krok deduplikacji.

Gdzie precyzyjne śledzenie ma największe znaczenie#

Czyste dane konwersji przynoszą największe korzyści, gdy porównujesz wyniki w wielu sieciach reklamowych o różnej wiarygodności śledzenia. Sieć z słabszym natywnym wsparciem dla pikseli może wydawać się sztucznie gorsza w Twoim panelu, wyłącznie z powodu utraty danych śledzenia, a nie z powodu niższej jakości ruchu. Zanim przekażesz budżet w oparciu o porównanie dotknięte ograniczeniami śledzenia, sprawdź, co faktycznie jest uruchomione i jak długo w każdej sieci. Platforma inteligencji reklamowej OpenAdLibrary zapewnia wgląd w długość trwania reklam i wolumen kreacji według sieci, będąc niezależnym sygnałem obok własnych liczb śledzenia.