Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Kiedy rozmawiam z klientem o zgodach, pytanie „Basic czy Advanced” — czyli o wariant Consent Mode v2 — pojawia się zwykle w momencie, w którym dostawca banera pokazuje dwie opcje w konfiguratorze i trzeba wybrać jedną. Nazwy sugerują, że jedna jest uboższą wersją drugiej, a wybór polega na tym, ile się chce zapłacić za funkcje.
To nieporozumienie. Różnica nie leży w liczbie funkcji, ale w tym, kiedy tag Google ma prawo wykonać jakiekolwiek żądanie. To decyzja o charakterze prawno-technicznym, a nie cennikowa, i w praktyce jej konsekwencje odbijają się w raportach na długie miesiące.
Poniżej rozkładam oba warianty na części: co dokładnie dzieje się w przeglądarce, co z tego wynika dla danych i według jakich kryteriów podejmuję decyzję razem z klientem. Wybór jest odwracalny, ale zmiana w połowie roku psuje porównywalność okresów, więc lepiej zrobić to raz i świadomie.
Punktem wyjścia jest napięcie między dwiema rzeczami: obowiązkiem uzyskania zgody przed jakimkolwiek przetwarzaniem oraz potrzebą reklamodawcy, żeby wiedzieć chociaż tyle, ile wolno.
Interpretacje przepisów w Europie różnią się w jednym istotnym szczególe: czy samo wysłanie do serwera żądania bez identyfikatorów, bez zapisu ciasteczka i bez danych pozwalających rozpoznać osobę wymaga już zgody. Część prawników mówi, że tak, bo adres IP i nagłówki i tak trafiają na serwer. Część mówi, że nie, bo nie dochodzi do przetwarzania danych osobowych w rozumieniu, które wymagałoby podstawy w postaci zgody.
Google nie rozstrzyga tego sporu za nas — oddaje do wyboru dwa modele odpowiadające obu interpretacjom. Wariant ostrożniejszy nie wysyła nic. Wariant szerszy wysyła żądanie pozbawione identyfikatorów i dopiero na jego podstawie potrafi cokolwiek policzyć.
Dlatego uważam, że tej decyzji nie powinien podejmować specjalista od reklamy w pojedynkę. To rozmowa z osobą odpowiedzialną za ochronę danych w firmie, w której ja dostarczam informację o konsekwencjach, a nie o tym, co jest legalne.
W wariancie Basic tagi Google są całkowicie wstrzymane do momentu, w którym użytkownik wyrazi zgodę. Fizycznie nie ładują się na stronie — nie ma żądania sieciowego, nie ma pinga, nie ma nawet informacji o samym fakcie odwiedzin.
Konsekwencja jest prosta i bezlitosna: użytkownik, który zamknął baner albo odmówił, dla Google nie istnieje. W statystykach nie ma go w żadnej formie, nie zasili żadnej listy, nie zostanie policzony w żadnym modelu. Widzisz wyłącznie tę część ruchu, która powiedziała „tak”.
Wdrożeniowo ten wariant bywa prostszy, bo najczęściej realizuje go sam baner: skrypt platformy zgód blokuje ładowanie tagów do czasu decyzji, a kontener startuje dopiero po niej. Nie zwalnia to jednak z obowiązku przekazywania sygnałów zgody — bez nich, nawet przy zgodzie, konto zachowa się jak konto bez wdrożenia.
Warto mieć świadomość skali. Odsetek odmów zależy od branży, konstrukcji banera i tego, czy przycisk odmowy jest równie widoczny jak przycisk akceptacji. Nie podam liczby, bo różni się między klientami bardziej niż większość osób się spodziewa. Powiem inaczej: zaplanuj wdrożenie tak, jakby część ruchu z Europy miała zniknąć z danych, i ustal z klientem przed startem, jak będziecie o tej luce mówić w raportach. Odkrywanie jej dopiero przy pierwszym porównaniu miesiąc do miesiąca kończy się rozmową o „spadku”, którego nie było.
W wariancie Advanced tagi ładują się od razu, przed pokazaniem banera, ale startują ze stanem ustawionym na odmowę. To znaczy, że działają w trybie ograniczonym: wysyłają żądanie, ale bez ciasteczek, bez identyfikatorów reklamowych i bez danych, które pozwalałyby powiązać wizytę z konkretną osobą.
Takie żądanie nosi w dokumentacji nazwę pinga bez ciasteczek. Zawiera niewiele: informację o zdarzeniu, przybliżony kontekst techniczny i sam stan zgody. Nie ma w nim historii użytkownika ani niczego, co pozwalałoby rozpoznać go przy następnej wizycie.
Jeśli użytkownik zgodę wyrazi, tagi przechodzą w tryb normalny bez przeładowania strony i od tego momentu działają jak zawsze. Jeśli odmówi, zostają w trybie ograniczonym do końca sesji.
Ten wariant jest trudniejszy we wdrożeniu dokładnie z powodu, który opisałem w tekście o konfiguracji kontenera: stany domyślne muszą zostać ustawione przed pierwszym tagiem, więc kolejność uruchamiania przestaje być szczegółem, a staje się warunkiem poprawności.
Cała przewaga szerszego wariantu sprowadza się do jednej rzeczy — Google ma z czego modelować.
Modelowanie polega na tym, że system, widząc pingi od użytkowników bez zgody oraz pełne dane od użytkowników ze zgodą, szacuje statystycznie, ile konwersji przypada na tę pierwszą grupę i przypisuje je do kampanii. W raportach dostajesz wtedy liczbę bliższą rzeczywistości niż surowa liczba zdarzeń zmierzonych bezpośrednio.
Trzy zastrzeżenia, o których mówię klientom od razu. Po pierwsze, model to szacunek — nie da się go rozłożyć na pojedyncze zamówienia i nie porówna się go jeden do jednego z panelem sklepu. Po drugie, wymaga ruchu: Google publikuje w dokumentacji progi wolumenu, poniżej których modelowanie po prostu nie działa i mniejsze konta go nie zobaczą. Po trzecie, uruchamia się z opóźnieniem, więc nie oceniaj wdrożenia po pierwszym tygodniu.
Jest jeszcze skutek, o którym się rzadziej mówi, a który dla mnie jest ważniejszy niż same liczby w raporcie: dane z pingów zasilają optymalizację. Strategie licytujące pod konwersje uczą się na sygnałach, więc konto z pełnym obrazem podejmuje lepsze decyzje w aukcjach niż konto widzące tylko część ruchu.
Z perspektywy pracy w kontenerze rozdziela je jedno pytanie: kto blokuje tagi.
To rozróżnienie ma jeszcze jedną praktyczną konsekwencję. Jeśli ktoś wdrożył wariant szerszy w konfiguratorze banera, ale jednocześnie zostawił w kontenerze stare wyjątki wstrzymujące tagi, dostaje najgorsze połączenie: koszt konfiguracji jednego wariantu i efekty drugiego. Widzę to na kontach regularnie i zawsze jest to pozostałość po wdrożeniu z lat, w których po prostu blokowaliśmy wszystko do czasu zgody.
Nie mam jednej odpowiedzi dla wszystkich, ale mam listę pytań, które zadaję.
Jak dużą część ruchu stanowi Europejski Obszar Gospodarczy i Wielka Brytania? Jeśli marginalną, decyzja jest mało istotna. Jeśli to podstawa biznesu, waga rośnie proporcjonalnie.
Jakie stanowisko ma dział prawny lub inspektor ochrony danych? Tu nie negocjuję. Jeżeli firma stoi na stanowisku, że żadne żądanie nie może wyjść przed zgodą, wybieram wariant ostrożniejszy i nie próbuję przekonywać argumentami z panelu reklamowego.
Czy konto ma wystarczający wolumen, żeby modelowanie w ogóle się uruchomiło? Przy niewielkim sklepie różnica w danych może być na tyle mała, że nie warto brać na siebie dodatkowego ryzyka interpretacyjnego.
Czy ktoś będzie to utrzymywał? Szerszy wariant ma więcej ruchomych części i po każdej przebudowie strony trzeba go sprawdzić ponownie.
W praktyce, jeśli dział prawny nie ma zastrzeżeń, a konto realnie żyje z reklamy w Europie, rekomenduję wariant szerszy. Przy oporze prawnym albo braku kogokolwiek, kto będzie pilnował wdrożenia, wybieram ostrożniejszy i uczciwie mówię, jakiej części obrazu nie zobaczymy.
Na koniec rzecz, którą powtarzam na każdym spotkaniu: wybór wariantu nie jest zgodą na zbieranie danych i nie zastępuje poprawnie zaprojektowanego banera.
Jeśli baner jest zbudowany tak, że użytkownik nie ma równie łatwej drogi do odmowy jak do akceptacji, żaden wariant tego nie uzdrowi — a zebrane w ten sposób zgody są wątpliwe niezależnie od tego, jak elegancko działa mechanizm techniczny.
Żaden wariant nie przywróci też danych historycznych. Listy odbiorców zbudowane wcześniej nie znikną, ale od marca 2024 przestaną rosnąć o użytkowników z Europy, dla których nie przekazano nowych sygnałów. To argument za tym, żeby skończyć wdrożenie przed terminem, a nie w tygodniu, w którym wchodzi w życie.
I ostatnia rzecz: ani jeden, ani drugi wariant nie zwalnia z podstaw pomiaru. Zdublowane konwersje, źle skonfigurowany tag i przypadkowe zdarzenia oznaczone jako konwersje główne psują dane bardziej niż brak zgód. Warto zrobić przegląd tych rzeczy przy okazji, bo i tak wchodzisz w konfigurację tagów.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |