Blog
Baner cookie przed tagowaniem po stronie serwera: co się zmienia, a co nie
Opublikowano · 4 min czytania
Pytanie przychodzi w dwóch postaciach. „Czy nadal potrzebuję banera, skoro tagi są teraz własne (first-party)?” — tak. „Czy mój baner nadal działa, skoro tagi są teraz własne?” — zazwyczaj, ale sposób, w jaki może zawieść, jest cichy, i warto poświęcić dwadzieścia minut, by się upewnić. To nie jest porada prawna; to opis mechaniki, żeby to, co doradzi Ci prawnik, konfiguracja faktycznie robiła.
Co tagowanie po stronie serwera zmienia w kwestii zgody: nic
Własna nazwa hosta to techniczna właściwość żądania. Nie jest zgodą. Jeśli wczoraj potrzebowałeś zgody, żeby ustawić ciasteczko analityczne, potrzebujesz jej dziś, a to, że ciasteczko ustawia teraz metrics.twojastrona.pl zamiast google-analytics.com, nie ma tu znaczenia. Pytanie organu nadzoru brzmi: co zbierasz i po co, a nie: który serwer pakiet odwiedził po drodze.
Zmienia się to, dokąd trafia zablokowane żądanie. Blokery reklam i funkcje prywatności przeglądarek blokują po nazwie hosta i wzorcu URL, i blokują googletagmanager.com. Nie blokują Twojej własnej domeny. Odwiedzający, który wyraził zgodę, a którego lista filtrów po cichu by odrzuciła, jest teraz liczony. To cała korzyść — i jest korzyścią tylko w przypadku odwiedzających, którzy wyrazili zgodę.
Consent Mode w jednym akapicie
Tagi Google odczytują stan zgody złożony z kilku nazwanych uprawnień — analytics_storage, ad_storage, ad_user_data, ad_personalization — i dostosowują to, co wysyłają. Zanim odwiedzający zdecyduje, menedżer zgód wypycha domyślne denied; gdy wybierze, wypycha aktualizację. W stanie denied tag Google nadal się uruchamia, ale wysyła ping bez ciasteczek: bez identyfikatora klienta, bez ciasteczka, sygnał, że strona została wyświetlona, i nic więcej. Gdy analytics_storage przejdzie na granted, wysyła pełne trafienie. Kontener serwerowy otrzymuje to, co zostało wysłane, a sygnały zgody podróżują razem z trafieniem, więc tag GA4 po stronie serwera zachowuje się tak samo.
Kolejność ma znaczenie, a tagi SignalHost nie dodają własnych warunków
Menedżer zgód musi załadować się przed tagiem Google, żeby jego wartość domyślna była na miejscu, gdy tag ocenia sytuację po raz pierwszy. Większość menedżerów udostępnia właśnie w tym celu wartość wait_for_update — kilkaset milisekund, przez które tag czeka na stan zgody, zanim przyjmie denied.
Encje, które SignalHost tworzy w Twoim kontenerze, nie mają warunków zgody. To celowe. Tagi Google same respektują Consent Mode; ręcznie dodane sprawdzenie zgody na tagu Google, bez żadnego na tagach zdarzeń GA4 pod nim, to pierwszy z dwóch błędów poniżej.
Błąd pierwszy: warunkowanie tagu Google, ale nie tagów zdarzeń
Tag Google to to, co kieruje pomiar przez kontener serwerowy. Tag zdarzenia GA4 — na przykład tag zakupu — może wysyłać samodzielnie. Jeśli tag Google czeka na zgodę, a tagi zdarzeń nie, tagi zdarzeń uruchamiają się przed zgodą i wysyłają prosto do Google — ze strony, której baner wciąż jest otwarty. Strona kontenera nie pokazuje niczego niepokojącego, bo trafienia nigdy nie przeszły przez kontener.
Albo nie warunkujesz niczego ręcznie i pozwalasz działać Consent Mode, albo warunkujesz każdy tag, który może wysyłać. Spójnego środka nie ma.
Błąd drugi: blokujący menedżer zgód, który nie rozpoznaje Twojego własnego loadera
Niektóre menedżery zgód działają, blokując skrypty do czasu wyrażenia zgody — przechwytują tagi script po adresie URL i je wstrzymują. Ich listy znają googletagmanager.com. Nie znają exxz2gdaz1jz.twojastrona.pl, bo żadna lista nie mogłaby: nazwa hosta i nazwa pliku loadera są unikalne dla Twojego kontenera. W trybie blokowania loader może więc zostać przepuszczony bezwarunkowo, a jeśli polegasz na blokowaniu zamiast na Consent Mode, to tag uruchamiający się przed zgodą.
Dwa wyjścia. Dodaj ręcznie adres URL loadera do reguł blokowania menedżera, w kategorii, do której należy Twoja analityka. Albo — lepiej, bo poprawnie obsługuje też ping bez ciasteczek — polegaj na Consent Mode w przypadku tagów Google, a blokowania używaj tylko do skryptów, które go nie obsługują. Nasza własna strona działa z menedżerem zgód w trybie automatycznego blokowania z Consent Mode obok; tag Google jest umieszczony po skrypcie menedżera, a test w repozytorium nie przechodzi, jeśli ktoś zamieni kolejność.
Strona serwera i pozostałe miejsca docelowe
Stan zgody dociera do kontenera serwerowego wewnątrz każdego trafienia, a tag GA4 po stronie serwera odczytuje go tak, jak zrobiłby to tag w przeglądarce. Nic po naszej stronie nie udziela ani nie rozszerza zgody; ping bez ciasteczek pozostaje pingiem bez ciasteczek.
Jeśli podłączysz miejsce docelowe Meta lub TikTok, zasilają je te same trafienia. To, czy odmowa zgody marketingowej odwiedzającego ma zatrzymać te przekazania, jest decyzją, którą wyraża Twój menedżer zgód — przez kategorię, w której znajduje się loader, i przez to, czy Twoja konfiguracja respektuje ad_storage z Consent Mode. Sprawdź to tak, jak sprawdzałbyś tu wszystko: otwórz stronę z nieodpowiedzianym banerem, obserwuj kartę sieci i zobacz, co wychodzi.
Lista kontrolna
- Skrypt menedżera zgód znajduje się na stronie powyżej tagu Google.
- Domyślny stan zgody denied jest wypychany przed załadowaniem tagu, z wait_for_update.
- Żaden tag w kontenerze nie ma ręcznie dodanego warunku zgody — albo ma go każdy tag, który może wysyłać.
- Przy nieodpowiedzianym banerze karta sieci pokazuje ping bez ciasteczek (gcs=G100 w żądaniu) i żadnego pełnego trafienia.
- Po akceptacji ta sama strona pokazuje pełne trafienie, a strona kontenera je zlicza.
- Jeśli menedżer blokuje po adresie URL, adres URL loadera znajduje się w jego regułach.
