Sprawdzanie banera zgody: które skrypty śledzące wczytują się, zanim ktoś kliknie

Widoczny baner zgody nie dowodzi, że śledzenie czeka. Znaczenie mają skrypty i żądania uruchamiane przed wyborem, informacje zapisywane w przeglądarce oraz zmiany po akceptacji lub odmowie.

Rzetelna kontrola łączy trzy poziomy: wskazówki w dostarczonym HTML, obserwację sieci i pamięci przeglądarki oraz konfigurację banera, menedżera tagów i serwera. Pojedyncze pobranie źródła stanowi punkt wyjścia, a nie pełną ocenę.

Dlaczego pozycja w HTML nie wystarcza

Baner jest przede wszystkim interfejsem. Zasłonięcie ekranu nie zatrzymuje połączeń sieciowych. CMP, czyli platforma zarządzania zgodą, wymaga działającej integracji z odpowiednimi usługami i tagami.

Wykonywanie skryptów nie przebiega według prostej zasady „najpierw góra, potem dół”. Klasyczne skrypty, async, defer, moduły i skrypty dodawane dynamicznie mają różne harmonogramy. Content Security Policy, błąd ładowania lub blokada przeglądarki mogą dodatkowo zatrzymać zasób. Widoczny odnośnik src wskazuje więc planowany zasób, a nie potwierdzony udany transfer.

Typowe mechanizmy wstrzymywania skryptów

Istnieje wiele podejść technicznych; poniższe przykłady nie są zamkniętą listą dokładnie trzech możliwości:

• Nieaktywny blok danych: type="text/plain" początkowo zapobiega wykonaniu jako JavaScript. Późniejsza aktywacja wymaga odpowiedniej procedury ładowania, często z utworzeniem nowego elementu script. Sama zmiana istniejącego atrybutu type nie gwarantuje uruchomienia.
• Wstrzymany adres: Przeglądarka nie pobiera adresu z data-src tak jak zasobu z src. Kod CMP może później rozpocząć właściwe pobranie. Dowolny atrybut data-* obok aktywnego src niczego samodzielnie nie blokuje.
• Warunkowe ładowanie lub uruchamianie: Kod aplikacji, integracja CMP lub menedżer tagów aktywują usługę dopiero po właściwym zezwoleniu. Załadowana biblioteka i niewysłane jeszcze zdarzenie pomiarowe to różne stany.

Zezwolenie musi odpowiadać celowi. Odmowa nie może uruchamiać usługi wymagającej zgody tylko dlatego, że został naciśnięty przycisk banera. Obserwacja w przeglądarce pozwala sprawdzić rzeczywiste działanie konfiguracji.

Consent Mode: wdrożenie podstawowe i zaawansowane

Google rozróżnia dwa warianty. W Basic Consent Mode odpowiednie tagi Google pozostają zablokowane do zgody; bez zgody do Google nie trafiają nawet dane o stanie zgody. W Advanced Consent Mode tagi mogą ładować się przy odmowie i przesyłać pomiary bez ciasteczek. Sam załadowany tag Google nie dowodzi więc ani zgody, ani błędu wdrożenia.

Sprawdzenia wymagają odpowiednie stany, zwłaszcza analytics_storage, ad_storage, ad_user_data i ad_personalization. Zezwolenie na zapis, wysyłanie danych użytkowników do celów reklamowych i reklama spersonalizowana to oddzielne ustawienia. Consent Mode nie zbiera zgody i nie zastępuje oceny prawnej.

Przy gtag.js właściwy stan domyślny powinien poprzedzać polecenia wysyłające dane pomiarowe. W GTM znaczenie mają Consent Initialization i interfejsy API zgody używane przez szablon. Brak widocznego wywołania gtag('consent', 'default', …) w HTML nie dowodzi więc braku stanu domyślnego. Widoczna wartość granted także wymaga kontekstu: default czy update, odpowiedni region i ewentualna wcześniej zapisana ważna decyzja.

wait_for_update pozwala określić ograniczony czas oczekiwania na asynchroniczną CMP. Okres na przykład 500 milisekund nie oznacza oczekiwania aż do decyzji człowieka. Tagi bez wbudowanej kontroli zgody wymagają odpowiednich dodatkowych warunków uruchamiania.

Ciasteczka mogą pojawić się już w odpowiedziach HTTP

Serwer może zażądać zapisu przez Set-Cookie, zanim pojawi się baner. Reguły przeglądarki i atrybuty ciasteczka również decydują o faktycznym zapisie. Sama linia nagłówka nie dowodzi więc obecności zapisanego ciasteczka.

Później uruchomiony baner nie może cofnąć przetworzonej odpowiedzi. Logika serwera może jednak jeszcze przed wysłaniem odpowiedzi zdecydować o ustawieniu opcjonalnego ciasteczka, na przykład na podstawie wcześniejszej zapisanej decyzji. Ciasteczka mogą też wystąpić w odpowiedziach pośrednich przekierowań. Kontrola wymaga zatem całego odpowiedniego łańcucha odpowiedzi i wynikowego stanu pamięci przeglądarki.

W Niemczech § 25 TDDDG zasadniczo wymaga zgody na zapis lub dostęp, z wąskimi wyjątkami. Ciasteczko bezwzględnie potrzebne do wyraźnie żądanego koszyka może spełniać warunki wyjątku; sama nazwa „ciasteczko sesyjne” nie wystarcza. Pozostałe wymagania ochrony danych wymagają osobnej oceny.

Rola skanera śledzenia i zgody

Skaner śledzenia i zgody analizuje HTML pobrany przez serwer według znanych wzorców. Przykładowe wyniki obejmują identyfikatory usług, odwołania do CMP, wyrażenia dotyczące zgody i cechy potencjalnie wstrzymanych skryptów. Rozpoznawanie nie wykonuje kodu strony docelowej i nie odczytuje konfiguracji kontenera GTM.

Dopasowanie może pochodzić również z komentarza lub przykładowego kodu. Brak dopasowania nie wyklucza usług nieznanych, ukrytych lub doładowywanych później. Znaleziony ciąg dotyczący zgody nie dowodzi wykonania, kolejności ani skutecznego stanu. Same cechy HTML nie pokazują wiarygodnie, które konkretne usługi są rzeczywiście blokowane.

Skan nie stanowi także pełnego spisu ciasteczek. Przekierowania i powtarzające się nagłówki Set-Cookie wymagają bezpośredniego porównania z danymi przeglądarki. Adresy prywatne, ograniczenia dostępu, limity pobierania lub ochrona przed botami mogą uniemożliwić albo ograniczyć wynik. Pobranie z lokalizacji skanera nie odzwierciedla automatycznie innych regionów, przeglądarek i zapisanych decyzji.

Powtarzalna procedura testowa

1. Opis stanu początkowego: Zapisanie adresu, czasu, regionu, przeglądarki i oczekiwanych reguł. Świeży profil testowy bez starej decyzji i nieoczekiwanych rozszerzeń. Jawne odnotowanie ochrony przed śledzeniem w przeglądarce.
2. Rejestracja przed nawigacją: Otwarcie rejestracji sieci, zachowanie logu przy nawigacji i wyłączenie pamięci podręcznej na czas testu. Następnie załadowanie strony bez początkowego wyboru w banerze. Kontrola skryptów, żądań fetch/XHR, obrazów, ramek i beaconów; śledzenie nie ogranicza się do plików JavaScript.
3. Oddzielne porównanie stanów: Nietknięty baner, odmowa, akceptacja i wybrane kategorie w osobnych powtarzalnych przebiegach. Ponowna obserwacja po istotnych interakcjach i zmianie strony.
4. Kontrola żądań i pamięci: Ustalenie adresu docelowego, czasu i przekazanych pól oraz skryptu lub dokumentu, który rozpoczął żądanie. Porównanie ciasteczek, local storage i innych używanych magazynów. Brak nowego ciasteczka nie dowodzi, że wcześniej zapisane informacje nie zostały odczytane.
5. Powrót i wycofanie zgody: Kontrola zapisanej decyzji po przeładowaniu, następnie wycofanie wcześniejszej zgody i sprawdzenie dalszego działania. W przypadku Google Tag Assistant uzupełnia porównanie stanów zgody i tagów.

Protokół powinien oddzielać obserwację od wniosku. „Żądanie do usługi X wystąpiło przed wyborem” jest sprawdzalnym ustaleniem. „Nie ma pomiaru” to zbyt mocny wniosek bez odpowiedniego zakresu kontroli. Eksporty sieciowe mogą zawierać poufne dane i wymagają chronionego przechowywania.

Pytania i odpowiedzi

Czy async albo defer czekają na zgodę?

Nie. Atrybuty regulują harmonogram wykonania i nie zawierają decyzji o zgodzie. Oczekiwanie wymaga oddzielnej integracji. Faktyczny czas zależy dodatkowo od typu skryptu i warunków ładowania.

Czy żądanie bez ciasteczek jest automatycznie nieszkodliwe?

Nie. Informacje mogą być przesyłane bez ciasteczek. Cel, zawartość, dostęp techniczny i podstawa prawna wymagają własnej oceny. Skan statyczny lub stan Consent Mode nie stanowią całościowego potwierdzenia zgodności prawnej.

Czy spokojny pierwszy odczyt strony wystarcza?

Nie. Późniejsze interakcje, zmiany widoku bez ponownego wczytania całej strony, warianty regionalne, zapisane decyzje i transmisje między serwerami mogą uruchamiać dalsze przetwarzanie. Log przeglądarki nie pokazuje też wszystkich późniejszych operacji na obcych serwerach.