Perché le PWA sono un caso limite per il consenso

Una Progressive Web App si comporta come un'app nativa — si installa nella schermata iniziale, funziona offline e mette in cache in modo aggressivo — ma viene comunque servita da un browser, quindi si applicano le regole sui cookie e sull'archiviazione web. È proprio questa natura ibrida a far inciampare gli editori: gli stessi obblighi di consenso GDPR di qualsiasi sito web, sovrapposti a service worker e cache persistenti che possono silenziosamente conservare dati e script dopo che un utente ha detto no.

Dove le PWA archiviano le cose

Prima di poter subordinare l'archiviazione al consenso, devi conoscere ogni luogo in cui una PWA può conservare i dati:

• Cookie — la superficie classica, regolata dal consenso come sempre.
• LocalStorage / IndexedDB — spesso usati per lo stato dell'app, ma anche per analitiche e identificatori pubblicitari.
• Cache Storage — il service worker può mettere in cache script di terze parti (analitiche, SDK pubblicitari) in modo che vengano eseguiti anche offline.
• Il service worker stesso — persiste tra le sessioni e può registrare nuovamente il tracciamento al lancio successivo.

Il consenso deve regolare tutto questo, non solo document.cookie.

Il pattern del service worker con il consenso prima di tutto

Il principio fondamentale: il service worker deve leggere lo stato del consenso prima di mettere in cache o eseguire qualsiasi risorsa di terze parti non essenziale. Un pattern pulito ha questo aspetto:

• Memorizza il segnale di consenso in un punto che il service worker possa leggere — IndexedDB o una voce della cache che la CMP aggiorna a ogni scelta.
• Nel gestore fetch del service worker, rifiuta di mettere in cache gli endpoint di analitiche/pubblicità a meno che non sia presente il consenso per tale finalità.
• Quando un utente revoca il consenso, invia un messaggio al service worker per eliminare gli script di tracciamento memorizzati nella cache e cancellare i relativi archivi IndexedDB.

Saltare quest'ultimo passaggio è la lacuna di conformità più comune delle PWA: il banner dice “rifiutato,” ma uno script di analitiche in cache continua a scattare dal service worker al lancio offline successivo.

UX del consenso offline

Le PWA possono avviarsi senza rete. Il tuo banner di consenso e la scelta memorizzata dell'utente devono entrambi funzionare offline — metti in cache l'interfaccia della CMP stessa e non impostare mai come predefinito “concesso” solo perché il server del consenso non è raggiungibile. Se non puoi confermare una scelta precedente, tratta l'utente come non consenziente e servi solo le funzionalità essenziali finché non puoi.

Implicazioni sui ricavi pubblicitari

Per le PWA supportate dalla pubblicità, lo stato del consenso deve raggiungere il tuo SDK pubblicitario al momento della richiesta, online o offline. Una PWA cablata correttamente passa la stringa IAB TCF e i segnali Consent Mode v2 ai partner della domanda esattamente come un sito normale; una mal configurata mette in cache uno stato obsoleto di “nessun consenso” e fa crollare il tuo eCPM a tariffe non personalizzate a tempo indeterminato. Tratta la freschezza del consenso come una metrica di ricavo.

Come aiuta FlexyConsent

FlexyConsent memorizza il record del consenso in un archivio leggibile dal service worker, emette segnali TCF e Consent Mode v2 che sopravvivono ai lanci offline ed espone un hook di revoca che puoi collegare alla pulizia della cache — così la tua PWA resta conforme e il tuo stack pubblicitario mantiene il segnale di consenso più fresco possibile su ogni superficie.

Punti chiave

• Le PWA affrontano tutti gli obblighi di consenso GDPR oltre alle complicazioni di service worker e cache.
• Subordina cookie, LocalStorage, IndexedDB e Cache Storage al consenso — non solo i cookie.
• In caso di revoca, elimina gli script di tracciamento in cache e cancella gli identificatori memorizzati.
• Mantieni lo stato del consenso fresco e sicuro offline così che i ricavi pubblicitari non restino bloccati a tariffe non personalizzate.