Hvorfor PWA'er er et samtykke-grænsetilfælde

En Progressive Web App opfører sig som en native app — den installeres på startskærmen, kører offline og cacher aggressivt — men den serveres stadig fra en browser, så reglerne for cookies og weblagring gælder. Den hybride natur er præcis det, der får udgivere til at snuble: de samme GDPR-samtykkeforpligtelser som ethvert websted, lagt oven på service workers og vedvarende caches, der stille kan bevare data og scripts, efter at en bruger har sagt nej.

Hvor PWA'er gemmer ting

Før du kan gatekeepe lagring på samtykke, skal du kende hvert sted, hvor en PWA kan bevare data:

• Cookies — den klassiske overflade, styret af samtykke som altid.
• LocalStorage / IndexedDB — ofte brugt til app-tilstand, men også til analyse og annonce-id'er.
• Cache Storage — service worker'en kan cache tredjepartsscripts (analyse, annonce-SDK'er), så de kører selv offline.
• Selve service worker'en — bevares på tværs af sessioner og kan genregistrere sporing ved næste opstart.

Samtykke skal styre alle disse, ikke kun document.cookie.

Samtykke-først service worker-mønsteret

Kerneprincippet: service worker'en skal læse samtykketilstanden, før den cacher eller udfører nogen ikke-essentiel tredjepartsressource. Et rent mønster ser sådan ud:

• Gem samtykkesignalet et sted, hvor service worker'en kan læse det — IndexedDB eller en cache-post, som CMP'en opdaterer ved hvert valg.
• I service worker'ens fetch-handler, nægt at cache analyse-/annonceendpoints, medmindre samtykke til det formål er til stede.
• Når en bruger trækker samtykke tilbage, send en besked til service worker'en om at udrense cachede sporingsscripts og rydde de relevante IndexedDB-stores.

At springe det sidste trin over er den mest almindelige PWA-compliancekløft: banneret siger “afvist,” men et cachet analysescript fortsætter med at fyre fra service worker'en ved næste offlineopstart.

Offline samtykke-UX

PWA'er kan starte uden netværk. Dit samtykkebanner og brugerens gemte valg skal begge fungere offline — cache selve CMP-grænsefladen, og fald aldrig tilbage til “givet” bare fordi samtykkeserveren ikke kan nås. Hvis du ikke kan bekræfte et tidligere valg, behandl brugeren som ikke-samtykkende og servér kun essentiel funktionalitet, indtil du kan.

Konsekvenser for annonceindtægter

For annoncefinansierede PWA'er skal samtykketilstanden nå din annonce-SDK på anmodningstidspunktet, online eller offline. En korrekt forbundet PWA sender IAB TCF-strengen og Consent Mode v2-signaler til demand-partnere ligesom et normalt websted; en fejlkonfigureret cacher en forældet “intet samtykke”-tilstand og kollapser din eCPM til ikke-personaliserede rater på ubestemt tid. Behandl samtykkefriskhed som en indtægtsmetrik.

Hvordan FlexyConsent hjælper

FlexyConsent gemmer samtykkeoptegnelsen i en service worker-læsbar store, udsender TCF- og Consent Mode v2-signaler, der overlever offlineopstarter, og eksponerer en tilbagetrækningshook, du kan forbinde til cacheudrensning — så din PWA forbliver compliant, og din annoncestak bevarer det friskest mulige samtykkesignal på tværs af hver overflade.

Vigtigste pointer

• PWA'er står over for fulde GDPR-samtykkepligter plus service worker- og cachekomplikationer.
• Gatekeep cookies, LocalStorage, IndexedDB og Cache Storage på samtykke — ikke kun cookies.
• Ved tilbagetrækning, udrens cachede sporingsscripts og ryd gemte id'er.
• Hold samtykketilstanden frisk og offlinesikker, så annonceindtægter ikke sidder fast på ikke-personaliserede rater.