Wdrożenie Server-Side Tagging
Pomiar client-side był projektowany pod warunki, których już nie ma.
Wdrażam Server-Side Tagging, który odzyskuje tracone zdarzenia i zasila nimi algorytmy Google i Meta.
Ten sam sklep,trzy stany pomiaru
Na każdym etapie liczba oznacza to samo. Ile opłaconych zamówień z panelu sklepu trafia do GA4 jako zdarzenie purchase w tym samym okresie. Każdy etap domyka inną lukę.
stan zastany
30%Siedem zakupów na dziesięć nie docierało do GA4, bo pomiar żył wyłącznie w przeglądarce.
po przeniesieniu na serwer
63%Blokery i ITP przestały wycinać zdarzenia. Nadal ginęły jednak te zakupy, przy których klient nie wracał ze strony płatności.
po dołożeniu webhooka
~100%WooCommerce zgłasza opłacone zamówienie bezpośrednio na serwer pomiarowy, niezależnie od tego, czy klient wrócił ze strony płatności.
Luka w pomiarzeto droższa reklama
O tym, kto zobaczy Twoją reklamę, decyduje dziś algorytm Google i Mety, a podstawą tej decyzji są dane konwersji. Luka w pomiarze przestała być kwestią raportu. Zdarzenie, które nie dotarło albo nie zostało dopasowane, nie bierze udziału w wyborze, komu pokazać następną reklamę. Gdy do algorytmu nie docierają konwersje całej grupy użytkowników, na przykład osób korzystających z Safari, uznaje on, że ta grupa nie konwertuje i ogranicza wyświetlanie jej reklam. W panelu zobaczysz to jako wyższy koszt pozyskania, nie jako błąd pomiaru.
Nie wiesz, czy SST ma sens w Twojej skali? Wyjaśniam to krok po kroku w artykule o Server-Side Tagging.
Blokery
Powstały do blokowania reklam, ale ich listy filtrów uwzględniają również skrypty pomiarowe. Konwersja użytkownika z blokerem nie trafia ani do GA4, ani do panelu reklamowego. Na komputerach używa ich 38% polskich internautów.
Wygasające ciasteczka
Safari skraca życie ciasteczka zapisanego w przeglądarce do siedmiu dni. Klient, który wraca po dwóch tygodniach, liczy się jako nowy użytkownik z wejścia bezpośredniego, a kampania, która go przyprowadziła, nie dostaje zasługi.
Limity przeglądarek
Pomiar w przeglądarce działa tylko wtedy, gdy przeglądarka jest w grze. Zakup, przy którym klient nie wraca na stronę potwierdzenia, nie zostawia po sobie żadnego zdarzenia.
Nie wiesz, ile ta luka kosztuje u Ciebie? Kalkulator policzy to na Twoich liczbach.
Oblicz potencjał SST// CASE STUDY
Sklep e-commerce,EMQ 9.3/10.
WooCommerce. Ten sam tag GA4 wgrany w trzech miejscach naraz: w GTM, we wtyczce i w kodzie od dewelopera. Jeden zakup trafiał do raportów kilka razy. Budżet reklamowy opierał się na liczbach, które nie miały pokrycia w sprzedaży.
WYZWANIE
Zupa z tagów
- Ukryty gtag w szablonie modułu „wielosztuk", do wykrycia dopiero przy czytaniu kodu
- Meta Pixel z wtyczki black box: nie widział zdarzeń na stronie, na którą trafiał płatny ruch
- TikTok Pixel ładowany poza GTM nie respektował zgód
- Ciasteczka zapisywane w przeglądarce wygasały w Safari po siedmiu dniach
- Ten sam zakup liczony kilka razy: algorytmy reklam uczyły się na zawyżonych konwersjach
ROZWIĄZANIE
Jedno źródło prawdy + SST
- Wyczyszczenie stosu do jednego źródła: GTM
- Autorski skrypt Data Layer dla modułu „wielosztuk"
- Server-Side Tagging w architekturze same-origin
- GA4, Meta CAPI, Google Ads i TikTok przez serwer, wszystkie pod jedną bramką zgody
- Dane kontaktowe znormalizowane pod wymagania każdego systemu reklamowego
- Ciasteczka ustawiane z serwera, bez limitu siedmiu dni
WYNIK
EMQ 9.3/10 i czyste dane
- 41,2% odzyskanych transakcji
- Jeden zakup, jedno zdarzenie w GA4
- Event Match Quality 9.3/10 dla zdarzenia Purchase w Meta
- Komplet parametrów użytkownika przy każdym zakupie
- Wszystkie tagi uruchamiają się respektując zgody
- Ciasteczka first-party z serwera, bez siedmiodniowego limitu Safari
Trzy poziomy SST,trzy rodzaje odzyskanych danych
Pierwszy poziom odzyskuje dane, które dziś giną. Drugi uzupełnia te, które docierają niekompletne. Trzeci sięga po zdarzenia, których przeglądarka nie zgłosi nigdy.
Odzyskiwanie danych
Pomiar przeniesiony na Twoją domenę przestaje wyglądać dla blokerów jak obcy skrypt, a ciasteczka zapisane z serwera nie wygasają po siedmiu dniach. Wracają zdarzenia, które dotąd ginęły, i atrybucja, którą przeglądarka zrzucała na ruch bezpośredni.
Uzupełnianie danych
Serwer wie o transakcji więcej niż przeglądarka. Dokłada do zdarzenia parametry, które podnoszą szansę dopasowania go do konta użytkownika, oraz dane, których na stronie w ogóle nie ma, jak koszt własny produktu. Do Google i Meta trafia wtedy razem z zakupem informacja, ile na nim zarobiłeś.
Przyjmowanie danych spoza przeglądarki
Webhook ze sklepu zgłasza opłacone zamówienie w tej samej sekundzie, w której zmienia się jego status. Tą samą drogą trafiają zdarzenia z innych systemów po Twojej stronie, bez udziału przeglądarki.
„Gdy Mateusz rozpoczynał pracę, śledzenie w Google Analytics oraz dane dotyczące transakcji były w moim sklepie właściwie całkowicie niepoprawne. […] Zajął się nie tylko samym raportowaniem, ale też kwestiami, które mają kluczowe znaczenie dla jakości danych — w tym m.in. wdrożeniem i uporządkowaniem Server Side Tagging.”
Jak przebiega wdrożenieServer-Side Tagging
Od audytu obecnej konfiguracji do dokumentacji, którą przejmie kolejny specjalista.
Nie wiesz, czy Twoja strona ma już Server-Side Tagging?
Skaner trackingu sprawdzi to w minutęKrok 01: Audyt obecnej implementacji
Przechodzę całą warstwę pomiarową: GTM, GA4, piksele reklamowe i kod wgrany poza nimi.
Krok 02: Plan wdrożenia
Projektuję architekturę pomiaru i ustalam kolejność prac.
Krok 03: Konfiguracja serwera
Uruchamiam kontener GTM Server pod Twoją domeną, na infrastrukturze dobranej do skali ruchu i ustaleń z planu wdrożenia.
Krok 04: Migracja tagów
GA4, Meta, Google Ads i pozostałe systemy przechodzą na stronę serwerową. Stary układ pracuje przez ten czas równolegle.
Krok 05: Uzupełnianie danych
Implementacja dodatkowych zdarzeń wysyłanych z Twoich systemów, o ile przewiduje je plan wdrożenia.
Krok 06: Testy i przekazanie
Weryfikacja kompletności danych w GA4 i w panelach reklamowych. Na koniec dokumentacja napisana tak, żeby kolejny specjalista przejął system bez zgadywania.
Platforma zmienia jedynie sposób integracji warstwy danych, architektura serwerowa jest od niej niezależna.
Wdrożenie bez przerwyw zbieraniu danych
Konfigurację porządkuję i przenoszę na serwer, a dotychczasowy pomiar zbiera dane aż do chwili przełączenia.
Równoległy bieg
Stary i nowy układ tagów działają jednocześnie. Obecny tracking zbiera dane bez przerwy przez cały czas wdrożenia.
Bramka zgodności
Nowy pomiar przejmuje zbieranie danych dopiero wtedy, gdy oba strumienie raportują te same zdarzenia i wartości.
Powrót w kilka minut
Jeśli coś odbiega od oczekiwań, wracamy do poprzedniej konfiguracji bez utraty zebranych danych.
Mój standard oceniony przez Stape
Każde wdrożenie sprawdzam audytem Stape. Ocenia on między innymi poprawność implementacji, odporność pomiaru na blokery i żywotność plików cookies.
wdziecznopis.pl
96/100Top 10%- Analytics
- 100/100
- Ads Tracking
- 100/100
- Cookie Lifetime
- 100/100
Gotowy na pełną infrastrukturę danych?
Zaczniemy od audytu Twojej obecnej implementacji i pokażę, ile danych możesz odzyskać i co możesz wzbogacić.
Najczęściej zadawane pytania
Typowe wdrożenie e-commerce to około 2 tygodnie od kompletu dostępów. Na ten czas składa się audyt obecnej implementacji, konfiguracja serwera, migracja tagów i równoległe testy. Zakres rozbudowany o wzbogacanie danych z CRM czy konwersje offline trwa dłużej. Działa to też w drugą stronę: gdy fundament pomiaru już stoi, pojedynczy element, np. webhook odzyskujący transakcje, implementuję w około tydzień.
Koszt zależy od zakresu: stanu obecnej analityki, liczby platform reklamowych i tego, czy dochodzą elementy niestandardowe, jak wzbogacanie danych z CRM. Konkretną wycenę podaję po krótkim audycie. Do tego dochodzi stały koszt serwera Stape, który opłacasz bezpośrednio: od 80 do 200 zł netto miesięcznie przy typowym ruchu sklepu.
Serwer w tej architekturze istnieje, ale nie jest Twoim zmartwieniem. Działa na Stape i to Stape go utrzymuje: nie stawiasz własnej maszyny, niczego nie aktualizujesz i nie angażujesz IT. Po Twojej stronie zostaje tylko stały abonament Stape. Konto zakładam na Ciebie, z Twoją kartą, więc dostępy, konfiguracja i dane należą do Ciebie, nie do mnie. Po wdrożeniu dostajesz krótkie oprowadzenie po panelu, żeby dało się z niego korzystać bez mojej pomocy.
Tak. Wdrażałem SST na WooCommerce, Shopify, Comarch e-Sklep, 2ClickShop i innych. Platforma zmienia jedynie sposób integracji warstwy danych, architektura serwerowa jest od niej niezależna.
To zależy od profilu Twojego ruchu: udziału adblocków, iOS i limitów przeglądarek. W sklepach, w których wdrażałem pomiar serwerowy, sama warstwa przeglądarki, jeszcze bez webhooka, odzyskiwała od kilkunastu do ponad 40% transakcji; rekordowe wdrożenie e-commerce to 41.2% odzyskanych zdarzeń purchase i Event Match Quality w Meta na poziomie 9.3/10.
Niezależną, dodatkową warstwą jest webhook prosto z platformy sklepu: rejestruje zakupy, przy których klient w ogóle nie wrócił na stronę podziękowania. Tych zakupów żadna poprawka w przeglądarce nie odzyska. Przed wdrożeniem mierzę Twoją dziurę w danych i dopiero z tym pomiarem rozmawiamy o zakresie.
Tak, i to jest jedna z głównych przewag pomiaru serwerowego. Klient, który po płatności nie wrócił na stronę podziękowania, nigdy nie wywołał zdarzenia purchase w przeglądarce. Serwer pomiarowy przyjmuje jednak dane nie tylko z przeglądarki: może odebrać i przetworzyć np. webhook z platformy sklepu z informacją o opłaconym zamówieniu, niezależnie od tego, co klient zrobił po płatności. To rozszerzenie wykraczające poza standardowe wdrożenie, a w sklepach z dużym udziałem przelewów potrafi domknąć największą pojedynczą dziurę w pomiarze.
Bo od niej zależy, czy pomiar rozpoznaje powracających klientów. Ciasteczko zapisane przez JavaScript żyje w Safari najwyżej 7 dni, więc klient, który wraca po dwóch tygodniach, liczy się jako nowy użytkownik z wejścia bezpośredniego, a reklama, która go przyprowadziła, nie dostaje zasługi. Zapis przez własny serwer, czyli element wdrożenia Server-Side Tagging, trzyma pełny okres życia ciasteczka: atrybucja, listy remarketingowe i raporty o powracających klientach zaczynają pokazywać prawdę.
To zależy od tego, co pokaże audyt. Kontener webowy GTM zostaje, ale jego zawartość bywa do uporządkowania: zdublowane tagi, warstwy kodu po poprzednich specjalistach czy brakująca obsługa zgód to rzeczy, które naprawiam w ramach wdrożenia, bo Server-Side Tagging postawiony na słabych fundamentach mierzyłby źle. Niezależnie od skali zmian stary pomiar działa równolegle, dopóki nie potwierdzę, że nowy liczy poprawnie, więc nie ma momentu, w którym zostajesz bez danych.
Server-Side Tagging nie omija zgód. Serwer egzekwuje decyzję użytkownika: przy braku zgody nie wysyła danych do platform reklamowych albo wysyła je w formie anonimowej zgodnie z Consent Mode v2. To element każdego wdrożenia, nie opcja.
Dokumentację powdrożeniową z opisem architektury i konfiguracji oraz okres opieki, w którym monitoruję dane i poprawiam wszystko, co wyjdzie na realnym ruchu. Dokumentację piszę tak, żeby kolejny specjalista mógł przejąć system bez zgadywania, co i dlaczego zostało ustawione.