Co to jest Server-Side Tagging i kiedy naprawdę ma sens

Server-side tagging coraz częściej nazywany jest przyszłością trackingu. W Polsce popularność zdobywa na razie powoli, ale kierunek jest jasny, bo rekomendują go najwięksi gracze reklamowi z Google i Metą na czele, a klasyczny pomiar w przeglądarce widzi z roku na rok coraz mniej. W tym artykule opiszę, jak ta technologia działa od środka, i obalę po drodze kilka mitów, które narosły wokół niej szybciej niż wdrożenia.

Rozpocznę od dwóch korzyści, które przy server-side taggingu pojawiają się w niemal każdej rozmowie: odzyskany ruch z blokerów reklam i ciasteczka, które przestają umierać po tygodniu. W moich wdrożeniach największą różnicę robiły jednak zakupy mierzone zupełnie bez udziału przeglądarki. Odpowiedź na pytanie, dlaczego GA4, czyli Google Analytics 4, pokazuje mniej transakcji niż panel sklepu, ma znacznie więcej warstw niż same blokery reklam. A sam server-side tagging daje więcej niż te dwie najczęściej wymieniane korzyści. Na sam koniec zostawiam instrukcję, jak policzyć własną dziurę pomiarową, mając pod ręką wyłącznie panel sklepu i raporty z analityki.

Jak działa server-side tagging

Server-side tagging, po polsku tagowanie po stronie serwera, to sposób pomiaru, w którym dane między sklepem a platformami reklamowymi pokonują inną drogę: nie prosto z przeglądarki klienta, tylko przez serwer pomiarowy należący do sklepu. W klasycznym układzie przeglądarka każdego klienta rozmawia z każdą platformą osobno: skrypt Google wysyła dane do Google, skrypt Mety do Mety, i tak dalej dla każdego kolejnego narzędzia. W układzie serwerowym między przeglądarką a platformami staje właśnie ten serwer, działający pod własnym adresem sklepu. Przeglądarka rozmawia już tylko z nim, a on decyduje, co, dokąd i w jakiej postaci zostanie przekazane dalej. Najczęściej sercem takiego serwera jest serwerowa wersja Google Tag Managera, w skrócie GTM server side albo sGTM.

Najbliższa analogia, która w łatwy sposób wyjaśnia działanie SST pochodzi z życia firmy. W przypadku standardowego pomiaru (client-side) każda platforma reklamowa ma w sklepie własnego obserwatora, który notuje, co chce i raportuje prosto do swojej centrali. Właściciel nie widzi ani tych notatek, ani momentu, w którym wychodzą one za drzwi.

Pomiar serwerowy zatrudnia w sklepie własnego pracownika, na zapleczu. To on staje się głównym informatorem. Obserwuje, co się dzieje, filtruje notatki i decyduje, co z tego trafi do której platformy.

W idealnym układzie zewnętrzni obserwatorzy wracają do domu, a nowa platforma to po prostu kolejny adresat raportu z zaplecza. W praktyce, żeby reklamy działały jak najskuteczniej, zwykle zostawia się im wejście do sklepu, ale bez wstępu na zaplecze. Wolno im zanotować podstawowe identyfikatory, a wszystko, co naprawdę ważne, wysyła już wyłącznie własny pracownik.

Ten pracownik ma zresztą przewagę, której obserwatorzy z zewnątrz nie odzyskają. Przeglądarki pełnią dziś rolę ochrony galerii handlowej i robią się z roku na rok bardziej restrykcyjne: obcych obserwatorów, czyli skrypty third-party, traktują podejrzliwie, wypraszają za drzwi albo zabraniają im robić notatki, kasując ich ciasteczka. Pracownik sklepu chodzi w firmowym uniformie, bo działa w obrębie domeny sklepu, więc ochrona go zna i przepuszcza. Stąd biorą się dwie najbardziej znane korzyści pomiaru serwerowego. Obie wymagają odpowiedniej konfiguracji serwera i obie stoją na tym samym mechanizmie. Dane przychodzą z własnej domeny sklepu, więc inaczej traktują je i blokery reklam, i przeglądarki.

Jak blokery reklam wycinają pomiar i co odzyskuje serwer

Blokery reklam działają na publicznych listach filtrów. Wpisane są w nie domeny, z których ładują się skrypty platform reklamowych. Tag reklamowy, czyli skrypt, którym platforma zbiera dane o wizycie, ginie właśnie dlatego, że przychodzi z obcej, dobrze znanej domeny. Pomiar prowadzony serwerowo wygląda z perspektywy blokera zupełnie inaczej. Dane trafiają na własny adres sklepu, czyli tam, gdzie klient i tak właśnie robi zakupy, więc typowy filtr nie ma go za co złapać. Większość ruchu z blokerów wraca dzięki temu do pomiaru.

Skala zjawiska w Polsce jest zmierzona. Według raportu IAB Polska o blokowaniu reklam Zjawisko blokowania reklam, IAB Polska, edycja III, marzec 2024 blokera używa 38% badanych na komputerach, 18% na smartfonach i 6% na tabletach. W tym samym raporcie stoi jednak liczba, którą branża pomija: ponad trzy czwarte czasu spędzanego w polskiej sieci przypada dziś na smartfony, gdzie blokowanie jest ponad dwukrotnie rzadsze. Problem jest więc realny, ale największy tam, gdzie ruchu jest najmniej.

I jeszcze jeden niuans, a przy okazji mit do obalenia: użytkownik z blokerem to nie to samo co ślepa analityka. Blokery różnią się listami tego, co wycinają. Najpopularniejsze rozszerzenie tnie pomiar od razu po instalacji, ale inne, równie znane, ma tę funkcję domyślnie wyłączoną. Jego program „dopuszczalnych reklam" przepuszcza według recenzowanego badania Understanding the Privacy Implications of Adblock Plus's Acceptable Ads około 80% wywołań do Google, które inaczej zostałyby zablokowane. Część osób z blokerem jest więc dla pomiaru widoczna. Z drugiej strony najbardziej agresywne listy potrafią wyciąć nawet pomiar osadzony na własnej domenie sklepu.

Ciasteczka serwerowe, czyli pełniejsza atrybucja

Druga standardowa korzyść wymaga zajrzenia pod maskę atrybucji. Analityka rozpoznaje powracającego gościa po ciasteczku, czyli małym wpisie, który przy pierwszej wizycie zostawia w przeglądarce odwiedzającego: ta przeglądarka to gość numer taki a taki, przyszedł z tej reklamy. Gdy ten sam gość wraca po dwóch tygodniach i kupuje, analityka łączy zakup z wcześniejszym wejściem i kampania dostaje zasługę. To właśnie jest atrybucja, czyli przypisanie sprzedaży do źródła, które ją przyprowadziło.

Problem w tym, że Safari, a coraz częściej także inne przeglądarki, skraca życie ciasteczek zapisywanych przez skrypty do około siedmiu dni. Klientka, która kliknęła reklamę w poniedziałek, a decyzję podjęła po dwóch tygodniach, wraca do sklepu jako zupełnie nowa osoba. Jej zakup ląduje w raportach jako wejście bezpośrednie, kampania, która ją przyprowadziła, nie dostaje żadnej zasługi, a właściciel sklepu przycina budżet dokładnie tam, gdzie powinien go zwiększać. Im dłuższy proces decyzyjny w danej branży, tym większa część sprzedaży znika w ten sposób z raportów reklamowych.

Serwer zmienia tu jedną, pozornie drobną rzecz. Ciasteczko może wystawić nie skrypt działający w przeglądarce, tylko sam serwer, na własnej domenie sklepu. Takich ciasteczek, nazywanych first-party, przeglądarki nie traktują jak śledzenia z zewnątrz i nie ucinają po tygodniu. Ich żywotność rośnie z siedmiu dni do nawet dwóch lat, choć większość nowoczesnych przeglądarek skraca je w praktyce do około 400 dni. To wciąż ponad rok zamiast tygodnia. Powracający klient znów jest tym samym klientem, konwersja wraca do kampanii, która na nią zapracowała, a właściciel przestaje ciąć budżety na podstawie raportu, w którym duża część sprzedaży udaje wejścia bezpośrednie.

Korzyści server-side taggingu, o których mało kto mówi

Gdyby korzyści z server-side taggingu kończyły się na odzyskanym ruchu z blokerów i dłużej żyjących ciasteczkach, byłaby to po prostu porządniejsza wersja tego samego pomiaru: te same zdarzenia, tylko szczelniej. Najciekawsze zaczyna się jednak tam, gdzie przeglądarki nie ma wcale.

Webhook, czyli zakup zgłoszony prosto z zaplecza sklepu

W jednym z moich wdrożeń, już po uruchomieniu pomiaru serwerowego i odzyskaniu ruchu z blokerów, w analityce wciąż było znacznie mniej zamówień niż w panelu sklepu. Powód okazał się prozaiczny. Część klientów płaci i nigdy nie wraca na stronę z podziękowaniem, czyli tam, gdzie uruchamia się pomiar zakupu: zamknięta karta, aplikacja banku, która nie przenosi z powrotem do sklepu, telefon schowany do kieszeni. Z punktu widzenia przeglądarki taki zakup nie istnieje i nie zmieni tego żadne wdrożenie, nawet najlepsze, bo nie było ani jednej chwili, w której pomiar mógłby się wykonać.

Ale system sklepu wie o tym zamówieniu wszystko. Co kupiono, za ile oraz kiedy zapłacono. I tę wiedzę da się wykorzystać, bo server-side tagging otwiera drogę, której przeglądarka nie ma. Sklep można skonfigurować tak, żeby informację o każdym opłaconym zamówieniu wysyłał prosto do serwera pomiarowego, z systemu do systemu, bez udziału kupującego, a serwer przekazywał ją dalej do analityki i platform reklamowych. W technicznym żargonie taki mechanizm nazywa się webhookiem. To odrębna część wdrożenia z własną konfiguracją, nie dodatek w pakiecie z serwerem. Postawiony raz serwer pomiarowy jest za to bazą, do której takie rozbudowy dokłada się później wedle potrzeb, bez ruszania tego, co już działa.

Jeśli przeglądarka zdążyła zmierzyć zakup, zostawia w bazie danych serwera informację, że tym zamówieniem już się zajęła. Zgłoszenie z systemu sklepu przychodzi kilka minut później, więc serwer zdąży tam zajrzeć i nie policzy tej samej transakcji dwa razy. Do raportów trafiają za to transakcje, które inaczej przepadłyby na zawsze.

Samo zgłoszenie z zaplecza sklepu nie niesie jednak żadnego śladu wcześniejszej wizyty, więc ten ślad trzeba zbudować osobno. Dopiero wtedy odzyskany zakup może zostać przypisany do odpowiedniej kampanii, zamiast wylądować wśród wejść bezpośrednich. To jeden z zabiegów, którymi serwer musi uzupełnić takie zdarzenie, i o nich jest następna sekcja. Po domknięciu tej drogi dziura w raportach w praktyce zniknęła, a całą historię opisałem krok po kroku.Case Study: jak webhook odzyskał 40% gubionych transakcji.

Data enrichment, czyli wzbogacanie zdarzeń po stronie serwera

Zakup zgłoszony przez system sklepu dociera na serwer bez kontekstu i dopiero tam zdarzenie może zostać wzbogacone o dane, których w samym zgłoszeniu nie ma. Ślad wizyty, o którym była mowa wyżej, powstaje jeszcze w koszyku. Sklep zapisuje przy nim znacznik, który przechodzi przez kasę i wraca w zgłoszeniu zamówienia, a serwer odnajduje po nim w swojej bazie dane wcześniejszej wizyty razem ze źródłem, z którego klient przyszedł. Bez tej drogi transakcja trafia do raportów jako wejście bezpośrednie.

Na tej samej zasadzie można uzupełnić parametry techniczne, po których platformy poznają, kto i skąd kupił: adres IP oraz informację o urządzeniu, zapamiętane z wcześniejszej wizyty. Bez nich każdy odzyskany zakup wyglądałby w raportach tak, jakby zrobiła go maszyna w serwerowni, a nie klient z Warszawy na telefonie. A to właśnie na geografii i podziale na urządzenia opiera się decyzja, gdzie i komu pokazywać reklamy.

W podobny sposób firma może wysłać na serwer informacje, do których pomiar w przeglądarce nie ma dostępu: marżę zamiast samego przychodu, wartość klienta z CRM, ocenę jakości leada nadaną przez handlowca albo korektę po zwrocie. Algorytmy reklamowe uczą się wtedy nie na tym, ile sklep sprzedał, tylko na tym, ile naprawdę zarobił, a to zmienia, które kampanie system uzna za skuteczne. Lista nie jest zamknięta, bo granicę wyznaczają tu możliwości systemów firmy, a nie sam pomiar.

Jedno zdarzenie, wszystkie platformy

Ostatnia korzyść nie dotyczy już tego, co pomiar widzi, tylko tego, jak bardzo obciąża przeglądarkę klienta, a przez to spowalnia sklep. W klasycznym układzie każda platforma to osobny, ciężki skrypt w przeglądarce. Każde następne narzędzie dokłada więc kilobajty do pobrania, połączenie do obcego serwera i kolejny element spowalniający ładowanie sklepu.

Pomiar serwerowy ten ciężar konsoliduje. Przeglądarka wysyła jedno główne zdarzenie do serwera, a ten rozsyła je do wszystkich platform naraz. Nawet w opisanym wcześniej wariancie hybrydowym, w którym skrypty platform zostają, ale odchudzone do zbierania samych identyfikatorów, strona zrzuca z siebie większość pracy analitycznej. Przeglądarka ma mniej do pobrania i mniej do wykonania, a najbardziej widać to na telefonach, czyli tam, gdzie odbywa się dziś większość ruchu i gdzie o porzuceniu koszyka decydują sekundy.

Czy pomiar serwerowy omija zgodę użytkownika?

Zostaje jeszcze pytanie o użytkowników, którzy nie wyrazili zgody na śledzenie. Server-side tagging bywa przedstawiany jako sposób na ominięcie tego wyboru. To mit.

Pomiar serwerowy nie omija zgód i nie zwalnia z przestrzegania prawa. Poprawnie wdrożony system egzekwuje decyzję z banera cookie tak samo jak pomiar w przeglądarce. Sklep odbiera zgodę dokładnie tak jak wcześniej, zmienia się tylko infrastruktura, która tę decyzję przetwarza. Serwer nie jest wytrychem do odzyskiwania zablokowanych informacji, tylko kolejnym systemem, który musi dostosować się do wyboru kupującego, na przykład blokując wysyłkę danych albo przesyłając wyłącznie w pełni zanonimizowane statystyki.

To, co dzieje się po odmowie, zależy jednak od platformy. Większość platform reklamowych bez zgody nie dostaje nic. GA4 może dostać sygnał pozbawiony identyfikatorów, na którym zbuduje wyłącznie modelowaną statystykę, więc odmowa nie oznacza tam pustego raportu, tylko raport gorszej jakości.

Ta warstwa wymaga przy wdrożeniu najwięcej ostrożności. Przed publikacją należy przetestować każdy scenariusz osobno: pełną akceptację, częściową zgodę i odmowę. Osobną pułapką jest przenoszenie zgody między domenami. Bez odpowiedniej konfiguracji osoba, która zaakceptowała pomiar na blogu marki i przeszła do sklepu, zostanie tam potraktowana jako całkowicie nowy, anonimowy gość i zapytana o decyzję ponownie.

Czego server-side tagging nie naprawi

Server-side tagging nie naprawi bałaganu, który zastanie. Jeśli zdarzenia liczą się podwójnie albo są źle zdefiniowane, serwer będzie powielał te błędy równie sprawnie (a nawet sprawniej) jak przeglądarka. Błędy w pomiarze po stronie przeglądarki trafiają się zresztą często: analityka wczytana dwa razy i zawyżająca ruch, tagi odpalające się przed zgodą, transakcje bez wartości, własny ruch nieodfiltrowany z raportów. Kampanie z automatycznym ustalaniem stawek uczą się wtedy na fałszywych liczbach. Pierwsze sygnały zepsutego trackingu pokaże skaner, który do tego przygotowałem. Sprawdź swój tracking. Darmowy skaner. Każde wdrożenie serwerowe poprzedza jednak dokładny, ręczny audyt pomiaru, bo dopiero on pokazuje, co trzeba naprawić i w jakiej kolejności. Uporządkowanie pomiaru jest warunkiem wstępnym, a nie dodatkiem.

Na koniec liczby, bo tu czeka kolejny mit, choć nie tam, gdzie można się go spodziewać. W moich wdrożeniach samo przeniesienie pomiaru na serwer, jeszcze bez odzyskiwania zakupów z zaplecza sklepu, podnosi liczbę rejestrowanych zdarzeń o 20 do 40%, bo do pomiaru wraca ruch wycinany wcześniej przez blokery i mechanizmy ochrony prywatności w przeglądarkach. Jedno z takich wdrożeń opisałem osobno. Case Study: server-side tagging w e-commerce Branżowe „20 do 30%" nie jest więc wyssane z palca, tylko opisuje dolną część tego, co realnie widzę w moich wdrożeniach.

Mit zaczyna się dopiero tam, gdzie ktoś obiecuje tę liczbę każdemu z góry. O tym, ile z tych zdarzeń da się odzyskać, decyduje miks urządzeń, wiek i przyzwyczajenia klientów, długość ścieżki zakupowej oraz sama platforma sklepu. Sklep z młodą, techniczną publicznością przy komputerach odzyska zupełnie inną część zdarzeń niż sklep sprzedający głównie na telefonach, więc dwa równie dobre wdrożenia potrafią skończyć się dwoma różnymi wynikami.

Ile kosztuje server-side tagging i kiedy go odradzam

Na pytanie o koszt wdrożenia nie odpowiem jedną kwotą, bo pod tym samym szyldem kryją się zupełnie różne projekty. Na wycenę wpływa między innymi to, do ilu narzędzi mają być wysyłane dane, czy sklep stoi na popularnej platformie, czy na czymś bardziej niszowym, czy pomiar ma sięgać do systemów zaplecza i czy warstwa zgód jest już wdrożona. Sporo zależy też od tego, co pokaże wstępny audyt, bo dopiero on odsłania stan pomiaru. Jedno wdrożenie zaczyna się od czystej kartki, a inne od posprzątania po kilku poprzednich. Pytania „ile to kosztuje" i „ile odzyskam" mają więc tę samą pierwszą odpowiedź i jest nią najbardziej ograne zdanie w tej branży: to zależy.

Koszt utrzymania serwera jest za to przewidywalny. To stała opłata po stronie sklepu, zwykle 80 do 200 zł netto miesięcznie, a rozpiętość bierze się z mechanizmu rozliczenia. Większość dostawców rozlicza serwer pakietami żądań, czyli abonamentem na określoną liczbę zapytań, jakie strona może w miesiącu wysłać do serwera.

Sklep z tysiącem wizyt, mierzący wyłącznie najważniejsze zdarzenia, jak zakupy czy dodania do koszyka, zmieści się bez problemu w najtańszym pakiecie. Pakiety są zwykle pojemne, więc jedno zdarzenie więcej niczego nie zmieni. Ale mierzenie wszystkiego, co da się zmierzyć, czyli każdego przewinięcia strony, kliknięcia w puste tło i ruchu myszką, zwielokrotnia liczbę żądań z tego samego ruchu i prędzej czy później przesuwa sklep na wyższy plan. Dlatego pomiar trzeba zaprojektować świadomie, zamiast mierzyć wszystko na wszelki wypadek.

Ważniejsze od pytania, ile to kosztuje, jest jednak pytanie, komu się opłaci. Cała wartość pomiaru serwerowego bierze się z tego, że odzyskane dane wracają do algorytmów reklamowych i do decyzji o budżecie. Mała strona usługowa bez kampanii nie ma więc czego odzyskiwać ani czym karmić algorytmów, a pomiar serwerowy nie doda jej nic poza rachunkiem. Im większy ruch i im większe wydatki na reklamę, tym bardziej szala przechyla się na drugą stronę, bo ten sam procent gubionych sygnałów zaczyna kosztować realne pieniądze i psuć optymalizację kampanii. Rząd wielkości oszacuje kalkulator, w którym wystarczy podać budżet reklamowy i koszt konwersji.Sprawdź, ile konwersji tracisz. Kalkulator SST.

GA4 pokazuje mniej transakcji niż sklep. Tak można to policzyć

Zestawienie panelu sklepu z raportami analitycznymi to dla wielu właścicieli e-commerce moment zderzenia z rzeczywistością. Kiedy dwa systemy pokazują dwie różne kwoty, łatwo o frustrację i o pochopną decyzję, żeby przebudować cały tracking. Zanim jednak zaczniesz szukać winnych albo wydasz budżet na nową infrastrukturę, zmierz skalę problemu i zamień przeczucia na liczbę.

Rachunek jest prosty i wymaga jedynie dostępu do panelu sklepu oraz GA4. Eksportujesz listę opłaconych zamówień i zestawiasz ją z listą transakcji z Google Analytics za ten sam okres. Każde zamówienie ze sklepu, które nie ma pary w analityce, to jeden brak, a wynik jest prostym ułamkiem: ile z faktycznie opłaconych zamówień analityka zdołała zarejestrować.

Zanim uznasz ten wynik za dowód, odfiltruj cztery pułapki, które najczęściej go zniekształcają.

Pierwsza dotyczy identyfikatora. Zamówienia paruje się wyłącznie po Transaction ID, bo numer widoczny dla klienta na fakturze bywa zupełnie inną wartością niż wewnętrzny identyfikator bazy, którym analityka posługuje się pod maską. Porównywać trzeba te same wartości, nie te same nazwy.

Druga to strefy czasowe. Panel sklepu, analityka i eksporty nie zawsze operują na tej samej strefie, a ustawienie bywa inne w każdym narzędziu. Zamówienie złożone późnym wieczorem potrafi wtedy wylądować w raporcie w innym dniu niż w panelu, więc na krawędziach badanego okresu warto to sprawdzić, zanim uzna się je za brak.

Trzecia to opóźnione raportowanie. Ostatnie 72 godziny zostawia się poza rachunkiem, bo standardowe raporty GA4 potrzebują czasu na przetworzenie danych i atrybucję, a sprawdzanie braków z wczoraj zawsze pokaże dziurę większą, niż jest naprawdę.

Czwarta to wielkość próbki. Dziesięć zamówień to szum, a nie statystyka, a pojedynczy tydzień bywa anomalią. Dla wyniku z dokładnością do dziesięciu punktów procentowych potrzeba rzędu 40 zamówień oraz drugiego przebiegu tydzień lub dwa później, który potwierdzi wynik.

Jeśli po uwzględnieniu tych pułapek dziura utrzymuje się na stabilnym, dwucyfrowym poziomie, masz w ręku twarde dane. Napisz do mnie z wynikiem, a ustalimy, gdzie dokładnie przecieka pomiar, dlaczego tak się dzieje i czy wdrożenie server-side taggingu będzie w Twoim przypadku opłacalną inwestycją.