Serwerowy tag Google Ads i zero konwersji - gdzie ginie gclid

Wdrożenie server-side na sklepie z aktywnymi kampaniami, tor testowy zbudowany równolegle, nowa akcja konwersji Google Ads. Wszystko na karcie akcji świeci na zielono: Enhanced Conversions aktywne, warunki przetwarzania danych klienta zaakceptowane, status “Recording”. Do tego “Last activity: Today”, czyli Google coś od nas dostaje. Konwersji: zero. Dzień po dniu.

To nie jest historia o literówce w identyfikatorze konwersji ani o zapomnianym triggerze. Zdarzenia docierały do kontenera serwerowego kompletne, z poprawnym gclid w środku, a tag Google Ads odpalał się przy każdym zakupie. Problem siedział w założeniu, które wygląda na oczywiste i jest błędne: że serwerowy tag Google Ads przeczyta click-id z pola zdarzenia, skoro mu je tam położyliśmy.

Nie czyta. I ta jedna właściwość tagu tłumaczy sporą część przypadków “server-side działa, a konwersji nie ma”. Poniżej pełna diagnoza krok po kroku, mechanizm i naprawa, która po drodze odzyskała wstecznie 31 konwersji.

Objaw: wszystko zielone, licznik stoi na zerze

Najbardziej mylące w tej awarii jest to, że żaden panel nie pokazuje błędu. Akcja konwersji skonfigurowana zgodnie ze specyfikacją: zliczanie każdej konwersji, okno 30 dni, atrybucja oparta na danych, Enhanced Conversions przez GTM, source server-side. Konwersje z toru testowego miały wpadać jako akcja secondary, dokładnie po to, żeby wdrożenie na działającym sklepie niczego nie zepsuło w rozliczeniach kampanii.

Zdarzenia szły. Webhook płatności dostarczał każde opłacone zamówienie, warstwa pośrednicząca forwardowała je do kontenera serwerowego, tag Google Ads Conversion Tracking odpalał się na każdym purchase. W logach po drodze same statusy 200.

A w panelu: “No recent conversions”. Przez trzy dni.

Co naprawdę mówi “Last activity” na karcie akcji

Pole “Last activity” na karcie akcji konwersji rozróżnia dwie zupełnie różne awarie i to jest pierwsza rzecz, którą warto odczytać, zanim zacznie się rozbieranie czegokolwiek na części. Są dwa scenariusze:

• “Last activity” puste lub stare - pingi w ogóle nie docierają do Google albo nie trafiają w parę identyfikator + label. Szukasz problemu w triggerze, identyfikatorach, sieci.
• “Last activity: Today” przy zerze konwersji - pingi docierają i matchują akcję, ale Google nie ma ich do czego przypisać. Problem nie leży w dostarczeniu, tylko w atrybucji: brakuje click-id.

U nas: scenariusz drugi. To od razu zawęża pole poszukiwań: nie ma sensu grzebać w triggerach ani identyfikatorach akcji, skoro Google potwierdza, że słyszy nasze pingi. Pytanie brzmiało: czego w tych pingach nie ma.

Wykluczanie podejrzanych: dane były kompletne

Zanim padło na sam tag, sprawdziłem wszystko dookoła, bo doświadczenie uczy, że tag jest winny rzadziej niż dane, które dostaje. Po kolei:

• Payloady zdarzeń: każde opłacone zamówienie niosło gclid. Wszystkie unikalne, w poprawnym formacie (prefiksy Cjw/Cj0/EAIaIQ, długość 55-92 znaków), więc to nie były obcięte ani zdublowane wartości.
• Consent: zgody reklamowe w zdarzeniach ustawione, żadnego filtrowania po stronie trybu zgód.
• Karta akcji: konfiguracja zgodna ze specyfikacją, warunki danych klienta zaakceptowane, EC “Recording”.

Pipeline czysty, panel czysty, dane kompletne. Zostało jedno miejsce, w które nikt nie zagląda, bo wygląda na czarną skrzynkę: co dokładnie tag wysyła do Google.

Smoking gun: w pingu do Google nie było click-id

Rozstrzygnięcie przyszło z podglądu pełnego wychodzącego requestu, nie z żadnego panelu. Kontener serwerowy ma tryb podglądu: zdarzenie wysłane z nagłówkiem X-Gtm-Server-Preview pojawia się w Tag Assistant razem z kompletnym Request URL, który tag skleił i wysłał do Google. Wysłałem więc syntetyczne zdarzenie testowe z podstawionym gclid i przeczytałem, co poszło w ping na endpoint /pagead.

W wychodzącym URL nie było parametru gclaw=, czyli miejsca, w którym click-id jedzie do Google. Gclid siedział wyłącznie w blobie data=, który jest ładunkiem diagnostycznym, nie atrybucyjnym. A odpowiedź Google mówiła wprost: cookie_present=false.

Czyli: tag odpalał się poprawnie, wysyłał poprawnie zaadresowany ping, Google go przyjmował i odpowiadał “nie widzę click-id”. Wszystkie trzy zielone statusy w panelach były prawdziwe. Po prostu żaden z nich nie mierzył tego, co się zepsuło.

Serwerowy tag Google Ads nie czyta gclid z pola zdarzenia

Kluczowa właściwość, wbrew intuicji z budowania specyfikacji zdarzeń: serwerowy tag Google Ads Conversion Tracking bierze click-id wyłącznie z dwóch miejsc - z cookies requestu przychodzącego (ścieżka Conversion Linker, czyli _gcl_aw i pokrewne) albo z query stringa w page_location. Pole zdarzenia z gclid, choćby nazwane najstaranniej, jest dla niego niewidzialne.

W klasycznym przepływie browser-to-server to nieodczuwalne: przeglądarka wysyła zdarzenia do kontenera serwerowego razem ze swoimi cookies, więc _gcl_aw zapisane przez Conversion Linker przy kliknięciu w reklamę jedzie w każdym requeście automatycznie. Tag ma skąd czytać i nikt się nie dowiaduje, jak ta lektura przebiega.

Przepływ webhookowy tę ciągłość zrywa. Webhook płatności to request server-to-server: nie niesie żadnych cookies użytkownika, bo nie wychodzi z przeglądarki. Gclid trzeba przechwycić po stronie sklepu, przechować i dołączyć do zdarzenia, i to zrobiliśmy, tyle że jako pole payloadu. Dane były w zdarzeniu. Tag ich tam nie szukał.

To samo dotyczy identyfikatorów braid: _gcl_ag (gbraid) i _gcl_gb (wbraid) mapują się na parametr gclgb= w pingu. Jeśli tor konwersji obsługuje ruch z iOS, warto wiedzieć, że te wartości podlegają tej samej zasadzie - cookie albo query string, nigdy pole zdarzenia.

Dwie drogi podania click-id i dlaczego wygrywa cookie

Skoro tag czyta z dwóch miejsc, są dokładnie dwie drogi naprawy i obie dają się sprawdzić empirycznie. Test A/B na syntetycznych zdarzeniach: raz gclid jako cookie _gcl_aw w nagłówku requestu, raz jako parametr doklejony do query stringa page_location. Obie próby zapaliły gclaw= w wychodzącym pingu. Technicznie remis.

Rozstrzygnęło sąsiedztwo. W tym samym kontenerze serwerowym z tych samych zdarzeń korzysta tag Meta CAPI, a page_location zasila jego event_source_url. Doklejanie click-id Google do URL-a zdarzenia zanieczyszczałoby dane jadące do zupełnie innej platformy. Cookie jest izolowane: czyta je ścieżka Conversion Linker, nikogo innego nie obchodzi.

Naprawa sprowadziła się do jednej zmiany w warstwie forwardującej: jeśli zdarzenie niesie gclid, request do kontenera serwerowego dostaje nagłówek Cookie z wartością _gcl_aw=GCL.<timestamp>.<gclid>, czyli dokładnie w formacie, w którym zapisałby ją Conversion Linker w przeglądarce. Tag znajduje cookie, gclaw= pojawia się w pingu, Google ma click-id do atrybucji.

Backfill: konwersje dają się odzyskać wstecznie

Najlepsza wiadomość z całej tej historii: nic nie przepadło. Zamówienia z okresu awarii miały gclid zapisany po naszej stronie, więc po wdrożeniu poprawki wystarczyło ponownie wysłać 31 zaległych zdarzeń przez naprawioną ścieżkę. Google Ads księguje konwersje po dacie kliknięcia, nie po dacie dotarcia pingu - odzyskane konwersje wskoczyły do raportów tam, gdzie zawsze powinny były być.

Pierwsze pozycje pojawiły się w panelu mniej więcej godzinę po wysyłce, akcja przeszła z “No recent conversions” na “Active”, a w kolejnych godzinach dosypała się reszta. Standardowo konwersje z gclid przetwarzają się w mniej niż 12 godzin, z identyfikatorami braid do 72 godzin, więc werdykt o skuteczności backfillu wydaje się następnego dnia, nie po kwadransie.

Dwie rzeczy sprawiły, że cała awaria kosztowała zero szkód w kampaniach. Po pierwsze, akcja przez cały okres diagnozy była secondary, więc Smart Bidding nie podejmował na jej podstawie żadnych decyzji. Po drugie, gclid był przechwytywany i przechowywany od pierwszego dnia, niezależnie od tego, czy dalsza ścieżka umiała go użyć. Zbieraj identyfikatory nawet wtedy, gdy jeszcze nie wiesz, czy wszystko po drodze działa - odtworzyć się da tylko to, co zostało zapisane.

Jak zdiagnozować to samo u siebie w godzinę

Jeżeli masz serwerowy tor konwersji Google Ads i podejrzanie niskie liczby, ta sekwencja rozstrzyga sprawę szybciej niż jakiekolwiek zgadywanie:

1. Karta akcji konwersji, pole “Last activity”. Świeża data przy zerze konwersji oznacza problem atrybucji, nie dostarczania. Stara lub pusta - problem dostarczania, wróć do narzędzi debugowania GTM.
2. Tryb podglądu kontenera serwerowego + zdarzenie testowe z nagłówkiem X-Gtm-Server-Preview. Interesuje cię pełny wychodzący Request URL tagu Google Ads, nie status “Fired”.
3. Szukaj gclaw= w pingu /pagead. Jest - click-id dojeżdża, problemu szukaj gdzie indziej. Nie ma, a gclid widzisz tylko w blobie data= - masz dokładnie ten przypadek.
4. Sprawdź odpowiedź Google. cookie_present=false potwierdza, że po stronie Google nie ma czego atrybuować.
5. Podaj click-id tam, skąd tag czyta: cookie _gcl_aw w requeście do kontenera (albo query string page_location, jeśli nie koliduje z innymi tagami).

Warstwa Enhanced Conversions nie zastąpi tego mechanizmu: EC dla web wzmacnia dopasowanie konwersji, które mają click-id, a nie tworzy konwersji z samego adresu e-mail. Różnice między wariantami EC rozbieram w porównaniu browser-side i server-side Enhanced Conversions, a cały serwerowy tor od podstaw w przewodniku po server-side GTM dla Shopera. Przepływy webhookowe, w których click-id trzeba przenosić ręcznie, to akurat ta warstwa, którą biorę na siebie w ramach wdrożenia, bo prawie każda platforma ma tu swój wariant tej samej pułapki.

Podsumowanie

Serwerowy tag Google Ads czyta click-id wyłącznie z cookies requestu albo z query stringa page_location - nigdy z pól zdarzenia. W przepływach browser-to-server załatwia to za ciebie Conversion Linker, więc problem pozostaje niewidoczny. W przepływach server-to-server (webhooki płatności, forwardowanie zamówień) cookies użytkownika nie istnieją i click-id trzeba tagowi podać w formacie, którego szuka: _gcl_aw=GCL.<timestamp>.<gclid>.

Diagnostycznie cała sprawa rozstrzyga się w jednym miejscu: pełny wychodzący Request URL tagu w trybie podglądu kontenera serwerowego. Panele mogą świecić na zielono, bo mierzą dostarczenie i konfigurację, a nie kompletność atrybucji. I warto pamiętać o dobrej stronie tej awarii: jeśli identyfikatory kliknięć były zapisywane, konwersje odzyskuje się wstecznie, bo Google księguje je po dacie kliknięcia.

Zielony status w panelu mówi, że pingi dochodzą. Nie mówi, że niosą to, czego Google potrzebuje do atrybucji - to sprawdzisz tylko czytając wychodzący request.