Blokowanie skryptów do momentu uzyskania zgody

CookieZen blokuje te skrypty, które zostaną oznaczone w kodzie strony, i uruchamia je dopiero wtedy, gdy użytkownik wyrazi zgodę na odpowiednią kategorię.

Ten wpis odpowiada na trzy pytania: których narzędzi nie trzeba oznaczać, jak oznaczyć pozostałe oraz jak sprawdzić w przeglądarce, że blokada działa. Do oznaczenia skryptu wystarczą dwa atrybuty HTML, więc nie jest do tego potrzebny programista, o ile jest dostęp do kodu strony lub do miejsca, w którym wkleja się skrypty zewnętrzne.

Dwie warstwy zgody

CookieZen chroni prywatność odwiedzających na dwa niezależne sposoby i tylko jeden z nich wymaga pracy w kodzie strony.

Najczęstszy błąd jest odwrotny do tego, którego ludzie się boją: nie brak oznaczeń, a oznaczanie narzędzi, które same respektują zgodę. Podwójna blokada tagów Google psuje pomiar, rozstraja Tag Assistanta i odbiera Google Ads możliwość modelowania konwersji.

Jak oznaczyć skrypt

Potrzebne są dwa atrybuty naraz: type="text/plain" oraz data-cmp-category z nazwą kategorii.

type="text/plain" sprawia, że przeglądarka traktuje zawartość jak zwykły tekst i jej nie wykonuje. Po zgodzie CookieZen wstawia w to miejsce prawdziwy skrypt, z zachowaniem pozostałych atrybutów, takich jak async, defer czy crossorigin. Sam atrybut data-cmp-category, bez zmiany type, niczego nie blokuje.

Kategorie

Nazwy zapisuje się małymi literami, dokładnie tak jak w tabeli. Można wymienić kilka kategorii po przecinku, na przykład data-cmp-category="analytics,marketing", i wtedy do uruchomienia skryptu wystarczy zgoda na jedną z nich.

Mapy, filmy i widgety w ramkach

Osadzoną treść blokuje się inaczej niż skrypt. Adres docelowy przenosi się z src do data-cmp-src.

Zamiast pustego miejsca użytkownik zobaczy kartę z informacją, że treść czeka na zgodę, przyciskiem „Wyrażam zgodę" i linkiem do zarządzania zgodami. Kliknięcie przycisku nadaje wymaganą kategorię i od razu ładuje treść. Karta pojawia się tylko przy ramkach widocznych dla użytkownika; ramki wielkości piksela śledzącego są blokowane bez karty, żeby nie zaśmiecać strony.

Trzy błędy, które wyglądają jak działająca blokada

To najważniejsza część tego wpisu. Każdy z tych trzech błędów daje stronę, która wygląda na poprawnie zabezpieczoną, a nie jest, i żaden z nich nie objawia się komunikatem o błędzie.

1. Kategoria bez zmiany typu skryptu

Bez zmiany type przeglądarka uruchamia skrypt w chwili, gdy go wczyta, czyli zanim CookieZen w ogóle się załaduje. Blokady nie ma, a w kodzie widać atrybut, który sugeruje, że jest.

Ten przypadek jest z trzech najgroźniejszy, bo jako jedyny kończy się zebraniem danych przed zgodą, podczas gdy strona wygląda na zabezpieczoną. CookieZen ostrzega o nim w konsoli komunikatem zawierającym no type="text/plain" i informację, że skrypt już się wykonał.

2. Literówka albo wielka litera w nazwie kategorii

Nazwy kategorii są wrażliwe na wielkość liter. Nieznana nazwa nigdy nie dostanie zgody, więc skrypt pozostaje zablokowany na stałe, także po zaakceptowaniu wszystkich kategorii. Objawem jest narzędzie, które po prostu przestało zbierać dane. CookieZen ostrzega o tym w konsoli przeglądarki komunikatem [CookieZen] Unknown consent category.

3. Adres zostawiony w src obok data-cmp-src

Przeglądarka zaczyna pobierać treść ramki w momencie, w którym czyta kod strony, a więc zanim baner istnieje. CookieZen zablokuje wyświetlenie treści, ale żądanie do zewnętrznego serwera, razem z adresem IP odwiedzającego, zostało już wysłane i nie da się go cofnąć. Adres musi znaleźć się wyłącznie w data-cmp-src. Ten przypadek również kończy się ostrzeżeniem w konsoli.

Jak sprawdzić, że blokada działa

Panel nie ma wglądu w kod strony, więc oznaczeń nie da się sprawdzić z panelu. Sprawdzenie zajmuje minutę w przeglądarce, w narzędziach deweloperskich (klawisz F12).

Stronę trzeba otworzyć w oknie prywatnym, żeby nie było zapisanej zgody, i nie klikać jeszcze w baner. W karcie Network nie powinno być wtedy żadnego żądania do zablokowanego narzędzia. Następnie w konsoli wystarczy wpisać CookieZen.debug().stats i sprawdzić dwie liczby: pendingBlockedScripts to skrypty czekające na zgodę, pendingBlockedFrames to ramki. Jeśli oznaczone zostały trzy skrypty, a licznik pokazuje zero, oznaczenia nie działają i najprawdopodobniej wystąpił jeden z trzech błędów opisanych wyżej.

Na liście blocked przy każdym poprawnie oznaczonym zasobie widać powód manual-data-attr. Po zaakceptowaniu zgody w banerze liczniki spadają do zera, a w karcie Network pojawiają się żądania, których wcześniej nie było.

Odmowa, powrót na stronę i awaria banera

Po odrzuceniu zgody oznaczone skrypty pozostają zablokowane, a narzędzia z Consent Mode dostają sygnał odmowy. Gdy użytkownik wróci na stronę z zapisaną zgodą, jego skrypty uruchamiają się od razu, bez cyklu zablokuj i odblokuj, który restartowałby Google Tag Managera.

Jeśli baner z jakiegokolwiek powodu się nie załaduje, na przykład zablokuje go wtyczka w przeglądarce, oznaczone skrypty nie uruchomią się wcale. To zachowanie celowe, bo bezpieczniejsze prawnie, ale ma praktyczną konsekwencję: nie należy oznaczać w ten sposób niczego, od czego zależy działanie sklepu, na przykład koszyka, płatności, wyszukiwarki czy czata z obsługą.

Kiedy oznaczanie skryptów nie wystarczy

Oznaczanie działa na kod obecny w szablonie strony. Nie obejmie trzech sytuacji.

• Cookies zapisywane po stronie serwera na WordPressie. Tu rozwiązaniem jest standard, który przekazuje zgodę wtyczkom. Opisuje go WP Consent API dla WordPress.
• Tagi uruchamiane z Google Tag Managera. Nimi steruje się w GTM, nie atrybutami w kodzie strony. Ścieżkę opisuje wpis o wyłączeniu Consent Mode i blokowaniu tagów.
• Skrypty wstrzykiwane przez platformę sklepową. Jeśli sklep sam dodaje piksel reklamowy przez własną integrację, jego kodu nie ma w szablonie i nie da się go oznaczyć. Na Shoperze CookieZen synchronizuje zgody z wbudowanym Customer Privacy API platformy, więc własne skrypty warunkuje się mechanizmem Shopera, a nie atrybutami CookieZen. Opisuje to Wdrożenie CookieZen na Shoperze i zgody dla skryptów.