Server-side i Enhanced Conversions w 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ę. Skrajny przypadek to płatność za pobraniem, gdzie online nie ma żadnego potwierdzenia zakupu - jak zmierzyć COD server-side przez webhook zamówienia, rozpisałem osobno.

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%. Kiedy wystarczy wariant przeglądarkowy, a kiedy potrzebny jest serwer albo API, rozpisuję niżej.

Match rate sprawdzisz w diagnostyce konkretnej akcji konwersji w Google Ads. Zrób zrzut z datą przed zmianami, to Twoja baza. Po wdrożeniu odczekaj 30-45 dni, bo wskaźnik przelicza się na większej próbie, i patrz na wzrost względny, nie tylko na wartość: skok z 40 do 60% znaczy więcej niż z 70 do 75%.

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.

To dlatego niski match rate tak często nie jest problemem braku danych. Sklep wysyła hash e-maila poprawnie, tylko identyfikator, do którego Google miałby go dopasować, wygasł przed zakupem. Typowy przebieg: klik w reklamę, wizyta bez zakupu, powrót po dziesięciu dniach z Safari. Ciasteczko _ga zapisane skryptem już nie istnieje, więc dopasowanie zależy wyłącznie od tego, czy klient był zalogowany w Google w obu momentach.

Jedno zastrzeżenie, które pomija większość ofert: od 2023 roku Safari skraca także ciasteczka z odpowiedzi serwera, jeśli serwer tagowania stoi pod adresem IP z zupełnie innej sieci niż sklep. Sama subdomena sgtm.twojsklep.pl na zewnętrznym hostingu nie wystarcza, liczy się to, jak serwer jest wpięty w domenę sklepu. Stąd w tabeli niżej kolumna “od czego zależy efekt”.

Część trwałości odzyskasz jeszcze przed wdrożeniem serwera:

• ustaw cookie_domain w Google Tagu na własną domenę,
• hashuj dane klienta po stronie sklepu (trim, małe litery, SHA-256), nie w tagu,
• dodawaj transaction_id do każdego zakupu,
• wyłącz wtyczki marketingowe, które dublują własne ciasteczka i zdarzenia.

Po stronie Meta ten sam problem nazywa się EMQ. Jak podnieść go trwałym external_id z maila, rozpisałem dla każdego zdarzenia osobno.

O ile - tabela uczciwych oczekiwań

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.

Enhanced Conversions: przeglądarka, serwer czy hybryda

Enhanced Conversions nie zastępują zwykłego tagu konwersji, tylko go uzupełniają. Tag dalej wysyła zdarzenie, wartość, walutę i transaction_id, a do tego dochodzą zahaszowane dane klienta (e-mail, telefon, adres), po których Google łączy zakup z kliknięciem reklamy. Pytanie nie brzmi więc „włączyć czy nie”, tylko którędy te dane mają płynąć.

Przeglądarka jako szybki start

Wariant przeglądarkowy włączasz w Google Ads i konfigurujesz w Google Tagu albo GTM: automatycznym wykrywaniem danych, ręcznym wskazaniem pól (selektory CSS, zmienne JavaScript) albo konfiguracją kodową, która daje największą kontrolę nad formatem i haszowaniem. To najszybsza droga, bez serwera i bez programisty backendu.

Słabość jest jedna, ale poważna: wariant przeglądarkowy dziedziczy wszystkie problemy przeglądarki. Jeśli tag się nie załaduje, adblock go zatrzyma albo e-mail klienta nie jest stabilnie dostępny na stronie podziękowania (ukryty, tylko w obiekcie JavaScript, zmieniony selektor po aktualizacji szablonu, checkout na zewnętrznej domenie), dane po prostu nie wyjdą.

Serwer albo API dla zakupu

Po zakupie sklep ma w backendzie lepsze dane niż przeglądarka na stronie podziękowania: e-mail, telefon, adres, transaction_id, status płatności. W wariancie serwerowym tag Google Ads w kontenerze serwerowym dostaje je przez user_data, a przez Google Ads API dane klienta można dosłać nawet do 24 godzin po konwersji. Zmiana szablonu czy selektora niczego tu nie psuje, a dane formatujesz raz, przed wysyłką.

Najrozsądniejsza kolejność to hybryda: najpierw poprawne zwykłe konwersje (ID, etykieta, wartość, waluta, transaction_id), potem Enhanced Conversions w przeglądarce jako szybki zysk, na końcu zakup przez serwer albo API. Zdarzenia pomocnicze, jak dodanie do koszyka, mogą zostać w przeglądarce. Google zapowiedział na 2026 rok przyjmowanie danych klienta naraz z tagu, Data Managera i API oraz połączenie ustawień Enhanced Conversions dla witryn i dla leadów w jedno, więc wybór „tylko przeglądarka albo tylko serwer” i tak traci ostrość. Jak tag i backend przez Data Manager dzielą się pracą na jednej akcji, pokazałem w tekście o liczeniu w Google Ads tylko opłaconych zamówień.

Trzy błędy, które widzę najczęściej:

• Import konwersji z GA4 zamiast natywnej akcji Google Ads. Enhanced Conversions nie działają na celach importowanych z GA4, potrzebna jest akcja konwersji ustawiona przez Google Tag albo GTM.
• Brak transaction_id. Bez niego nie ma deduplikacji przeglądarka-serwer ani pewnego połączenia z zamówieniem. Skąd biorą się zdublowane zakupy na Shoperze, opisałem w trzech sposobach na duplikację purchase.
• Serwer jako obejście braku zgody. Sygnał ad_user_data z Consent Mode v2 obowiązuje także po stronie serwera. Serwer ma poprawiać jakość danych, a nie omijać decyzję klienta.

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.

Enhanced Conversions zacznij w przeglądarce, ale zakup docelowo wysyłaj z serwera albo przez API. Tam dane klienta są kompletne i nie zależą od tego, co akurat wyrenderowała strona podziękowania.

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ń.