Por que as PWA son un caso límite do consentimento

Unha aplicación web progresiva compórtase coma unha app nativa — instálase na pantalla de inicio, funciona sen conexión e almacena en caché de forma agresiva — pero séguese servindo desde un navegador, polo que se aplican as regras de cookies e almacenamento web. Esa natureza híbrida é exactamente o que fai tropezar aos publishers: as mesmas obrigas de consentimento GDPR ca calquera sitio web, superpostas a service workers e cachés persistentes que poden reter silenciosamente datos e scripts despois de que un usuario dixese que non.

Onde almacenan as cousas as PWA

Antes de poder condicionar o almacenamento ao consentimento, necesitas coñecer cada lugar onde unha PWA pode persistir datos:

• Cookies — a superficie clásica, rexida polo consentimento coma sempre.
• LocalStorage / IndexedDB — a miúdo usados para o estado da app, pero tamén para analítica e identificadores publicitarios.
• Cache Storage — o service worker pode almacenar en caché scripts de terceiros (analítica, SDK de anuncios) para que se executen mesmo sen conexión.
• O propio service worker — persiste entre sesións e pode volver rexistrar o rastrexo no seguinte inicio.

O consentimento debe rexer todo isto, non só document.cookie.

O patrón de service worker con consentimento primeiro

O principio central: o service worker debe ler o estado do consentimento antes de almacenar en caché ou executar calquera recurso de terceiros non esencial. Un patrón limpo vese así:

• Almacena o sinal de consentimento nalgún lugar que o service worker poida ler — IndexedDB ou unha entrada de caché que o CMP actualice en cada elección.
• No manexador fetch do service worker, négate a almacenar en caché os endpoints de analítica/anuncios a menos que estea presente o consentimento para ese propósito.
• Cando un usuario retira o consentimento, envía unha mensaxe ao service worker para purgar os scripts de rastrexo almacenados en caché e limpar os almacéns de IndexedDB pertinentes.

Omitir ese último paso é a fenda de cumprimento máis común en PWA: o banner di “rexeitado,” pero un script de analítica en caché segue executándose desde o service worker no seguinte inicio sen conexión.

UX de consentimento sen conexión

As PWA poden iniciarse sen rede. Tanto o teu banner de consentimento coma a elección almacenada do usuario deben funcionar sen conexión — almacena en caché a propia interface do CMP, e nunca uses “concedido” por defecto só porque o servidor de consentimento non estea accesible. Se non podes confirmar unha elección previa, trata o usuario coma sen consentimento e serve unicamente a funcionalidade esencial ata que poidas.

Implicacións para os ingresos publicitarios

Para as PWA con publicidade, o estado do consentimento ten que chegar ao teu SDK de anuncios no momento da solicitude, con ou sen conexión. Unha PWA correctamente conectada pasa a cadea IAB TCF e os sinais de Consent Mode v2 aos socios de demanda igual ca un sitio normal; unha mal configurada almacena en caché un estado obsoleto de “sen consentimento” e afunde o teu eCPM a tarifas non personalizadas indefinidamente. Trata a frescura do consentimento coma unha métrica de ingresos.

Como axuda FlexyConsent

FlexyConsent almacena o rexistro de consentimento nun almacén lexible polo service worker, emite sinais de TCF e Consent Mode v2 que sobreviven aos inicios sen conexión, e expón un hook de retirada que podes conectar á purga de caché — para que a túa PWA siga cumprindo e a túa pila publicitaria manteña o sinal de consentimento máis fresco posible en cada superficie.

Puntos clave

• As PWA afrontan plenas obrigas de consentimento GDPR máis as complicacións de service workers e caché.
• Condiciona cookies, LocalStorage, IndexedDB e Cache Storage ao consentimento — non só as cookies.
• Ao retirar o consentimento, purga os scripts de rastrexo en caché e limpa os identificadores almacenados.
• Mantén o estado do consentimento fresco e seguro sen conexión para que os ingresos publicitarios non queden atascados en tarifas non personalizadas.