Server-side tracking i Consent Mode v2: dlaczego reklamy przestały widzieć połowę konwersji

Pierwsza warstwa to Safari i ITP. Ciasteczko ustawione JavaScriptem przez gtag albo piksel Meta żyje siedem dni, a przy wejściu z parametrami reklamowymi bywa skracane do doby. W sklepach, w których ścieżka od pierwszej wizyty do zakupu trwa 9-14 dni, oznacza to systematyczną utratę atrybucji dla jednej trzeciej ruchu mobilnego.

Druga warstwa to blokery treści. Na polskich sklepach z dużym udziałem ruchu desktopowego widzimy 18-30 procent sesji, w których żądania do google-analytics.com i connect.facebook.net nie wychodzą w ogóle. To nie jest szum, tylko realny ubytek w liczniku, rosnący razem z udziałem użytkowników technicznych w grupie docelowej.

Trzecia warstwa to zgody. Po wdrożeniu certyfikowanego CMP typowy wskaźnik akceptacji analityki wynosi 55-80 procent i zależy głównie od tego, czy baner ma równorzędny przycisk odrzucenia. Czwarta warstwa jest najbardziej banalna: zdarzenie zakupu odpalane w komponencie, który nie renderuje się, gdy użytkownik wraca na stronę podziękowania z pamięci podręcznej przeglądarki. Ta ostatnia potrafi zjeść 5-8 procent transakcji i prawie nikt jej nie szuka, bo wygląda jak problem z prywatnością.

Consent Mode v2 dodał dwa sygnały obok istniejących: ad_user_data i ad_personalization. Bez nich Google Ads nie może używać danych do remarketingu ani do modelowania, nawet jeśli użytkownik zaakceptował wszystko. Większość wdrożeń, które audytujemy, ma poprawnie ustawione analytics_storage, a nowe pola pomija, bo szablon w Tag Managerze konfigurowano w 2023 roku i nikt do niego nie wrócił.

Stan domyślny musi zostać ustawiony przed załadowaniem jakiegokolwiek taga Google, w trybie denied, z parametrem wait_for_update na poziomie 500 ms. Jeśli baner ładuje się asynchronicznie po kontenerze GTM, przez ułamek sekundy lecą żądania bez sygnałów zgody, a Google odrzuca je w całości. Sprawdza się to w dwie minuty: zakładka sieci w narzędziach deweloperskich, filtr collect, kolumna gcs w żądaniu. Wartość G100 oznacza brak zgody, G111 pełną zgodę, a brak parametru w ogóle oznacza, że Consent Mode nie działa.

Modelowanie konwersji, czyli powód, dla którego w ogóle robi się Consent Mode zamiast po prostu wyłączać tagi, ma próg wejścia. Google podaje minimum około 700 kliknięć reklam dziennie w danym kraju i domenie przez siedem dni. Konto z budżetem 8 tys. zł miesięcznie na jednym rynku tego progu nie osiągnie i modelowanych konwersji nie zobaczy, choć konfiguracja będzie bez zarzutu.

Kontener serwerowy postawiony na własnej subdomenie pozwala ustawiać ciasteczka nagłówkiem Set-Cookie po stronie serwera. Takie ciasteczko nie podlega siedmiodniowemu limitowi ITP i może żyć 400 dni, co odbudowuje atrybucję dla dłuższych ścieżek zakupowych. Warunek jest jeden i bywa łamany: subdomena musi wskazywać na twoją infrastrukturę rekordem A lub CNAME w twojej strefie DNS, a nie na domyślny adres z gtm-server w nazwie.

Czego serwerowy GTM nie robi: nie omija zgody. Jeśli użytkownik odrzucił cele marketingowe, kontener serwerowy nadal musi ten stan respektować, bo inaczej przetwarzasz dane bez podstawy prawnej. Nie omija też blokerów w sposób trwały, bo listy filtrów reagują również na wzorce ścieżek i nazwy parametrów. Zysk jest realny, ale opisałbym go jako odzyskanie połowy blokowanego ruchu, nie całości.

Koszty warto policzyć przed decyzją. Na Google Cloud Run z trzema instancjami minimalnymi w regionie europe-central2 sklep generujący 2 mln zdarzeń miesięcznie mieści się w przedziale 180-320 zł. Hosting zarządzany wychodzi podobnie, a oszczędza kilkanaście godzin wdrożenia kosztem kontroli nad logami. Do rachunku trzeba doliczyć utrzymanie: każda zmiana w warstwie danych sklepu wymaga teraz aktualizacji w dwóch kontenerach zamiast w jednym.

Po stronie przeglądarki zostaje jeden tag GA4 kierujący na własny endpoint oraz CMP. Wszystko inne, czyli Meta, Google Ads, Microsoft Ads i systemy afiliacyjne, przenosimy do kontenera serwerowego i zasilamy z klienta GA4. Dzięki temu zdarzenie zakupu opuszcza przeglądarkę raz, a nie pięć razy, co przy okazji zdejmuje kilkadziesiąt kilobajtów skryptów z wątku głównego.

Deduplikacja jest miejscem, w którym wdrożenia sypią się najczęściej. Meta CAPI wymaga tej samej pary event_name i event_id po stronie piksela i serwera, w oknie 48 godzin. Generujemy event_id na backendzie razem z numerem zamówienia i wstrzykujemy go do warstwy danych, zamiast losować w przeglądarce. Bez tego panel Meta pokazuje wzrost liczby zakupów o 60 procent, który jest czystym podwójnym liczeniem i po miesiącu psuje optymalizację kampanii.

Dla Google Ads dokładamy dane od użytkownika: adres e-mail i numer telefonu hashowane algorytmem SHA-256 po normalizacji, wysyłane wyłącznie wtedy, gdy ad_user_data ma wartość granted. Przy leadach dochodzi import konwersji offline z CRM po identyfikatorze gclid, zwykle harmonogramem raz na dobę. To dwie oddzielne rzeczy i nie zastępują się nawzajem, choć w rozmowach traktuje się je wymiennie.

Punktem odniesienia nie jest GA4, tylko baza zamówień. Przed wdrożeniem liczymy stosunek transakcji raportowanych przez GA4 do zamówień opłaconych w systemie sklepu, dzień po dniu, przez pełne cztery tygodnie. Typowy punkt startowy w sklepach, które do nas trafiają, to 0,72-0,85. Po poprawnym wdrożeniu Consent Mode i serwerowego GTM realistyczny cel wynosi 0,90-0,96, a nie jedność, bo część użytkowników po prostu nie wyraziła zgody i modelowanie tej luki nie wypełni w całości.

Drugi wskaźnik to jakość dopasowania po stronie platform. W Meta patrzymy na Event Match Quality dla zakupu, gdzie wynik poniżej 6,0 oznacza zbyt ubogi zestaw parametrów, a 7,5-8,5 jest osiągalne przy komplecie danych klienta. W Google Ads odpowiednikiem jest raport zasięgu ulepszonych konwersji, w którym interesuje nas odsetek konwersji z dopasowanymi danymi.

Wzrost liczby konwersji mierzymy przez porównanie okien czterotygodniowych, z korektą na sezonowość i zmianę budżetu. W projektach z ostatnich dwóch lat mediana odzysku wyniosła około 14 procent konwersji w Google Ads i 19 procent w Meta. Każdy, kto obiecuje podwojenie liczby konwersji po samym serwerowym GTM, sprzedaje podwójne liczenie.

Przeniesienie tagów na serwer nie zmienia podstawy prawnej przetwarzania. Nadal potrzebujesz zgody na cele marketingowe, nadal musisz umieć ją odtworzyć i nadal odpowiadasz za to, co wysyłasz do Meta czy Google. Zahaszowany adres e-mail pozostaje daną osobową, bo pozwala na identyfikację po stronie odbiorcy, i tak traktują go organy nadzorcze.

W praktyce oznacza to trzy rzeczy do załatwienia razem z działem prawnym: aktualizację rejestru czynności przetwarzania o kontener serwerowy, umowę powierzenia z dostawcą hostingu, jeśli nie stoi we własnej chmurze, oraz opis w polityce prywatności, który faktycznie odpowiada temu, co robi kod. Region przetwarzania warto ustawić na europejski, nie dlatego, że to formalny wymóg, ale dlatego, że upraszcza dokumentację transferu danych.