Odzyskiwanie konwersji server-to-server: co zmienił GTM 22 czerwca

22 czerwca 2026 Google Tag Manager opublikował wydanie „Improved measurement of server-to-server conversions”. Zdanie pod nagłówkiem jest jeszcze bardziej dosadne: wydanie „odzyskuje konwersje, które w konfiguracjach server-to-server były niedoszacowane z powodu braku kontekstu cookie w przeglądarce”.

Google przyznaje więc, że po przeniesieniu tagów konwersji do kontenera serwerowego część konwersji nigdy nie została policzona. Nie zaniżona przez model, nie przypisana do złego kanału. Po prostu nieobecna w raporcie. Poprawka łączy dane z serwera z równoległymi sygnałami przeglądarki, między innymi z cookies, gdy w zdarzeniu obecny jest GCLID, dzięki czemu Floodlight przypisuje konwersje dokładniej. Jeśli prowadzisz server-side tagging dla klienta z budżetem w Google Ads, to wydanie wyjaśnia skok liczby konwersji w okolicy końca czerwca i pokazuje, które elementy konfiguracji nadal tracą dane.

Co dokładnie zmieniło się 22 czerwca

Zdarzenie z kontenera serwerowego dociera do Google z tym, co wie serwer: nazwą zdarzenia, znacznikiem czasu, wartością i identyfikatorami, które udało się przekazać. Brakuje w nim często kontekstu cookie przeglądarki, a Floodlight potrzebuje tego kontekstu, żeby połączyć konwersję z kliknięciem w reklamę. Od czerwca Google łączy zdarzenie z serwera z równoległymi sygnałami przeglądarki dla tej sesji, czyli między innymi z cookies zapisanymi przez tag conversion linker w kontenerze serwerowym. Dwie ścieżki danych, jeden rekord konwersji.

Z opisu wynikają trzy warunki:

• Łączenie działa tylko wtedy, gdy obecny jest GCLID. Bez identyfikatora kliknięcia nie ma odzysku.
• Opiera się na cookies, więc zgoda wpływa na jego zakres.
• Dotyczy Floodlight, czyli warstwy pomiarowej za tagami konwersji Google Ads i rodziną Search Ads 360. To nie jest zmiana w kluczowych zdarzeniach GA4.

Skąd brał się brakujący kontekst cookie

Server-side tagging przenosi pomiar ze strony na serwer. Architektura ma jednak kształt, o którym łatwo zapomnieć, gdy wszystko działa: przeglądarka do serwera, serwer z powrotem do przeglądarki, przeglądarka do dostawcy. Elementem, który utrzymuje przeglądarkę w obiegu, jest tag conversion linker. Wykrywa informacje o kliknięciu w reklamę w adresach stron docelowych i zapisuje je w cookies pierwszej strony oraz w pamięci lokalnej przeglądarki. W kontenerze serwerowym wysyła dodatkowo beacon ze strony docelowej do Google.

Zapis trafia do cookies z rodziny _gcl_*, między innymi _gcl_aw i _gcl_gs, a kopia ląduje w localStorage pod kluczem _gcl_ls. Dokumentacja tagów Floodlight w kontenerze serwerowym mówi wprost, że konto Floodlight może wysyłać dane konwersji do Tag Managera tylko przy skonfigurowanym tagu conversion linker. Gdy tego uścisku dłoni brakuje, nie ma czego łączyć i konwersja zostaje poza raportem.

Warunek, którego nikt nie sprawdza: czy GCLID przetrwał

GCLID musi przejść drogę od kliknięcia w reklamę, przez adres strony docelowej, do kontenera i z powrotem razem z konwersją. To dłuższa trasa, niż większość kontenerów obsługuje. Awarie najczęstsze:

• Łańcuchy przekierowań gubią parametr. Przejście z http na https, przekierowanie z www na wersję bez www, przekierowanie geograficzne albo skracacz linków potrafią obciąć parametry zapytania.
• Strona docelowa i strona konwersji stoją na różnych domenach. Bez łączenia domen w tagu conversion linker informacja o kliknięciu nie przejdzie.
• Kontener nie dostaje identyfikatora kliknięcia. Jeśli tag GA4 w przeglądarce nie wysyła danych do kontenera serwerowego, łączenie nie ma połowy przeglądarkowej.
• GCLID jest w adresie, ale nie w zdarzeniu. Dociera na stronę, po czym nikt nie przekazuje go do DataLayer ani do żądania do serwera. Ta usterka dobrze się ukrywa, bo konfiguracja wygląda na kompletną.

Test jest mechaniczny. Bierze się kliknięcie testowe ze znanym GCLID i sprawdza trzy rzeczy: parametr w adresie, cookie kliknięcia na domenie, identyfikator w ładunku zdarzenia przychodzącego do kontenera serwerowego. Jeśli którykolwiek punkt nie przechodzi, odzysk z czerwca nie działa dla tego ruchu.

Zgoda decyduje, ile z tego odzysku zobaczysz

Odzysk działa przez cookies, a cookies przez zgodę.

• Przy ad_storage granted cookies reklamowe mogą być odczytywane i zapisywane, a cookies konwersji pierwszej strony, takie jak _gcl_*, są dostępne. To stan, którego wymaga łączenie.
• Przy ad_storage denied nie można zapisać nowych cookies reklamowych ani odczytać istniejących, a żądania idą przez inną domenę. Adres strony jest nadal zbierany i może zawierać GCLID, ale informacja o kliknięciu posłuży tylko do przybliżonego pomiaru ruchu.
• Przy ad_user_data denied eksport danych konwersji powiązanych z identyfikatorem kliknięcia do platformy Ads jest ograniczony, co powoduje wysyłanie pingów konwersji bez cookies.
• Przy włączonym ads_data_redaction identyfikatory kliknięć w pingach zgody i konwersji są redagowane po stronie Google Ads.

W praktyce odzysk przywraca głównie ruch z aktywną zgodą. Na koncie, gdzie znaczna część użytkowników odrzuca cookies reklamowe, wzrost dotyczy tych, którzy zaakceptowali, a pozostali nie zobaczą nic. To zamierzone działanie, a nie błąd. Propozycja przedstawiająca odzysk jako sposób obejścia zgody zasługuje na odmowę. Podstawą dla cookies reklamowych pozostaje zgoda w rozumieniu Prawa komunikacji elektronicznej i RODO.

Powiązana zmiana po stronie GA4

1 maja 2026 Google Tag Manager udostępnił poprawę śledzenia i atrybucji konwersji dla usług GA4 powiązanych z Google Ads, dla klientów server-side Tag Managera. Poprawa opiera się na równoległych sygnałach przeglądarki, gdy włączone są sygnały Google. Dokumentacja sygnałów Google zawiera dziś zdanie skierowane wprost do takich konfiguracji: jeśli używasz server-side Google Tag Managera, zadbaj o włączenie sygnałów Google. Jeśli zasilasz Google Ads konwersjami z GA4 i prowadzisz kontener serwerowy, wyłączone sygnały odbierają jedno z połączeń, na których opiera się dziś Google.

Jak sprawdzić odzysk na koncie klienta

1. Potwierdź, że conversion linker istnieje w kontenerze serwerowym i odpala się na wszystkich stronach, nie tylko na stronie konwersji.
2. Potwierdź, że tag webowy wysyła dane do kontenera serwerowego, czyli że zbieranie pierwszej strony działa.
3. Prześledź GCLID od początku do końca na kliknięciu testowym: parametr w adresie, cookie kliknięcia, ładunek w kontenerze, tag konwersji.
4. Sprawdź, czy nie ma zdublowanych tagów konwersji. Ten sam tag w kontenerze webowym i serwerowym to podwójne zliczanie.
5. Zestaw konwersje z kliknięciami i wydatkami tydzień po tygodniu, z datą 22 czerwca w środku.
6. Sprawdź stan zgód w ruchu, który mierzysz, i wyklucz zmiany w metodzie zliczania oraz w oknach konwersji.

Co powiedzieć klientowi

Wzrost wynikający z poprawki pomiaru to odtworzenie stanu, a nie rozwój, i tak trzeba go przedstawić.

• Ustaw benchmarki od nowa. Wczorajszy cel CPA powstał na niedoszacowanych danych.
• Zaznacz nieciągłość na wykresie. Każde porównanie obejmujące 22 czerwca ma teraz przerwę.
• Podaj przedział, nie jedną liczbę. Odzysk zależy od stanu zgód i od tego, czy identyfikator kliknięcia przetrwał.

Czego to wydanie nie naprawi

Zakres odzysku jest węższy, niż wynika z pierwszego czytania. Nie naprawi kontenera, który nigdy nie przechwycił identyfikatora kliknięcia, i nie stworzy sygnału przeglądarki tam, gdzie zgoda go odebrała. Pingi bez cookies pozostaną bez cookies. Konwersje offline i z CRM pozostaną bez przypisania, jeśli nie wyślesz ich z identyfikatorem kliknięcia. Zdublowane zdarzenia pozostaną zdublowane.

Nic się nie zmieni u użytkowników wylogowanych, u osób z wyłączoną personalizacją reklam ani w ruchu, który nigdy nie widzi kliknięcia w reklamę.

Wydanie z czerwca oddaje konwersje, które od początku powinny być w raportach. Nie oddaje tych, które zatrzymała zgoda, a traktowanie obu grup jako jednej prowadzi do sytuacji, w której agencja mówi klientowi o wzroście skuteczności reklam, choć w reklamach nie zmieniło się nic.