Consent Mode — jak mierzyć, kiedy część ludzi nie zgadza się na cookies

Baner zgód traktuje się w firmach jak formalność prawną: trzeba mieć, więc się wkleja i zapomina. To jest kosztowna pomyłka, bo baner nie jest warstwą prawną nałożoną na pomiar — jest warstwą, która o tym pomiarze decyduje.

Od tego, jak jest zbudowany i co dokładnie wyłącza, zależy, ilu Waszych odwiedzających w ogóle pojawi się w raportach. A od tego z kolei zależy, czy jakakolwiek decyzja podjęta na tych raportach ma sens.

Ten tekst jest o architekturze pomiaru: co się dzieje z danymi po kliknięciu „odrzuć", czego Google w zamian nie zrobi i jak ustawić zgody tak, żeby nie tracić danych bez powodu. Jeśli szukacie raczej odpowiedzi, jak czytać liczby, które już macie, to osobny tekst — o czterech sposobach, w jakie raport potrafi kłamać.

Analityka internetowa — cztery warstwy, w których coś może się zepsuć

Zanim przejdziemy do zgód, warto rozłożyć na części to, co w firmach nazywa się jednym słowem „analityka". To są cztery osobne warstwy, każda z własnym sposobem psucia się — i większość rozmów o „złych danych" dotyczy innej warstwy, niż się rozmówcom wydaje.

Zbieranie. Strona wysyła zdarzenia: ktoś wszedł, przewinął, kliknął, wysłał formularz. Tu psuje się to, że zdarzenie nie jest wysyłane wcale albo jedzie pod nazwą, której nikt nie odbiera.

Zgoda. Między zbieraniem a resztą stoi decyzja odwiedzającego. To jest warstwa, o której ten tekst jest w całości, bo ona rozstrzyga, ile z warstwy pierwszej w ogóle pojedzie dalej.

Przetwarzanie. Zdarzenia trafiają do narzędzia, które grupuje je w sesje, użytkowników i konwersje. Tu psuje się liczenie podwójne i wliczanie własnego ruchu.

Raportowanie. Dopiero na końcu powstaje liczba, którą ktoś ogląda. I to jest jedyna warstwa, którą widać — dlatego wszystkie problemy z trzech poprzednich wyglądają jak problem z raportem.

Praktyczna konsekwencja: jeśli liczby wyglądają dziwnie, nie zaczynajcie od raportu. Zaczynajcie od warstwy pierwszej i idźcie w dół. Raport prawie nigdy nie jest miejscem, w którym coś się zepsuło — jest miejscem, w którym to widać.

Menedżer tagów — do czego właściwie służy

Drugie słowo, które pada w każdej rozmowie o pomiarze i rzadko bywa wyjaśnione. Menedżer tagów to warstwa pośrednia między Waszą stroną a narzędziami, które mają dostawać dane.

Bez niego każde narzędzie wymaga wklejenia własnego fragmentu kodu w strony — czyli dodanie czegokolwiek wymaga programisty i wdrożenia. Z nim strona wysyła zdarzenia w jedno miejsce, a to miejsce rozdziela je dalej według reguł ustawianych w panelu.

Dla firmy oznacza to trzy rzeczy, i warto znać wszystkie trzy, bo druga i trzecia bywają przemilczane:

• Zmiana w pomiarze przestaje wymagać wdrożenia. To jest realna oszczędność czasu i główny powód, dla którego się go używa.
• Powstaje miejsce, w którym da się popsuć wszystko naraz. Reguły są potężne i nie przechodzą przez żaden przegląd kodu. Dlatego dostęp do menedżera tagów jest dostępem administracyjnym, a nie „dostępem dla marketingu".
• To tam ustawia się zgody. Deklaracja, jakiej zgody wymaga każdy tag, mieszka właśnie w tej warstwie — i tam też najczęściej jej brakuje.

Jeśli nie wiecie, kto ma dostęp do Waszego menedżera tagów, to jest pierwsza rzecz do ustalenia — przed jakąkolwiek rozmową o danych.

Co się dzieje z pomiarem, kiedy ktoś klika „odrzuć"

Consent Mode to mechanizm, w którym tagi Google nie są po prostu wyłączane przy odmowie, tylko zmieniają zachowanie. Przy zgodzie działa pomiar z identyfikatorem — wiadomo, że ten sam człowiek wrócił trzy dni później. Przy odmowie wysyłany jest sygnał bezciasteczkowy: bez identyfikatora, bez rozpoznania powrotu.

Konsekwencja jest taka, że dane nie znikają całkowicie, ale przestają się łączyć. Ta sama osoba, która weszła z reklamy w poniedziałek i wysłała zapytanie w czwartek, jest teraz dwoma zdarzeniami bez związku. Raport nadal pokazuje ruch. Przestaje pokazywać ścieżkę.

Drugą, rzadziej rozumianą konsekwencją jest utrata mianownika. Współczynnik konwersji to iloraz — jeśli licznik i mianownik zbierane są przy różnych warunkach zgody, wynik przestaje być procentem czegokolwiek. Dlatego przy odmowach nie ma sensu porównywać „konwersji" między miesiącami, w których zmieniał się baner.

Modelowanie, którego mała firma nie dostanie

Tu pojawia się zdanie, które słyszy każdy, kto zapyta o dziurę w danych: „Google to domodeluje". I to jest prawda — ale pod warunkami, których niemal żadna polska strona firmowa nie spełnia.

Modelowanie behawioralne w GA4 ma twarde progi wejścia: usługa musi zbierać co najmniej 1 000 zdarzeń dziennie z odmową zgody przez minimum 7 dni oraz mieć co najmniej 1 000 użytkowników dziennie ze zgodą przez 7 z ostatnich 28 dni. I nawet spełnienie obu progów niczego nie gwarantuje — model ma dodatkowe kryteria, między innymi proporcję użytkowników nowych do powracających.

Żeby pokazać skalę, użyjemy własnych liczb, bo cudzych nie mamy jak sprawdzić:

Nasza strona firmowa zebrała 6 016 sesji przez dwanaście miesięcy — około szesnastu dziennie. Próg mówi o tysiącu dziennie. Jednostki nie są tożsame, bo Google liczy użytkowników i zdarzenia, a my sesje — ale różnica jest rzędu sześćdziesięciokrotnej i żadna korekta jednostek jej nie zamknie.

Wniosek, który warto powiedzieć wprost, bo sprzedawcy narzędzi go nie mówią: przy typowej stronie firmowej modelowania nie będzie. Dane, których nie zebraliście przez odmowę zgody, są utracone na stałe. Nie ma mechanizmu, który je później odtworzy — więc jedyne, co można zrobić, to nie tracić ich niepotrzebnie. O tym jest reszta tekstu.

Co zamiast modelowania, kiedy ruch jest mały

Skoro modelowania nie będzie, zostaje pytanie, na które sprzedawcy narzędzi zwykle nie odpowiadają: co w takim razie robić. Są trzy drogi i warto znać ograniczenia każdej.

Liczyć zagregowanie, bez identyfikatora. Licznik, który zapisuje, ile razy otwarto stronę, ale nie wiąże tego z osobą i nie rozpoznaje powrotu. Nie zastąpi analityki — nie powie nic o ścieżce ani o powracających — ale daje mianownik, czyli liczbę, do której da się odnieść wszystko inne. Przy małej stronie to często najcenniejsza pojedyncza liczba, jaką można mieć.

Zmienić dostawcę analityki na takiego, który trzyma dane w Europie. Są dwie drogi. Pierwsza to narzędzia instalowane na własnym serwerze zamiast używane jako usługa — najbardziej znane to Matomo. Druga to usługa z deklarowaną lokalizacją danych w Unii: najbliżej nam do Piwik PRO, bo to firma polska, a jej plan Business obejmuje od razu moduł zgód, czyli dokładnie tę warstwę, o której jest ten tekst.

Cennik sprawdzony u dostawcy 9 września 2026 i przeliczony po kursie NBP z tego samego dnia (tabela 175/A/NBP/2026, euro 4,3171 zł): Business od 36 €/mies — około 155 zł, w tym do 2 mln akcji miesięcznie na maksymalnie 20 domenach i 25 miesięcy przechowywania danych, z trzydziestodniowym okresem próbnym bez podawania karty. Wyżej jest Enterprise od 366 €/mies rocznie — około 1 580 zł miesięcznie. Darmowego planu nie ma. Dane w planie Business leżą w chmurze w Szwecji; Enterprise pozwala wskazać centrum danych, w tym w Niemczech i Holandii.

Warto wiedzieć, czego to nie załatwia, bo tak bywa sprzedawane. Zmiana dostawcy nie zwalnia z obowiązku zgody — dokładnie tak samo jak tagowanie serwerowe, o którym niżej. Lokalizacja serwerów w Unii rozwiązuje inny problem: transferu danych poza EOG, a nie samego pytania, czy wolno zapisać identyfikator na urządzeniu odwiedzającego. Jeśli ktoś sprzedaje Wam europejski hosting albo własny serwer jako sposób na pozbycie się banera, obowiązuje ta sama odpowiedź co przy server-side.

Liczyć poza analityką. Telefony, maile, zapytania z formularza, wiadomości z profilu w Google. To są dane, które macie niezależnie od jakiejkolwiek zgody, bo powstają z kontaktu, a nie ze śledzenia. Przy kilkunastu kontaktach miesięcznie ręczna tabelka bywa dokładniejsza niż analityka — i to nie jest żart: przy takiej skali każdy kontakt da się przypisać do źródła jednym pytaniem „skąd Państwo o nas wiedzą".

Te drogi nie wykluczają się nawzajem; przy małej firmie zwykle sensowna jest pierwsza i trzecia naraz.

Trzy zgody, nie jedna

Najczęstszy błąd we wdrożeniach, które oglądamy, jest zarazem najłatwiejszy do naprawienia: zgoda jest traktowana jako jeden przełącznik. Odwiedzający klika „odrzuć", a razem z reklamowym śledzeniem wyłącza się cała analityka.

To jest strata bez żadnego uzasadnienia, bo ludzie odrzucają te rzeczy w różnym stopniu. Sprzeciw wobec reklamowego profilowania jest znacznie powszechniejszy niż sprzeciw wobec zwykłego liczenia odwiedzin — a przy jednym przełączniku obie decyzje są zlepione w jedną.

W poprawnie zbudowanym pomiarze każdy odbiorca danych deklaruje, czego wymaga:

Zasada, którą stosujemy u siebie: odmowa zgody marketingowej nie może wyłączać analitycznej, ani odwrotnie. To jest jednocześnie kwestia zgodności z zasadami ePrivacy i — z perspektywy, która firmy zwykle bardziej interesuje — kwestia tego, czy w raporcie zostaje jakikolwiek mianownik.

Baner, który zawyża własny wynik

Jest jeszcze mechanizm, który psuje dane po cichu i wygląda przy tym na sukces: baner asymetryczny. Taki, w którym „Akceptuj wszystko" to jedno kliknięcie w wyróżnionym przycisku, a odmowa wymaga wejścia w ustawienia i odklikania trzech suwaków.

Taki baner podnosi formalny wskaźnik zgód. Wygląda to jak dobra wiadomość — i bywa tak raportowane. W rzeczywistości oznacza, że część osób zaakceptowała, bo tak było szybciej, a nie dlatego, że chciała.

Konsekwencje są dwie i obie są dla firmy niekorzystne. Pierwsza jest formalna: wytyczne europejskich organów ochrony danych idą wyraźnie w stronę symetrii — odmowa ma być równie łatwa jak zgoda, i to jest kierunek, w którym warto być z wyprzedzeniem, a nie po kontroli. Druga jest praktyczna i mniej oczywista: zgoda wymuszona układem przycisków zawyża Wam własny wskaźnik, więc tracicie także możliwość zauważenia, że coś jest nie tak. Firma, która ma „92% zgód", nie zada sobie pytania o jakość pomiaru.

Uczciwy baner z realnym wskaźnikiem na poziomie sześćdziesięciu procent jest lepszą podstawą decyzji niż wymuszony z dziewięćdziesięcioma — bo o pierwszym wiecie, ile jest wart.

Server-side nie omija obowiązku zgody

To jest najczęstszy mit sprzedawany przy tagowaniu serwerowym i wart osobnego zdania, bo bywa podawany jako główna korzyść z wdrożenia.

Tagowanie po stronie serwera realnie coś daje: pełniejszą kontrolę nad tym, co wychodzi z Waszej strony, mniejszą zależność od blokad w przeglądarce i lepszą jakość danych o konwersjach. Nie daje natomiast zwolnienia ze zgody. Obowiązek dotyczy tego, że przetwarzacie dane odwiedzającego, a nie tego, przez którą maszynę te dane przechodzą. Przeniesienie tagu z przeglądarki na serwer nie zmienia w tej sprawie nic.

Praktycznie: jeśli ktoś proponuje Wam server-side jako sposób na „ominięcie banera", to albo nie rozumie, co sprzedaje, albo rozumie i liczy, że Wy nie rozumiecie. Warto wtedy zapytać wprost, na jakiej podstawie prawnej mają być przetwarzane dane osób, które odmówiły.

Audyt pomiaru — pięć rzeczy do sprawdzenia w tym, co już macie

Jeśli analityka na Waszej stronie stoi od dawna i nikt jej od tamtej pory nie oglądał, warto zacząć od sprawdzenia, a nie od przebudowy. Pięć rzeczy, w kolejności od najczęstszej — wszystkie da się sprawdzić bez pisania kodu, choć przy części potrzebna będzie osoba z dostępem do menedżera tagów.

1. Czy zdarzenia mają odbiorcę. Zaskakująco często strona wysyła zdarzenia, których nikt nie odbiera: nazwa jest generowana, trafia do menedżera tagów i tam kończy bieg, bo nie ma tagu, który by ją przekazał dalej. W raporcie nie widać wtedy nic i wygląda to na brak zdarzenia, a nie na brak odbiornika. Sprawdzenie: porównajcie listę nazw wysyłanych przez stronę z listą tagów, które je odbierają.

2. Czy tagi deklarują wymaganą zgodę. Tag, który nie deklaruje niczego, wysyła również po odmowie. To jest ta klasa błędu, która jednocześnie jest ryzykiem formalnym i przyczyną danych, którym nie można ufać.

3. Czy konwersje nie są liczone podwójnie. Jeśli to samo zdarzenie idzie dwiema drogami — z przeglądarki i z serwera — a nie ma wspólnego identyfikatora zdarzenia, obie drogi liczą się osobno. Efekt: raport pokazuje dwa razy więcej konwersji, niż było, i każda decyzja oparta na koszcie pozyskania jest zawyżona o połowę.

4. Czy własny ruch jest wykluczony. Wejścia z Waszych komputerów, od wykonawcy i z narzędzi monitorujących zostają w danych na stałe, jeśli nikt ich nie odfiltrował na wejściu.

5. Czy ktokolwiek do tych raportów zagląda. To nie jest pytanie techniczne, ale rozstrzyga o wartości pozostałych czterech. Pomiar, którego nikt nie czyta, jest kosztem, a nie narzędziem.

Uczciwa uwaga: takie rzeczy znajdujemy również u siebie — nasz własny audyt tagowania też wypisał listę do naprawy. To jest stan normalny dla wdrożenia, które żyje kilka lat i przez które przeszło kilka osób, a nie dowód niekompetencji kogokolwiek. Ważne jest, żeby ta lista w ogóle powstała.

Co ustawić przy wdrożeniu, żeby nie poprawiać tego później

Cztery decyzje, które przy nowym wdrożeniu nic nie kosztują, a odtwarzane wstecz kosztują sporo:

• Rozdzielone zgody od pierwszego dnia. Dokładanie tego później oznacza przejście po wszystkich tagach i sprawdzenie każdego z osobna.
• Wspólny identyfikator zdarzenia, jeśli cokolwiek ma iść dwiema drogami. Bez niego deduplikacja nie zadziała, a wykryjecie to dopiero po tym, jak zaczniecie porównywać raporty z rzeczywistością.
• Filtr własnego ruchu, zanim strona pójdzie na produkcję. Danych już zebranych nie da się wyczyścić wstecz.
• Spisana lista zdarzeń — co wysyłamy, w którym momencie i po co. Jedna strona tekstu, która za dwa lata oszczędza tydzień pracy komuś, kto będzie to rozplątywał. Zwykle nie istnieje.

Nazwa techniczna tego zestawu to plan pomiaru i brzmi poważniej, niż jest: to jest tabelka z kolumnami „co", „kiedy" i „po co". Wdrożenie bez niej daje się zrobić, ale każde późniejsze pytanie o dane zaczyna się wtedy od archeologii.

Co z tego wynika dla małej firmy

Cztery rzeczy, w kolejności od najtańszej:

Rozdzielcie zgody. Analityczna osobno od reklamowej. To jest ustawienie, nie projekt, i odzyskuje mianownik u tych osób, które nie chcą reklam, ale nie mają nic przeciwko liczeniu odwiedzin.

Zróbcie odmowę równie łatwą jak zgodę. Jeden przycisk obok drugiego, na pierwszym ekranie. Traficie wtedy na niższy wskaźnik zgód i to jest dobra wiadomość, bo od tego momentu ta liczba coś znaczy.

Sprawdźcie, ile faktycznie wynosi. To jedna z tych liczb, których prawie nikt nie zna o własnej stronie, a bez niej każdy raport czyta się źle — bo nie wiadomo, o ile jest zaniżony.

Nie planujcie na modelowanie. Przy Waszej skali go nie będzie. Wszystko, co ma być zmierzone, musi być zmierzone naprawdę — albo policzone inaczej, poza analityką: telefonami, mailami, zapytaniami z formularza, które i tak macie. Przy czym warto najpierw sprawdzić, czy te zapytania w ogóle dochodzą, bo cicha awaria formularza wygląda w raporcie identycznie jak brak zainteresowania — jak to przetestować.

I rzecz ostatnia, wykraczająca poza narzędzia: część kontaktów nigdy nie pojawi się w żadnym raporcie, bo powstaje z polecenia albo z rozmowy. Pomiar ma zawężać obszar zgadywania, a nie udawać, że go nie ma. Skąd realnie przychodzą kontakty, rozłożyliśmy na własnych danych.