Server-side tracking Google Ads - co poprawia, czego nie naprawi

Jeśli czytasz oferty wdrożeń server-side, znasz te obietnice: „odzyskasz 30% konwersji”, „ROAS wzrośnie o połowę”, „pełne dane mimo adblocków”. Część z tego jest prawdą w sprzyjających warunkach, część jest prawdą wyjętą z kontekstu, a część to zwykłe naciąganie.

Ten tekst jest dla decydenta, który chce wiedzieć, za co konkretnie płaci. Bez receptury technicznej - opisuję, co się zmienia w danych Google Ads, w jakich widełkach i od czego te widełki zależą. I równie ważne: których problemów server-side nie rozwiąże, choćby był wdrożony wzorowo.

Punkt wyjścia: ile danych dziś nie dociera

Zanim ocenisz, co poprawi server-side, musisz wiedzieć, ile tracisz teraz. W typowym polskim sklepie internetowym mierzonym wyłącznie w przeglądarce do Google Ads nie dociera zwykle 20-40% konwersji. Rząd wielkości dla swojego sklepu oszacujesz w kalkulatorze utraconych konwersji.

Składa się na to kilka warstw: adblocki (używa ich mniej więcej co trzeci internauta w Polsce), mechanizmy prywatności Safari i Firefoksa, odmowy zgody w okienku cookies oraz przekierowania na bramki płatności, które ucinają pomiar w najgorszym możliwym momencie - tuż przed potwierdzeniem zakupu. Rozbiłem te warstwy liczbowo w tekście o adblockach i iOS.

Widełki 20-40% to nie teoria. Najbardziej skrajny przypadek, jaki widziałem w audycie: sklep gubił ponad połowę zakupów, bo klienci po płatności wracali z bramki bez parametrów i strona podziękowania nie strzelała konwersją. Panel Google Ads pokazywał kampanie „na minusie”, które realnie zarabiały.

Co server-side realnie poprawia

Cztery obszary, w których zmiana jest mierzalna i powtarzalna.

Pokrycie konwersji

Konwersja wysyłana z Twojego serwera nie zależy od tego, czy przeglądarka klienta zdążyła załadować skrypt, czy adblock go przepuścił i czy redirect z bramki płatności nie uciął sesji. Zakup można zaraportować prosto z backendu sklepu, nawet gdy klient dawno zamknął kartę.

Realne widełki: odzyskanie od kilkunastu do 30% konwersji, których wcześniej nie widziałeś. Górna granica dotyczy sklepów z dużym udziałem płatności przez zewnętrzne bramki i mobilnego ruchu. Jeśli Twój pomiar już dziś jest niezły, efekt będzie bliżej dolnej granicy - i to też trzeba powiedzieć wprost.

Match rate konwersji rozszerzonych

Konwersje rozszerzone (Enhanced Conversions) polegają na tym, że Google dopasowuje zakup do kliknięcia reklamy po zahaszowanym adresie e-mail. W wariancie przeglądarkowym dane często nie wychodzą wcale albo wychodzą niekompletne. Po stronie serwera kontrolujesz, co i kiedy wysyłasz - dane są kompletne przy każdej konwersji.

Realne widełki: wzrost match rate z typowych 50-70% do 85-95%. Różnicę między wariantem przeglądarkowym a serwerowym rozpisałem w osobnym porównaniu.

Jakość sygnału dla Smart Bidding

To jest zmiana, którą widać w wynikach kampanii, nie tylko w raportach. Strategie automatyczne (tROAS, tCPA, Performance Max) uczą się na danych konwersji, które im dostarczasz. Gdy 30% zakupów znika, a część liczy się podwójnie, algorytm optymalizuje pod fałszywy obraz: tnie kampanie, które zarabiają, i dosypuje budżet tam, gdzie pomiar akurat zadziałał.

Po uporządkowaniu danych Smart Bidding przestaje błądzić. Efekt nie jest natychmiastowy - algorytm potrzebuje zwykle 2-4 tygodni na przeuczenie. Dlaczego zaszumione dane psują automaty, opisałem w tekście o Smart Biddingu.

Trwałość identyfikatorów

Safari ogranicza życie ciasteczek zapisywanych przez skrypty do 1-7 dni. Klient, który kliknął reklamę w poniedziałek, a kupił po dwóch tygodniach, jest dla pomiaru przeglądarkowego nowym, anonimowym użytkownikiem - konwersja nie łączy się z kampanią. Ciasteczko ustawiane przez serwer w Twojej domenie żyje miesiącami, więc dłuższe ścieżki zakupowe przestają znikać z atrybucji.

O ile - tabela uczciwych oczekiwań

Obszar	Typowy stan przed	Po wdrożeniu	Od czego zależy efekt
Pokrycie konwersji	60-80% zakupów widoczne	90-98%	udział bramek płatności, mobile, adblocki
Match rate konwersji rozszerzonych	50-70%	85-95%	jakość danych klienta w sklepie
Życie identyfikatora (Safari)	1-7 dni	miesiące	konfiguracja domeny serwera
Wyniki Smart Bidding	optymalizacja na zaszumionych danych	przeuczenie w 2-4 tygodnie	budżet, liczba konwersji miesięcznie

Jedno zastrzeżenie do tej tabeli: „po wdrożeniu” oznacza wdrożenie z deduplikacją i weryfikacją. Server-side zrobiony niedbale potrafi pogorszyć dane - o tym niżej.

Ukryte checkboxy: dane koszyka i dane klienta

Skoro porządkujesz pomiar, domknij też dwa ustawienia, o których większość wdrożeń zapomina - nie wymagają serwera, a podnoszą wartość danych, które Google Ads już dostaje.

Dane koszyka (cart data): konwersja może nieść nie tylko kwotę, ale i listę produktów z feeda. Google Ads pokazuje wtedy raporty zysku per produkt w kampaniach produktowych i Performance Max - widzisz, które produkty napędzają wynik, a które tylko generują koszt kliknięć.

Dane o nowym kliencie (new customer acquisition): oznaczasz w konwersji, czy kupujący jest nowy, czy powracający. Performance Max może wtedy optymalizować pod pozyskanie nowych klientów zamiast dowozić tanie konwersje od ludzi, którzy i tak by wrócili.

Oba ustawienia to detale konfiguracyjne, nie projekty. Ale bez nich nawet idealny server-side wysyła do Google ubogi sygnał.

Czego server-side nie naprawi

Ta sekcja jest ważniejsza niż poprzednie, bo na niej wykładają się wdrożenia robione „bo konkurencja ma”.

• Złych zgód nie obejdzie. Klient, który odmówił zgody marketingowej, nie stanie się mierzalny tylko dlatego, że dane płyną przez Twój serwer. Consent Mode obowiązuje w obu wariantach. Kto sprzedaje server-side jako sposób na ominięcie RODO, ten sprzedaje problem prawny.
• Bałaganu w koncie Google Ads nie posprząta. Źle ustawione kategorie konwersji, podwójne cele, połączenie telefoniczne jako Primary - to wszystko dalej psuje optymalizację, tylko na dokładniejszych danych.
• Złego feeda produktowego nie poprawi. Performance Max z ubogim feedem dalej będzie wyświetlał się słabo, niezależnie od jakości konwersji.
• Sam siebie nie zweryfikuje. Najczęstszy błąd wdrożeń: te same zakupy raportowane i z przeglądarki, i z serwera, bez deduplikacji. Panel pęcznieje od konwersji, które nie istnieją, Smart Bidding podbija stawki, a właściciel cieszy się wykresem. Błąd nie krzyczy - po cichu psuje decyzje budżetowe.

Wniosek z tego prosty: kolejność ma znaczenie. Najpierw porządek w koncie i pomiarze podstawowym, potem server-side jako wzmocnienie. W odwrotnej kolejności przenosisz bałagan na serwer.

Po czym poznać, że to moment na server-side

Trzy warunki, z których powinien być spełniony przynajmniej jeden:

1. Budżet reklamowy od około 5 000 zł miesięcznie. Poniżej tego progu koszt wdrożenia i utrzymania zjada oszczędności - matematykę zwrotu rozpisałem osobno.
2. Istotna część sprzedaży idzie przez kampanie automatyczne. Performance Max i tROAS są dokładnie tak dobre, jak dane, którymi je karmisz.
3. Widzisz rozjazd między panelem sklepu a Google Ads rzędu 20% i więcej - to sygnał, że algorytmy pracują na niepełnym obrazie.

Jeśli masz w firmie osobę, która zna GTM od strony serwerowej - większość z tego zrobicie sami. Jeśli nie masz i wolisz nie uczyć się na własnym budżecie reklamowym, to jest zakres, który wdrażam jako usługę - od audytu obecnego pomiaru, przez wdrożenie z deduplikacją, po weryfikację na żywych danych.

Podsumowanie

Server-side tracking poprawia w Google Ads cztery rzeczy: pokrycie konwersji (realnie do 90-98%), match rate konwersji rozszerzonych (do 85-95%), trwałość identyfikatorów na Safari i - w konsekwencji - jakość sygnału, na którym uczy się Smart Bidding. Nie naprawi natomiast braku zgód, bałaganu w koncie, słabego feeda ani własnych błędów wdrożeniowych.

Server-side nie jest magicznym przełącznikiem „więcej konwersji”. Jest dokładniejszym licznikiem - a wartość dokładnego licznika rośnie wprost proporcjonalnie do budżetu, który wydajesz na podstawie jego wskazań.