Consent Mode v2 i Privacy Sandbox: co zostaje po 2025 roku

Od marca 2024 roku Consent Mode v2 jest obowiązkowy dla wszystkich reklamodawców, którzy w EOG i Wielkiej Brytanii korzystają z Google Ads, remarketingu lub śledzenia konwersji. Bez prawidłowo wdrożonego Consent Mode Google przestaje wyświetlać spersonalizowane reklamy i wyłącza funkcje remarketingu. Równocześnie w 2025 roku zmieniła się sytuacja wyjściowa całej branży trackingowej: Google porzucił kluczowe elementy Privacy Sandbox, przez lata przedstawianego jako następca plików cookie stron trzecich. Dla firm B2B w Europie oznacza to jasne zadanie: mierzyć zgodnie z prawem, nie licząc na przyszłość plików cookie, która nie nadejdzie.

Ten artykuł omawia oba zjawiska od strony technicznej i wyjaśnia prawidłową konfigurację Consent Mode v2, stojące za nim modelowanie konwersji oraz konsekwencje dla pomiaru po stronie serwera, Core Web Vitals i widoczności dla crawlerów AI.

Dlaczego Consent Mode v2 i koniec Privacy Sandbox trzeba dziś rozpatrywać razem

Oba tematy wydają się odrębne, ale są ze sobą powiązane. Consent Mode v2 określa, jak reklamodawca przekazuje Google status zgody użytkownika. Privacy Sandbox miał zapewnić techniczny fundament, na którym reklama działałaby po odejściu od plików cookie stron trzecich. Wraz z końcem tych planów obecna rzeczywistość pozostaje bez zmian i właśnie ona sprawia, że Consent Mode v2 jest tak ważny.

Dane są jednoznaczne: według HTTP Archive Web Almanac 61% wszystkich plików cookie na stronach z top 1 mln to cookies stron trzecich, a w top 1000 aż 77% (pomiar międzynarodowy). Niemal 100% tych plików cookie stron trzecich ustawia atrybut SameSite=None, aby w ogóle mogły być wysyłane między witrynami. Pokazuje to, jak bardzo ekosystem reklamowy nadal zależy od tych samych plików cookie, których koniec zapowiadano od lat.

Do tego dochodzi utrata zgód przez banery zgodne z prawem. Badanie porównawcze z regionu DACH (Niemcy, Austria, Szwajcaria) pokazuje: przy zgodnej z prawem konstrukcji banera traci się średnio ok. 60% danych o odwiedzinach, bo użytkownicy odmawiają zgody (dane dla Niemiec/UE). Odpowiada to wskaźnikowi zgód na poziomie ok. 40%. Kto mierzy w EOG, pracuje więc strukturalnie na niepełnych danych, a Consent Mode v2 jest odpowiedzią Google właśnie na tę lukę.

Czym technicznie jest Consent Mode v2: tryb podstawowy, zaawansowany i cztery sygnały

Consent Mode v2 to interfejs, przez który status zgody trafia do tagów Google. Zamiast po prostu blokować tagi, Consent Mode dostosowuje ich działanie do statusu. Istnieją dwa warianty wdrożenia.

• Podstawowy Consent Mode: tagi Google ładują się dopiero wtedy, gdy użytkownik wyrazi zgodę. Przed zgodą do Google nie trafiają żadne dane, nawet pingi bez plików cookie. Jeśli użytkownik odmówi, danych brakuje całkowicie, a Google modeluje wyłącznie na podstawie zagregowanych obserwacji.
• Zaawansowany Consent Mode: tagi Google ładują się od początku, ale przy braku zgody wysyłają tylko anonimowe sygnały bez plików cookie i bez identyfikatorów osobowych. Te pingi dostarczają danych, na których opiera się modelowanie konwersji. Gdy tylko użytkownik wyrazi zgodę, tagi przechodzą w tryb pełnego pomiaru.

Tym działaniem sterują cztery sygnały. ad_storage reguluje zapisywanie plików cookie związanych z reklamą. analytics_storage steruje plikami cookie do analityki, np. w Google Analytics 4. ad_user_data określa, czy dane użytkownika mogą być wysyłane do Google w celach reklamowych. ad_personalization decyduje o reklamie spersonalizowanej i remarketingu. Dwa ostatnie sygnały doszły w wersji 2 i to z ich powodu przejście na nią stało się obowiązkowe.

Technicznie sterowanie odbywa się za pomocą dwóch poleceń. Polecenie default ustawia stan początkowy, zanim uruchomi się jakikolwiek tag. W EOG ten default musi być ustawiony na denied dla wszystkich kategorii innych niż niezbędne. Polecenie update aktualizuje status po decyzji użytkownika. Kolejność i timing mają kluczowe znaczenie: polecenie default musi zostać wywołane przed załadowaniem tagów Google, inaczej tag uruchomi się, zanim status zgody będzie znany. W praktyce sterowanie to przejmuje zwykle platforma do zarządzania zgodami, która przekazuje sygnały do tagu Google lub Google Tag Managera.

Modelowanie konwersji: jak Google szacuje brakujące konwersje

Modelowanie konwersji to właściwa korzyść z zaawansowanego Consent Mode. Gdy użytkownik odmawia zgody, brakuje bezpośredniego powiązania między kliknięciem reklamy a konwersją. Google wypełnia tę lukę modelem statystycznym, który na podstawie obserwowalnych ścieżek ze zgodą wnioskuje o ścieżkach nieobserwowalnych.

Skalę potwierdza sam Google: modelowanie konwersji w Consent Mode odtwarza średnio ponad 70% ścieżek od kliknięcia reklamy do konwersji utraconych z powodu braku zgody na pliki cookie (międzynarodowe dane Google, 2021). Ważne jest zastrzeżenie, które Google wyraźnie podaje: wyniki mocno się różnią w zależności od wskaźnika zgód i jakości wdrożenia.

Tu właśnie leży problem B2B. Modelowanie potrzebuje wolumenu. Google włącza modelowanie konwersji w Consent Mode dopiero od określonego minimalnego wolumenu kliknięć reklam i ruchu użytkowników. Wiele kont B2B nie osiąga tego progu: niszowy dostawca z kilkuset kliknięciami miesięcznie jest poniżej. Dla takich kont działa wtedy tylko ogólniejszy, mniej precyzyjny model na poziomie Google.

Realistyczne oczekiwanie dla B2B o małym wolumenie brzmi więc tak: modelowanie konwersji nie jest przełącznikiem, który gwarantuje odzyskanie utraconych konwersji. Działa dobrze tam, gdzie jest wystarczający ruch. Przy małym wolumenie lepiej skupić się na przemyślanej strategii danych first-party i pomiarze po stronie serwera, zamiast polegać na modelowaniu.

Jak prawidłowo ocenić koniec Privacy Sandbox w 2025 roku

Chronologia jest ważna, bo często przedstawia się ją w uproszczeniu. W kwietniu 2025 roku Google ogłosił, że nie wprowadzi w Chrome osobnego okna wyboru dotyczącego plików cookie stron trzecich i pozostanie przy dotychczasowym modelu. W październiku 2025 roku nastąpił decydujący krok. Według oficjalnego bloga Privacy Sandbox Google ogłosił wycofanie szeregu technologii Privacy Sandbox, w tym Attribution Reporting API, Protected Audience i Topics, oraz utrzymanie w Chrome dotychczasowego podejścia do wyboru dotyczącego plików cookie stron trzecich (ogłoszenie z 17 października 2025 roku).

Ważne dla prawidłowej oceny: Google wycofuje konkretną listę technologii, a nie wszystkie funkcje hurtem. Wycofywane są m.in. Topics, Protected Audience, Attribution Reporting API, Private Aggregation, IP Protection i Related Website Sets. Co w praktyce zostaje:

• Pliki cookie stron trzecich w Chrome: nie znikną w dającej się przewidzieć przyszłości. Obecny model zostaje utrzymany, a nowe, osobne okno wyboru dotyczące cookies nie zostało zapowiedziane.
• CHIPS (Cookies Having Independent Partitioned State): partycjonowane pliki cookie pozostają jako mechanizm i można z nich korzystać niezależnie od wycofanych API.
• Ramy prawne: decyzja Google nie zmienia RODO ani przepisów ePrivacy. Zgoda pozostaje obowiązkowa niezależnie od tego, jaka technologia przeglądarki jest dostępna.

Konsekwencja dla reklamodawców: wieloletnie przygotowania do przyszłości bez plików cookie opartej na API Sandboxa stały się bezprzedmiotowe. Zamiast tego punkt ciężkości trwale przesuwa się na zgodę, dane first-party i architekturę po stronie serwera. Ograniczenia po stronie przeglądarek, takie jak Intelligent Tracking Prevention Apple'a w przeglądarce Safari, która w Europie ma ok. 20% udziału w rynku (dane dla Europy; Chrome ok. 60%, Edge ok. 7%), nadal działają bez zmian.

RODO, TKG 2021, TDDDG i unijny omnibus cyfrowy

W Austrii dostęp do urządzeń końcowych reguluje ustawa o telekomunikacji (TKG 2021), a konkretnie zawarta w niej transpozycja dyrektywy ePrivacy. Pliki cookie, które nie są technicznie niezbędne, oraz podobne technologie wymagają uprzedniej, aktywnej zgody. W Niemczech tę samą funkcję pełni, poprzez § 25, ustawa znana wcześniej jako TTDSG, a obecnie przemianowana na TDDDG. Obie wymagają wyraźnej zgody na wszystkie pliki cookie inne niż niezbędne; samo dalsze przewijanie strony nie wystarcza.

Austriackie orzecznictwo jeszcze bardziej zaostrzyło standard w 2025 roku. W orzeczeniu z 13 sierpnia 2025 roku Federalny Sąd Administracyjny uznał zbiorczy baner Pay-or-Okay bez możliwości granularnego wyboru za niezgodny z prawem (orzeczenie dla Austrii). Sąd zakwestionował to, że użytkownicy nie mogli granularnie wyrazić zgody na poszczególne cele przetwarzania, takie jak reklama, profilowanie i analityka, ani jej odmówić. W praktyce oznacza to, że granularność nie jest opcjonalna, tylko stanowi warunek skutecznej zgody.

Na poziomie UE coś się zmienia. W propozycji omnibusa cyfrowego z 19 listopada 2025 roku Komisja Europejska planuje obowiązkowy przycisk odrzucenia jednym kliknięciem, centralne, odczytywalne maszynowo ustawianie preferencji, np. w przeglądarce, oraz rezygnację z pop-upów zgody dla celów niewiążących się z ryzykiem, takich jak samo liczenie odwiedzin (propozycja Komisji Europejskiej). Jeśli propozycja stanie się prawem, może wyraźnie zmienić krajobraz banerów. Do tego czasu obowiązują bez zmian dotychczasowe ramy z równorzędnym przyciskiem odrzucenia i granularnymi celami.

Tagowanie po stronie serwera i dane first-party jako odpowiedź na utratę sygnałów

Tagowanie po stronie serwera, najczęściej wdrażane jako sGTM (Server-Side Google Tag Manager), to techniczna odpowiedź na ograniczenia przeglądarek i utratę sygnałów. Zamiast wykonywać tagi w przeglądarce użytkownika, kontener tagów działa na własnym serwerze, który odbiera dane, przetwarza je i w kontrolowany sposób przekazuje do systemów docelowych.

Korzyści są wielowarstwowe:

• Dłuższa żywotność plików cookie: pliki cookie ustawiane przez serwer w kontekście first-party w odpowiedzi HTTP omijają krótkie terminy, które ITP przewiduje dla plików cookie ustawianych przez JavaScript. Dotyczy to jednak tylko sytuacji, w której Safari nie klasyfikuje serwera tagującego jako podmiotu zewnętrznego. Jeśli ITP rozpozna podmiot zewnętrzny po rekordzie CNAME lub adresie IP, skraca również pliki cookie ustawiane po stronie serwera do 7 dni. Zwykle dotyczy to sGTM na subdomenie, która przez CNAME wskazuje na zewnętrznego dostawcę chmury. Jeśli serwer tagujący działa w tym samym zakresie IP co strona, stabilizuje pomiar w Safari.
• Kontrola danych przed przekazaniem: na serwerze można filtrować, skracać lub pseudonimizować pola z danymi osobowymi, zanim dane trafią do podmiotów trzecich. Wspiera to minimalizację danych w rozumieniu RODO.
• Konwersje rozszerzone: zahaszowane dane first-party, takie jak adresy e-mail, są bezpiecznie przekazywane po stronie serwera i poprawiają przypisywanie konwersji, o ile istnieje ważna zgoda.

Ważne jest rozgraniczenie: tagowanie po stronie serwera nie służy do obchodzenia zgody. Zmienia architekturę przepływów danych, a nie podstawę prawną. Kto mierzy po stronie serwera bez zgody, narusza TKG i RODO tak samo jak po stronie klienta. sGTM poprawia więc jakość danych i kontrolę nad nimi, ale nigdy nie zastępuje zgody.

CMP i IAB TCF: obowiązek dla wydawców, wybór dla reklamodawców

Reklamodawcom Google nie narzuca certyfikowanej platformy do zarządzania zgodami. Consent Mode v2 można też wdrożyć przez własną implementację gtag lub Tag Managera, o ile default i update są przekazywane prawidłowo. Certyfikowana przez Google platforma CMP z IAB Transparency and Consent Framework (TCF) jest obowiązkowa tylko dla wydawców, którzy wyświetlają spersonalizowane reklamy w EOG, Wielkiej Brytanii i Szwajcarii przez AdSense, Ad Managera lub AdMob. Według Google reklamodawcy mogą korzystać również z CMP spoza programu partnerskiego dla Consent Mode. Partnerska CMP i tak się opłaca: rejestruje zgodę, przechowuje ją w sposób umożliwiający jej udowodnienie i niezawodnie przekazuje cztery sygnały do Consent Mode.

Przy wyborze i integracji liczą się trzy kwestie:

• Właściwe rozumienie certyfikacji: wydawcy korzystający z AdSense, Ad Managera lub AdMob wybierają z listy certyfikowanych dostawców Google. Reklamodawcy sprawdzają natomiast, czy CMP przekazuje wszystkie cztery sygnały Consent Mode. Lista partnerów Google jest do tego dobrym punktem wyjścia.
• Prawidłowe połączenie z Consent Mode: CMP musi ustawić sygnały default na denied, zanim załadują się tagi, a po decyzji użytkownika wysłać update. Ten łańcuch to najczęstsze źródło błędów.
• Odwzorowanie granularnych celów: TCF działa na zdefiniowanych celach i dostawcach. Interfejs banera musi przedstawiać je granularnie, aby zgoda wytrzymała ocenę w świetle austriackiego orzecznictwa.

Wpływ na crawlery AI i GEO

Poza pomiarem konfiguracja zgód i trackingu wpływa też na widoczność dla crawlerów AI, takich jak GPTBot, ClaudeBot i PerplexityBot. Mechanizm jest techniczny i łatwo go przeoczyć.

W jednym kluczowym punkcie crawlery AI zachowują się jak boty klasycznych wyszukiwarek: nie zamykają banerów cookies i nie wyrażają zgody. Kto ukrywa treści za cookie wall albo doładowuje kluczowe fragmenty tekstu przez JavaScript dopiero po zgodzie, ryzykuje, że pozostaną one niewidoczne dla systemów AI. Wynikają z tego trzy zasady GEO:

• Nie uzależniać treści od zgody: tekst redakcyjny, definicje i treści eksperckie powinny znajdować się w początkowym HTML, a nie w skryptach uruchamianych dopiero po zgodzie. Za zgodą powinny być tylko tracking i tagi marketingowe.
• Unikać cookie walli: twardy cookie wall, który blokuje całą treść, szkodzi klasycznemu indeksowaniu i widoczności w AI. Do tego jego zgodność z prawem jest sporna.
• Stawiać na renderowanie po stronie serwera: treści renderowane po stronie serwera są dostępne niezależnie od zgody i JavaScriptu po stronie klienta. W architekturach Next.js to solidniejsza podstawa dla crawlerów AI i odpowiedzi AI.

Podział jest więc jasny: pomiar za zgodą, treść przed nią. Kto miesza jedno z drugim, traci widoczność właśnie w tych kanałach, które w B2B coraz częściej decydują o tym, czy firmę da się znaleźć.

Core Web Vitals: skrypty zgód na ścieżce krytycznej

Skrypty cookies i zgód z natury działają wcześnie i blokująco, bo baner musi pojawić się przed jakąkolwiek interakcją. Właśnie to czyni je zagrożeniem dla Core Web Vitals. Ciężki skrypt CMP opóźnia renderowanie i szczególnie obciąża dwie metryki.

• LCP (Largest Contentful Paint): skrypt zgód blokujący renderowanie opóźnia wyświetlenie największego widocznego elementu. Jeśli baner zasłania główną treść, sam może stać się elementem LCP i pogorszyć wynik.
• INP (Interaction to Next Paint): rozbudowana logika CMP blokuje wątek główny i opóźnia reakcję na pierwszą interakcję użytkownika, np. kliknięcie Akceptuj lub Odrzuć.

Praktyczne środki zaradcze to utrzymanie skryptu CMP możliwie lekkim, ładowanie go asynchronicznie, tam gdzie pozwala na to logika, oraz unikanie przesunięć układu przez zarezerwowanie miejsca na baner, aby wartość CLS pozostała stabilna. Przyjazne prywatności rozwiązania analityczne bez plików cookie, z lekkim skryptem, dodatkowo zmniejszają obciążenie i dają zagregowany obraz pomiaru, który nie wymaga zgody.

Częste błędy przy wdrożeniu

Typowe błędy się powtarzają i zwykle można je usunąć niewielkim nakładem pracy.

• Default na granted w EOG: jeśli stan domyślny nie jest ustawiony na denied, tagi uruchamiają się przed zgodą z pełnym trackingiem. To najpoważniejsze i najczęstsze naruszenie.
• Brak sygnału update: polecenie default istnieje, ale brakuje update po decyzji użytkownika. Status pozostaje wtedy na stałe na denied i nawet użytkownicy, którzy wyrazili zgodę, nie są w pełni mierzeni.
• Zła kolejność: snippet Consent Mode ładuje się po tagach Google. Tag uruchamia się wtedy, zanim status będzie znany.
• Nierównorzędny przycisk odrzucenia: kolorowy przycisk Akceptuj obok szarego linku Odrzuć uznaje się za niedopuszczalny nudging, co zagraża skuteczności zgody.
• Treść za zgodą: tekst redakcyjny ładuje się dopiero po zgodzie i przez to znika dla crawlerów wyszukiwarek i AI.
• Niecertyfikowana CMP u wydawców: kto wyświetla spersonalizowane reklamy przez AdSense, Ad Managera lub AdMob i korzysta przy tym z CMP bez certyfikacji Google albo bez aktualnego TCF, nie spełnia wymogu Google dla wydawców. Dla reklamodawców korzystających z Consent Mode certyfikowana CMP nie jest obowiązkowa.

Metryki, pomiar i debugowanie

Skuteczność konfiguracji Consent Mode v2 trzeba aktywnie sprawdzać i monitorować. Raz skonfigurowany baner nie dowodzi, że wszystko działa prawidłowo.

• Sprawdzić Tag Assistant i status zgody: za pomocą Google Tag Assistant można prześledzić, które sygnały zgody są ustawione i czy default uruchamia się przed update. W idealnym przypadku tryb debugowania pokazuje zmianę statusu z denied na granted po wyrażeniu zgody.
• Monitorować modelowane konwersje: w Google Ads i GA4 modelowane konwersje warto obserwować jako osobną wielkość. Nagły spadek wskazuje na zepsutą konfigurację.
• Wskaźnik zgód jako metryka: sam wskaźnik zgód jest wielkością sterującą. Przy typowym poziomie ok. 40% pozwala osadzić dostępne dane w kontekście i ocenić projekt banera.
• Realistycznie oceniać progi: zwłaszcza konta B2B o małym wolumenie powinny sprawdzić, czy w ogóle mają wystarczający wolumen do modelowania konwersji, zamiast bezkrytycznie interpretować modelowane wartości.
• Trendy zamiast wartości bezwzględnych: ponieważ dane są systematycznie niepełne, względne zmiany w czasie mówią więcej niż liczby bezwzględne.

Dalsza lektura

Consent Mode v2 i koniec Privacy Sandbox wyznaczają ten sam punkt zwrotny: przyszłość pomiaru nie leży w technologii przeglądarki działającej bez plików cookie, lecz w zgodzie, danych first-party i architekturze po stronie serwera. Dla firm B2B w Europie wynika z tego jasna kolejność. Najpierw granularnie zaprojektowany baner z równorzędnym przyciskiem odrzucenia i CMP, która przechowuje zgody w sposób umożliwiający ich udowodnienie. Potem czysta konfiguracja Consent Mode v2 z default na denied i prawidłowym update. Na tej podstawie tagowanie po stronie serwera i konwersje rozszerzone tam, gdzie pozwalają na to wolumen i zgoda. I przez cały czas oddzielenie treści od pomiaru, aby wyszukiwarki i crawlery AI widziały treści, a tracking uruchamiał się dopiero po zgodzie. Kto konsekwentnie wdroży ten łańcuch, mierzy zgodnie z prawem i pozostaje widoczny niezależnie od tego, jaka technologia przeglądarek pojawi się lub zniknie jako następna.