Jak sprawdzić baner plików cookie: czy naprawdę blokuje opcjonalne skrypty? 7 typowych błędów

Przycisk „Odrzuć” nie dowodzi jeszcze, że śledzenie ustało. Praktyczny przewodnik po sprawdzaniu banera w panelach Sieć i Aplikacja, trybie uzyskiwania zgody oraz powtarzalnych testach.

Otwierają Państwo stronę w nowym profilu przeglądarki, klikają „Odrzuć” i widzą, że komunikat o plikach cookie znika; wszystko wygląda poprawnie, lecz właśnie wtedy pytamy, jak sprawdzić baner plików cookie: czy jeszcze przed kliknięciem wyszło żądanie do platformy reklamowej, czy odpowiedź próbowała ustawić identyfikator, który pozostał w pamięci przeglądarki, oraz czy po odmowie tagi otrzymały właściwy stan zgody? Baner jest tylko panelem sterowania, a test sprawdza, czy pod spodem podłączono przewody, ponieważ CMP mogła jeszcze nie ustawić wartości domyślnych, gdy Menedżer tagów Google wykonał pierwszą regułę.

Oględziny banera ani zielony znacznik skanera nie pokazują, co wydarzyło się w pierwszych sekundach wczytywania, który skrypt wywołał dane działanie, jaki stan zgody był wtedy dostępny ani czy stan końcowy odpowiada wcześniejszej sekwencji zdarzeń. Dlatego na jednej osi czasu porównujemy zachowanie strony przed wyborem, po odrzuceniu wszystkich opcjonalnych kategorii, po ich zaakceptowaniu oraz po późniejszym wycofaniu zgody, sprawdzając żądania sieciowe, nagłówki odpowiedzi, pliki cookie, localStorage i inne rodzaje pamięci, kolejność sygnałów zgody oraz inicjatora konkretnego działania. Dopiero takie porównanie odróżnia poprawną konfigurację od banera, który po prostu się zamyka.

To artykuł techniczny, a nie indywidualna opinia prawna: pokazuje, jak zebrać sprawdzalne fakty i nie formułować wniosków, których dowody nie uzasadniają. Jeżeli strona korzysta z Google Tag Managera, Google Analytics 4, Google Ads, Meta Pixela, osadzonych filmów, okna czatu lub innych narzędzi zewnętrznych, lista plików cookie widoczna na jednym ekranie będzie tylko częścią obrazu, dlatego właściwe pytanie nie brzmi „czy baner został zainstalowany?”, lecz „co strona robi w każdym momencie, w którym użytkownik podejmuje lub zmienia decyzję?”.

Jak sprawdzić baner plików cookie — i czego taki test nie dowodzi

Test obejmuje techniczny łańcuch zgody od pierwszego żądania strony do zmiany stanu po decyzji użytkownika, lecz nie można go oceniać wyłącznie po stanie końcowym, ponieważ początkowa kolejność wczytywania mogła już uruchomić działanie, którego późniejsze zamknięcie banera nie cofnie. Zakres obejmuje kolejność wczytywania skryptów, połączenia sieciowe, pliki cookie i inne rodzaje pamięci, sygnały platformy do zarządzania zgodą użytkowników (CMP), konfigurację trybu uzyskiwania zgody Google, działanie kategorii oraz możliwość późniejszej zmiany wyboru; rezultatem jest zestaw dowodów dotyczących warstwy plików cookie i śledzenia, a nie potwierdzenie zgodności z prawem wszystkich procesów przetwarzania danych osobowych w organizacji.

Trzeba rozdzielić dwa powiązane poziomy: art. 5 ust. 3 dyrektywy o prywatności i łączności elektronicznej dotyczy przechowywania informacji w urządzeniu końcowym użytkownika oraz uzyskiwania dostępu do informacji już w nim zapisanej, a ten techniczny zakres nie ogranicza się do plików noszących nazwę „cookie”; w Polsce ten obszar reguluje art. 399 ustawy – Prawo komunikacji elektronicznej. RODO ma znaczenie, gdy przetwarzane są dane osobowe, i określa również warunki skutecznej zgody oraz zasady jej wycofania, dlatego techniczna kontrola wymogów jednego reżimu nie zastępuje oceny prawnej drugiego. W raporcie z audytu nazywamy oba poziomy osobno, aby zaobserwowany fakt techniczny nie został przedstawiony jako szerszy wniosek prawny.

UODO omawia ustalenia EROD dotyczące banerów plików cookie: przyciski „Odrzuć”, wstępnie zaznaczone pola, wygląd banera i wycofanie zgody. Opcjonalne mechanizmy wykorzystujące pliki cookie i podobne technologie nie mogą przed wyrażeniem zgody przechowywać informacji w urządzeniu użytkownika ani uzyskiwać dostępu do informacji już w nim zapisanych, a odmowa musi być rzeczywistym wyborem. Nazwa kategorii „niezbędne” niczego nie dowodzi. Wyjątek dotyczący mechanizmów ściśle niezbędnych należy interpretować wąsko: działanie musi być konieczne do transmisji komunikatu albo świadczenia usługi wyraźnie żądanej przez użytkownika, a nie tylko wygodne dla analityki, marketingu czy właściciela strony. Audytor musi powiązać to działanie z funkcją, która go wymaga, i jednocześnie sprawdzić, czy w tej samej kategorii nie ukryto zupełnie innego celu, którego funkcja żądana przez użytkownika nie uzasadnia.

Fraza „audyt RODO strony internetowej” oznacza w tej usłudze wyłącznie zakres plików cookie, śledzenia i zarządzania zgodami, ponieważ poza nim pozostają podstawy prawne innych procesów, żądania osób, których dane dotyczą, umowy oraz zarządzanie wewnętrzne. Nasz audyt plików cookie i mechanizmów śledzących dostarcza faktów technicznych, na podstawie których prawnik lub inspektor ochrony danych może rzetelnie ocenić właśnie tę część strony, ale zgodność z RODO nie jest pojedynczym przełącznikiem, który skaner techniczny może włączyć dla całej organizacji. Takie ograniczenie zakresu nie jest uchylaniem się od odpowiedzialności; jasno wskazuje, co raport potwierdza i które kwestie wymagają jeszcze decyzji poza audytem technicznym.

Jak audyt zbiera dowody, a nie tylko wynik skanera

Dobry test zaczyna się w czystym profilu przeglądarki, bez zapisanej zgody, plików cookie strony ani żądań rozszerzeń; jeszcze przed jakimkolwiek kliknięciem włączamy rejestrowanie w panelu Sieć, sprawdzamy panel Aplikacja i utrwalamy stan początkowy. Następnie powtarzamy tę samą sekwencję działań po odmowie, po udzieleniu zgody i po jej wycofaniu, rozpoczynając każdy scenariusz z udokumentowanego stanu i zachowując cały dziennik, ponieważ w przeciwnym razie wczorajszy wybór może wyglądać jak dzisiejszy błąd banera albo, odwrotnie, ukryć rzeczywistą usterkę.

Wpis w panelu Sieć dowodzi, że przeglądarka próbowała połączyć się z konkretnym adresem, i pozwala sprawdzić inicjatora, stan, nagłówki żądania i odpowiedzi oraz przesyłane informacje, ale nie potwierdza jeszcze, że plik cookie został zapisany. Nagłówek odpowiedzi Set-Cookie pokazuje próbę ustawienia go przez serwer, lecz przeglądarka może tę próbę zablokować, natomiast JavaScript może zapisać wartość przez document.cookie albo w localStorage bez takiego nagłówka; dlatego faktyczny rezultat trzeba zweryfikować w panelu Aplikacja i żadna z tych oznak nie może zastępować pozostałych. Widoczne żądanie do domeny analitycznej jest dowodem próby przepływu danych, a nie automatycznym dowodem skutecznego ustawienia analitycznego pliku cookie ani odebrania przez serwer konkretnego zbioru danych osobowych.

Dla każdego ustalenia zapisujemy URL i ścieżkę użytkownika, czas, urządzenie, przeglądarkę, stan zgody, inicjatora i adres docelowy żądania, wynik transmisji oraz zmiany w pamięci, aby po poprawce powtórzyć ten sam test. Automatyczny skan daje szeroki inwentarz początkowy, ale nie przechodzi przez wszystkie menu, etapy zakupu, strefy logowania, wersje językowe i dynamicznie otwierane integracje ani nie potrafi wiarygodnie ustalić celu na podstawie samej nazwy pliku lub domeny, dlatego po nim wykonujemy scenariusze ręczne i rozmawiamy z właścicielami narzędzi. Ustalamy, kto wdrożył narzędzie, w jakim celu, w którym kontenerze tagów ono działa i jaki stan zgody powinien sterować jego działaniem, aby powiązać ustalenie techniczne z zamierzoną konfiguracją. Dowód bez kontekstu jest tylko zrzutem ekranu; kontekst bez dowodu jest tylko obietnicą.

1. Opcjonalne skrypty uruchamiają się przed wyborem użytkownika

Krytyczny błąd kolejności występuje wtedy, gdy baner CMP szybko pojawia się na ekranie, ale tag analityczny lub reklamowy został już uruchomiony: użytkownik nadal czyta tekst przycisków, podczas gdy przeglądarka połączyła się z podmiotem zewnętrznym albo zapisała identyfikator. Zasada uprzedniej zgody jest jednoznaczna — opcjonalnych plików cookie nie wolno aktywować przed dokonaniem wyboru — dlatego kontrola techniczna zaczyna się od pierwszego wczytania strony, a nie od chwili, w której audytor znalazł i nacisnął przycisk „Odrzuć”.

W środowisku Google Tag Managera częstą przyczyną jest niewłaściwa kolejność zdarzeń, ponieważ domyślny stan zgody trzeba ustawić przed tagami, korzystając z reguły „Inicjacja zgody – wszystkie strony” albo innego rozwiązania gwarantującego tę samą kolejność, a dopiero po działaniu użytkownika wysłać aktualizację. Jeżeli wartość domyślna dociera za późno, tag może przez krótką chwilę widzieć stan nieokreślony lub wcześniej zapisany i się uruchomić, a szybko znikający baner nie usunie tego warunku wyścigu, ponieważ problem dotyczy kolejności wykonywania kodu, nie animacji.

W audycie stwierdzenie „pliki cookie wczytują się przed wyrażeniem zgody” rozdzielamy na zdarzenia: wczytanie skryptu, żądanie sieciowe, sygnał bez plików cookie, próbę ustawienia pliku cookie przez nagłówek Set-Cookie albo faktyczny zapis identyfikatora; każde z tych zdarzeń ma inną wartość dowodową. W zaawansowanym trybie uzyskiwania zgody tagi Google przy domyślnym stanie odmowy mogą się wczytać i wysyłać pomiary bez plików cookie, dlatego sama obecność skryptu nie wystarcza ani do stwierdzenia naruszenia, ani do potwierdzenia zgodności.

Naprawę zaczynamy od mapy narzędzi i jasnego modelu stanów: które tagi mogą działać bez wyboru, które wymagają konkretnej kategorii i jakie zdarzenie zmienia wartość domyślną. Po zmianie konfiguracji powtarzamy test w czystym profilu z zachowanym dziennikiem panelu Sieć, zwracając szczególną uwagę na pierwsze żądania i ich inicjatorów; jeśli usterka pojawia się tylko czasami, zwykle oznacza wyścig między CMP, kontenerem tagów a kodem strony, który trzeba usunąć przez skorygowanie kolejności wczytywania, a nie maskować wizualnie szybszym banerem.

2. „Odrzuć” zmienia interfejs, lecz nie przepływ danych

Przycisk może zamknąć baner, wyszarzyć opcje, a nawet zapisać wartość „denied”, podczas gdy tagi zewnętrzne nadal działają jak wcześniej, dlatego test odmowy nie dotyczy znikającego napisu, lecz porównania dwóch stanów. Przed odrzuceniem wszystkich opcjonalnych kategorii i po nim rejestrujemy żądania oraz pamięć, a następnie sprawdzamy, czy odpowiednie tagi nie otrzymują zdarzenia aktywującego, czy nie pojawiają się nowe identyfikatory i czy kolejne odsłony zachowują odmowę. Poprzednia sesja łatwo psuje taki test: jeżeli wczoraj udzielono zgody, dzisiejsze kliknięcie „Odrzuć” może najpierw wczytać stronę ze stanem z wczoraj i dopiero później go zmienić, gdy pierwsze żądanie zostało już wysłane. Ręczne usunięcie plików cookie między krokami również tworzy sztuczną czystość i nie sprawdza prawdziwego mechanizmu wycofania, dlatego początkowa odmowa i późniejsze wycofanie to odrębne scenariusze: pierwszy zaczyna się bez decyzji, drugi — od świadomie udzielonej zgody, a ich wyników nie wolno łączyć na jednym zrzucie ekranu.

Po odmowie strona może wykonywać działania konieczne dla bezpieczeństwa, koszyka lub innej funkcji żądanej przez użytkownika, więc twierdzenie „każde żądanie po odmowie jest złe” byłoby równie mylące jak zielony znacznik. Dla każdego pozostałego połączenia ustalamy cel, inicjatora i ewentualny zapis danych, po czym konfigurujemy CMP tak, aby odmowa najpierw aktualizowała stan zgody, a tagi korzystały z wbudowanych lub jawnie wskazanych mechanizmów jej sprawdzania; sprawny przycisk przewidywalnie zmienia przepływ danych na wielu podstronach. Jeżeli odmowa zatrzymuje tag reklamowy, ale pozostawia własny sesyjny plik cookie strony, może to być wynik oczekiwany; jeżeli jedna kategoria po cichu aktywuje inną, konfiguracja jest zawodna; po naprawie odmowa musi zawsze, na wielu podstronach i bez ręcznego czyszczenia pamięci, prowadzić do tego samego odtwarzalnego i możliwego do udowodnienia stanu.

3. Kategorie i polityka plików cookie nie odpowiadają faktycznemu inwentarzowi

Baner może technicznie działać poprawnie, a mimo to wprowadzać w błąd, jeśli kategorie lub polityka opisują inną stronę, co zdarza się po skopiowaniu szablonu, przejęciu kontenera tagów lub dodaniu nowego narzędzia bez aktualizacji dokumentacji. W polityce pozostaje wtedy dawno nieużywany plik cookie, podczas gdy odtwarzacz wideo, okno czatu lub tag konwersji reklamowej nie zostały wspomniane, a użytkownik podejmuje decyzję na podstawie niepełnych informacji. W takiej sytuacji firma nie potrafi uzasadnić, który odbiorca otrzymuje dane, w jakim celu się to dzieje ani jak długo identyfikator jest przechowywany.

Polityka plików cookie powinna wynikać z rzeczywistego inwentarza, który wskazuje cel, usługodawcę lub odbiorcę oraz okres przechowywania, a nie tylko z tego, co automatycznie rozpoznał katalog CMP. Plik cookie o tej samej nazwie może mieć różne zastosowania w odmiennych konfiguracjach, natomiast niestandardowy identyfikator własny może w ogóle nie mieć opisu w publicznej bazie, dlatego w audycie łączymy obiekt techniczny z rzeczywistym celem jego użycia oraz narzędziem, które go tworzy. Zadaniem audytu nie jest przepisanie przypuszczenia z katalogu, lecz sprawdzenie, czy konfiguracja, odbiorca i okres odpowiadają temu, czego firma faktycznie używa i co potrafi wyjaśnić.

Inwentarz nie kończy się na karcie Pliki cookie: trzeba sprawdzić localStorage, sessionStorage, IndexedDB, piksele i żądania serwerowe, a także identyfikatory używane w adresach URL lub przepływach formularzy, jeżeli uczestniczą w śledzeniu. Według wytycznych technicznych EROD zakres dyrektywy o prywatności i łączności elektronicznej obejmuje więcej niż jedną technologię, więc polityka obiecująca „nie używamy plików cookie” nie odpowiada jeszcze na pytanie, czy strona inną metodą uzyskuje dostęp do informacji z urządzenia końcowego lub wysyła sygnały pomiarowe. Lista nazw plików cookie jest więc początkiem inwentaryzacji, a nie pełnym wykazem technologii zapisujących, odczytujących lub wysyłających identyfikatory.

Praktycznym rozwiązaniem jest centralny rejestr, na podstawie którego aktualizuje się klasyfikację CMP, tabelę techniczną w polityce i scenariusze audytu, a przy każdym wpisie wskazuje się właściciela narzędzia w firmie, dostawcę, cel, stan zgody uruchamiający działanie, używany rodzaj pamięci, odbiorcę oraz okres przechowywania. Dodanie nowego tagu nie jest wtedy wyłącznie pracą w kontenerze Google Tag Managera, lecz kontrolowaną zmianą wymagającą przed publikacją aktualizacji informacji dla użytkownika oraz scenariuszy testowych. Po wdrożeniu ten sam rejestr stanowi punkt wyjścia do powtarzalnego testu i pokazuje, kto w firmie odpowiada za usunięcie niezgodności.

4. Jedno żądanie w panelu Sieć uznaje się za dowód zapisania pliku cookie

Domena analityczna w panelu Sieć jest ważnym ustaleniem, lecz nie dowodzi, że „plik cookie został ustawiony”: wpis dowodzi próby połączenia i pokazuje, co przeglądarka dołączyła do adresu URL, nagłówków lub treści żądania, lecz żądanie nieudane, zablokowane albo anulowane nie dowodzi, że serwer odebrał dane. Trzeba sprawdzić, czy nagłówek żądania zawierał Cookie, czy w odpowiedzi pojawił się Set-Cookie, czy przeglądarka go nie zablokowała i czy wpis rzeczywiście trafił do pamięci. Żądanie mogło zostać zablokowane przed odbiorem danych przez serwer; opis musi zachować tę granicę i nie łączyć próby połączenia, wyniku transmisji i zapisu w jednym twierdzeniu.

Niepewny jest też wniosek odwrotny: żądanie bez pliku cookie może zawierać stan zgody i inne parametry, a strona może używać identyfikatora w localStorage, parametru URL albo innej metody technicznej; brak pliku cookie nie czyni połączenia anonimowym ani pustym. Set-Cookie to instrukcja serwera, nie gwarancja zapisu: przeglądarka może ją odrzucić z powodu domeny, atrybutów bezpieczeństwa, ograniczeń plików cookie podmiotów zewnętrznych lub innej zasady, natomiast plik cookie tej strony ustawiony przez JavaScript może pojawić się bez tego nagłówka odpowiedzi. Narzędzia deweloperskie pokazują przyczyny blokady, więc obecność Set-Cookie trzeba odczytywać razem z decyzją przeglądarki i faktycznym stanem w panelu Aplikacja. Brak nowego wiersza na karcie Pliki cookie nie oznacza „bez danych”: sprawdzamy adres URL, nagłówki, parametry i inne rodzaje pamięci.

Najbardziej wiarygodna metoda łączy trzy widoki na jednej osi czasu — co wywołało żądanie, co serwer polecił przeglądarce zrobić i co rzeczywiście pozostało potem w konkretnym profilu przeglądarki — a raport z audytu świadomie nazywa tylko to, co zostało udowodnione. Piszemy w nim „przed wyborem wysłano żądanie do domeny X”, „w odpowiedzi wykryto próbę ustawienia pliku cookie” albo „po odmowie w panelu Aplikacja pozostał identyfikator Y”, ponieważ programista może taki krok odtworzyć, prawnik widzi granice faktu technicznego, a wynik po naprawie da się obiektywnie porównać. Z jednego zrzutu ekranu nie wyprowadzamy wniosku o całym łańcuchu przetwarzania danych, gdyż może on potwierdzić jedynie konkretne działanie, stan i moment wykonania zrzutu.

5. Wycofanie zgody jest ukryte lub technicznie niepełne

Zgoda nie jest jednorazowym kliknięciem, o którym strona może zapomnieć: art. 7 ust. 3 RODO przewiduje możliwość wycofania jej w dowolnym momencie i wymaga, aby było to równie łatwe jak jej udzielenie. Jeżeli zgodę można wyrazić na pierwszym ekranie strony głównej, ale do jej wycofania trzeba odszukać podsekcję polityki prywatności, napisać wiadomość e-mail lub wyczyścić ustawienia przeglądarki, mechanizm nie jest równie dostępny; typowym rozwiązaniem jest stały link do zarządzania preferencjami w stopce strony. Sprawdzamy jego dostępność z każdej podstrony, również wtedy, gdy baner nie jest już widoczny, ponieważ właśnie w tym stanie użytkownik próbuje zmienić wcześniejszą decyzję.

Test techniczny zaczyna się od świadomego udzielenia zgody i rzeczywistego uruchomienia tagów, po czym audytor otwiera zarządzanie preferencjami, wycofuje zgodę dla opcjonalnych kategorii i nadal porusza się po stronie, bez sztucznego resetu przez ręczne czyszczenie pamięci. Trzeba sprawdzić, czy CMP wysyła zaktualizowany stan i czy tagi go otrzymują, czy nie rozpoczynają się już nowe przepływy danych oparte na zgodzie oraz co dzieje się z identyfikatorami zapisanymi lokalnie, bo właśnie tak wykrywa się przycisk, który zapisuje nowy wybór, lecz nie przekazuje go tagom już wczytanym. Jednocześnie rejestrujemy kolejność zdarzeń zmiany, aby odróżnić prawidłowo zapisany wybór od sytuacji, w której zależny tag otrzymuje aktualizację za późno albo nie otrzymuje jej wcale.

Wycofanie zgody działa na przyszłość i samo nie zmienia przeszłości ani nie usuwa wszystkich danych wcześniej przetwarzanych zgodnie z prawem, dlatego po jego dokonaniu trzeba przerwać dalsze przetwarzanie oparte na tej zgodzie, lecz przechowywanie albo usunięcie danych otrzymanych wcześniej przez serwer może wymagać osobnej oceny. W raporcie z audytu oddzielamy więc zatrzymanie przyszłych przepływów danych od kwestii przechowywania danych wcześniejszych i nie obiecujemy, że techniczna zmiana wyboru rozwiąże oba problemy. Naprawa musi połączyć interfejs z integracją: link ma być dostępny z każdej podstrony, CMP ma pokazywać bieżący stan, zmiana ma docierać do każdego zależnego tagu, a test trzeba powtórzyć z kilkoma kombinacjami kategorii, ponieważ „odrzuć wszystko” może działać, podczas gdy wyłączenie samego przełącznika marketingowego nie daje efektu. Usuwanie identyfikatorów z przeglądarki również oceniamy według ich funkcji, zamiast obiecywać, że jedno kliknięcie w CMP automatycznie wyczyści każdy system podmiotu zewnętrznego.

6. Mylone są podstawowy i zaawansowany tryb uzyskiwania zgody albo obiecuje się dane modelowane

Podstawowy i zaawansowany tryb uzyskiwania zgody nie są wariantami wyglądu jednego przełącznika. W wariancie podstawowym tagi Google są blokowane do czasu interakcji użytkownika z banerem: jeżeli zgoda nie zostanie udzielona, tagi się nie uruchamiają i Google nie otrzymuje od nich danych; po udzieleniu zgody mogą rozpocząć zwykły pomiar. W wariancie zaawansowanym tagi wczytują się przy domyślnym stanie odmowy i mogą wysyłać pomiary bez plików cookie, nie wolno więc twierdzić, że „nic nie jest wysyłane”; wariant podstawowy nie jest też automatycznie gorszy. Różnica dotyczy rzeczywistego działania tagów przed wyborem, nie wyglądu banera ani nazwy jednego ustawienia.

Wybór ma wynikać z oceny prawnej i potrzeb analitycznych firmy; nazwa produktu Google nie rozstrzyga wymagań dyrektywy ePrivacy ani RODO. Dokumentacja Google dotycząca trybu uzyskiwania zgody odróżnia blokowanie tagów w wariancie podstawowym od pomiarów bez plików cookie w wariancie zaawansowanym. W audycie sprawdzamy jednak konfigurację: czy wartości domyślne obowiązują przed tagami, jaki sygnał aktualizacyjny jest wysyłany po kliknięciu i jakie żądania pojawiają się w każdym stanie. Nazwa wariantu nie jest wnioskiem prawnym, raport opisuje więc przepływ i wybraną konfigurację, bez automatycznej etykiety zgodności.

„Bez plików cookie” nie oznacza „bez informacji”, więc raport musi oceniać treść i cel sygnału. W panelu Sieć trzeba sprawdzić adres docelowy, parametry, stan zgody i inicjatora, natomiast Google Tag Assistant lub narzędzia do debugowania trybu uzyskiwania zgody pokazują wartości domyślne i zaktualizowane; panel pokazuje przebieg konkretnej próby, a narzędzie — logikę konfiguracji. Jeśli widoki się nie zgadzają, trzeba znaleźć miejsce, w którym sygnał ustawiający stan domyślny albo go aktualizujący nie dotarł do tagu w zaplanowanej kolejności.

Dane modelowane także nie są gwarantowaną nagrodą za włączenie trybu zaawansowanego, ponieważ dostępność modelowania behawioralnego w Google Analytics 4 zależy od określonych przez Google warunków dotyczących usługi, ilości i jakości danych, a funkcja może być niedostępna albo zniknąć, gdy warunki przestaną być spełniane. Modelowanie nie odtwarza sesji poszczególnych użytkowników, którzy odmówili zgody, dlatego w ofercie obiecujemy poprawną konfigurację i sprawdzalną kolejność sygnałów, a nie konkretną ilość danych modelowanych, o której decyduje system Google oraz spełnienie warunków przez daną usługę. Wynikiem audytu jest zatem odtwarzalna konfiguracja i weryfikacja sygnałów, nie obietnica wolumenu danych, nad którym usługodawca nie ma kontroli.

7. Test kończy się na pierwszej podstronie i pierwszym dniu

Strona główna rzadko obejmuje cały inwentarz mechanizmów śledzących: tag wideo może się wczytać dopiero po rozpoczęciu odtwarzania, integracja mapy — na stronie kontaktowej, konwersja reklamowa — po wysłaniu formularza, narzędzie płatnicze — na ostatnim etapie koszyka, a skrypt czatu lub personalizacji — po określonym czasie. Audytor, który otworzy jeden adres URL, odczeka kilka sekund i zamknie skaner, może napisać technicznie poprawny raport o tym jednym widoku, a jednocześnie niebezpiecznie niepełny raport o całej stronie. Każdy z tych stanów trzeba wywołać działaniem, które naprawdę go aktywuje, zamiast zakładać, że inwentarz strony głównej automatycznie reprezentuje wszystkie szablony i ścieżki użytkownika.

Scenariusze budujemy na podstawie rzeczywistych ścieżek użytkowników i szablonów strony, obejmując stronę publiczną, artykuł, formularz kontaktowy, strefę konta, proces zakupu, osadzoną treść oraz każdą istotną wersję językową lub regionalną; trzeba też sprawdzić układ mobilny, w którym przyciski CMP mogą na siebie nachodzić albo link do preferencji może stać się niedostępny, choć na komputerze wszystko działa. Automatyczne skanowanie zapewnia szerokie pokrycie, natomiast scenariusz ręczny wywołuje stany, których robot bez konta, kliknięcia lub wpisania danych nigdy nie zobaczy. Wersje językowe i regionalne, podobnie jak układ mobilny, nie są ozdobnymi kopiami, jeśli zmienia się w nich wczytywanie integracji lub dostępne użytkownikowi wybory.

Jednorazowy audyt nie obejmuje zmian w czasie, ponieważ nowy tag marketingowy, zmiana szablonu CMP lub zaimportowany kontener Google Tag Managera mogą zepsuć wcześniej prawidłową kolejność bez widocznej zmiany banera, dlatego każde nowe narzędzie wymaga testu przed publikacją i ponownego porównania. Warto wpisać taki rygor testów już w umowie na wykonanie strony, jak wyjaśnialiśmy w artykule o 10 błędach przy zamawianiu strony internetowej; w naszym procesie audytu po wdrożeniu przewidujemy ponowny skan po 30 i 180 dniach, z użyciem tych samych scenariuszy i schematu dokumentowania dowodów, aby sprawdzić, czy poprawka pozostaje skuteczna podczas zwykłych publikacji i czy później nie pojawiły się nowe narzędzia lub odchylenia konfiguracji. Pierwszy punkt kontrolny pokazuje, czy wdrożenie pozostało poprawne podczas codziennej pracy redakcyjnej, a drugi ujawnia późniejsze zmiany; w ponownym teście porównujemy konkretne żądanie, stan pamięci i stan zgody z pierwotnym ustaleniem, zamiast poprzestać na wrażeniu, że „teraz wygląda lepiej”.

Co otrzymują Państwo w technicznym audycie plików cookie i śledzenia

Pierwszym rezultatem audytu jest zweryfikowany inwentarz plików cookie, rodzajów pamięci, tagów i żądań do podmiotów zewnętrznych, w którym każde ustalenie powiązano z podstroną, działaniem użytkownika i stanem zgody, a obok wskazano dowód oraz jego granicę: wpis w panelu Sieć, próbę ustawienia pliku cookie przez nagłówek Set-Cookie, plik cookie faktycznie zapisany w panelu Aplikacja, wpis w localStorage lub zdarzenie CMP. Programista otrzymuje dzięki temu odtwarzalny błąd, a nie niejasną uwagę „proszę naprawić RODO”, natomiast osoba odpowiedzialna za prywatność widzi, które fakty nadal wymagają decyzji prawnej. Każde ustalenie zachowuje również ścieżkę odtworzenia, aby po wdrożeniu sprawdzić dokładnie tę samą podstronę, wybór, żądanie i wynik zapisu.

Druga część to wdrożenie: porządkujemy kategorie CMP oraz kolejność wartości domyślnych i aktualizacji w Google Tag Managerze, konfigurujemy mechanizmy sprawdzania zgody w Google Analytics 4, Google Ads, Meta Pixelu i pozostałych narzędziach, a także przygotowujemy deklarację dotyczącą plików cookie i tekst polityki prywatności. Podstawowy albo zaawansowany tryb uzyskiwania zgody wybieramy na podstawie Państwa oceny prawnej i potrzeb analitycznych, nie przedstawiając wariantu zaawansowanego jako rozwiązania zawsze właściwego i nie obiecując danych modelowanych, gdy konkretna usługa Google nie spełnia warunków Google. Rezultat wdrożenia sprawdzamy w tych samych stanach zgody, w których zapisano pierwotne ustalenie, aby zmianę konfiguracji można było uzasadnić porównywalnymi dowodami.

Cena usługi wynosi od 800 €, a czas realizacji to 1–4 tygodnie, zależnie od wielkości strony, liczby języków i szablonów, złożoności CMP i kontenerów tagów oraz liczby potrzebnych integracji. Jeszcze przed rozpoczęciem prac jasno określamy w wycenie i harmonogramie, które elementy obejmują dowody z audytu i poprawki techniczne, a które wymagają decyzji prawnika firmy lub inspektora ochrony danych; po 30 i 180 dniach wykonujemy ponowny skan na podstawie utrwalonych scenariuszy. Cena i termin odnoszą się więc do precyzyjnie nazwanego zakresu technicznego, a nie do nieokreślonej obietnicy uporządkowania całej ochrony danych w przedsiębiorstwie.

Jeżeli potrzebują Państwo „audytu RODO strony internetowej”, najpierw uzgadniamy, że chodzi tu o zakres plików cookie, śledzenia, CMP i trybu uzyskiwania zgody, a nie pełne sprawdzenie zgodności całej organizacji z RODO, dlatego obiecujemy wyłącznie to, co możemy technicznie wykazać: zachowanie strony przed wyborem, po odmowie, po udzieleniu zgody i po jej wycofaniu, sygnały przesyłane narzędziom oraz miejsca, w których dowód nadal nie wystarcza do wniosku prawnego. Takie rozdzielenie pozwala zakończyć pracę techniczną sprawdzalnym wynikiem, a pytania prawne przekazać osobie odpowiedzialnej za szersze przetwarzanie danych osobowych. Zapraszamy do zamówienia audytu plików cookie i mechanizmów śledzących — wystarczy przesłać adres strony oraz nazwę używanej platformy CMP lub menedżera tagów.