Dlaczego PWA to przypadek graniczny zgody

Progresywna Aplikacja Webowa zachowuje się jak aplikacja natywna — instaluje się na ekranie głównym, działa offline i agresywnie buforuje — ale wciąż jest serwowana z przeglądarki, więc obowiązują zasady dotyczące plików cookie i pamięci webowej. To właśnie ta hybrydowa natura jest tym, na czym potykają się wydawcy: te same obowiązki zgody RODO co w przypadku każdej witryny, nałożone na service workery i trwałe pamięci podręczne, które mogą po cichu zachowywać dane i skrypty po tym, jak użytkownik powiedział nie.

Gdzie PWA przechowują rzeczy

Zanim będziesz mógł uzależnić przechowywanie od zgody, musisz znać każde miejsce, w którym PWA może utrwalać dane:

• Pliki cookie — klasyczna powierzchnia, regulowana zgodą jak zawsze.
• LocalStorage / IndexedDB — często używane do stanu aplikacji, ale również do analityki i identyfikatorów reklamowych.
• Cache Storage — service worker może buforować skrypty stron trzecich (analityka, SDK reklamowe), aby działały nawet offline.
• Sam service worker — utrzymuje się między sesjami i może ponownie zarejestrować śledzenie przy następnym uruchomieniu.

Zgoda musi regulować wszystkie te elementy, nie tylko document.cookie.

Wzorzec service workera z priorytetem zgody

Główna zasada: service worker musi odczytać stan zgody, zanim zbuforuje lub wykona jakikolwiek nieistotny zasób strony trzeciej. Czysty wzorzec wygląda tak:

• Przechowuj sygnał zgody w miejscu, które service worker może odczytać — IndexedDB lub wpis w pamięci podręcznej, który CMP aktualizuje przy każdym wyborze.
• W obsłudze fetch service workera odmów buforowania punktów końcowych analityki/reklam, chyba że istnieje zgoda na ten cel.
• Gdy użytkownik wycofa zgodę, wyślij wiadomość do service workera, aby wyczyścił zbuforowane skrypty śledzące i wymazał odpowiednie magazyny IndexedDB.

Pominięcie tego ostatniego kroku to najczęstsza luka w zgodności PWA: baner mówi “odrzucono”, ale zbuforowany skrypt analityczny nadal się uruchamia z service workera przy następnym uruchomieniu offline.

UX zgody offline

PWA mogą uruchamiać się bez sieci. Twój baner zgody i zapisany wybór użytkownika muszą działać offline — buforuj sam interfejs CMP i nigdy nie ustawiaj domyślnie “udzielono” tylko dlatego, że serwer zgody jest nieosiągalny. Jeśli nie możesz potwierdzić wcześniejszego wyboru, traktuj użytkownika jako niewyrażającego zgody i serwuj tylko niezbędną funkcjonalność, dopóki nie będziesz mógł.

Implikacje dla przychodów reklamowych

W przypadku PWA opartych na reklamach stan zgody musi dotrzeć do Twojego SDK reklamowego w momencie żądania, online lub offline. Poprawnie podłączone PWA przekazuje ciąg IAB TCF i sygnały Consent Mode v2 do partnerów popytu dokładnie jak normalna witryna; źle skonfigurowane buforuje nieaktualny stan “brak zgody” i zawala Twój eCPM do stawek niepersonalizowanych na czas nieokreślony. Traktuj świeżość zgody jako wskaźnik przychodów.

Jak pomaga FlexyConsent

FlexyConsent przechowuje rekord zgody w magazynie odczytywalnym przez service worker, emituje sygnały TCF i Consent Mode v2, które przetrwają uruchomienia offline, oraz udostępnia hook wycofania, który możesz podłączyć do czyszczenia pamięci podręcznej — dzięki czemu Twoje PWA pozostaje zgodne, a Twój stos reklamowy zachowuje możliwie najświeższy sygnał zgody na każdej powierzchni.

Kluczowe wnioski

• PWA stają wobec pełnych obowiązków zgody RODO plus komplikacji związanych z service workerami i pamięcią podręczną.
• Uzależnij pliki cookie, LocalStorage, IndexedDB i Cache Storage od zgody — nie tylko pliki cookie.
• Przy wycofaniu wyczyść zbuforowane skrypty śledzące i wymaż zapisane identyfikatory.
• Utrzymuj stan zgody świeży i bezpieczny offline, aby przychody reklamowe nie utknęły na stawkach niepersonalizowanych.