Varför PWA:er är ett gränsfall för samtycke

En progressiv webbapp beter sig som en nativ app — den installeras på hemskärmen, körs offline och cachar aggressivt — men den serveras fortfarande från en webbläsare, så reglerna för cookies och webblagring gäller. Just den hybrida naturen är vad som får publishers att snubbla: samma GDPR-samtyckesskyldigheter som vilken webbplats som helst, lagda ovanpå service workers och beständiga cachar som tyst kan behålla data och skript efter att en användare har sagt nej.

Var PWA:er lagrar saker

Innan du kan villkora lagring på samtycke behöver du känna till varje plats där en PWA kan bevara data:

• Cookies — den klassiska ytan, styrd av samtycke som alltid.
• LocalStorage / IndexedDB — ofta använda för appens tillstånd, men även för analys och annonsidentifierare.
• Cache Storage — service workern kan cacha tredjepartsskript (analys, annons-SDK:er) så att de körs även offline.
• Service workern själv — består mellan sessioner och kan återregistrera spårning vid nästa start.

Samtycke måste styra allt detta, inte bara document.cookie.

Mönstret med samtycke-först-service worker

Grundprincipen: service workern måste läsa samtyckestillståndet innan den cachar eller kör någon icke-väsentlig tredjepartsresurs. Ett rent mönster ser ut så här:

• Lagra samtyckessignalen någonstans där service workern kan läsa den — IndexedDB eller en cachepost som CMP:n uppdaterar vid varje val.
• I service workerns fetch-hanterare, vägra cacha analys-/annonsslutpunkter om inte samtycke för det ändamålet finns.
• När en användare återkallar samtycke, skicka ett meddelande till service workern för att rensa cachade spårningsskript och tömma relevanta IndexedDB-lager.

Att hoppa över det sista steget är den vanligaste efterlevnadsluckan i PWA:er: bannern säger “avvisat,” men ett cachat analysskript fortsätter att avfyras från service workern vid nästa offlinestart.

Offline-samtycke-UX

PWA:er kan startas utan nätverk. Både din samtyckesbanner och användarens lagrade val måste fungera offline — cacha själva CMP-gränssnittet, och använd aldrig “beviljat” som standard bara för att samtyckesservern är onåbar. Om du inte kan bekräfta ett tidigare val, behandla användaren som icke-samtyckande och servera endast väsentlig funktionalitet tills du kan.

Konsekvenser för annonsintäkter

För annonsfinansierade PWA:er måste samtyckestillståndet nå ditt annons-SDK vid begäran, online eller inte. En korrekt kopplad PWA skickar IAB TCF-strängen och Consent Mode v2-signaler till efterfrågepartner precis som en vanlig webbplats; en felkonfigurerad cachar ett föråldrat “inget samtycke”-tillstånd och kollapsar ditt eCPM till icke-personaliserade priser på obestämd tid. Behandla samtyckets aktualitet som ett intäktsmått.

Hur FlexyConsent hjälper

FlexyConsent lagrar samtyckesposten i ett lager som service workern kan läsa, sänder TCF- och Consent Mode v2-signaler som överlever offlinestarter, och exponerar en återkallelsekrok som du kan koppla till cacherensning — så att din PWA förblir efterlevnadsenlig och din annonsstack behåller den färskast möjliga samtyckessignalen på varje yta.

Viktiga slutsatser

• PWA:er möter fulla GDPR-samtyckesskyldigheter plus service worker- och cache-komplikationer.
• Villkora cookies, LocalStorage, IndexedDB och Cache Storage på samtycke — inte bara cookies.
• Vid återkallelse, rensa cachade spårningsskript och töm lagrade identifierare.
• Håll samtyckestillståndet färskt och offlinesäkert så att annonsintäkter inte fastnar på icke-personaliserade priser.