Por que os PWAs são um caso-limite de consentimento

Um Progressive Web App comporta-se como um app nativo — instala-se na tela inicial, funciona offline e armazena em cache de forma agressiva — mas continua sendo servido a partir de um navegador, então as regras de cookies e armazenamento web se aplicam. Essa natureza híbrida é exatamente o que faz os publishers tropeçarem: as mesmas obrigações de consentimento GDPR de qualquer site, sobrepostas a service workers e caches persistentes que podem reter silenciosamente dados e scripts depois que um usuário disse não.

Onde os PWAs armazenam coisas

Antes de poder condicionar o armazenamento ao consentimento, você precisa conhecer cada lugar onde um PWA pode persistir dados:

• Cookies — a superfície clássica, regida pelo consentimento como sempre.
• LocalStorage / IndexedDB — frequentemente usados para o estado do app, mas também para análises e identificadores de anúncios.
• Cache Storage — o service worker pode armazenar em cache scripts de terceiros (análises, SDKs de anúncios) para que sejam executados mesmo offline.
• O próprio service worker — persiste entre sessões e pode registrar novamente o rastreamento na próxima inicialização.

O consentimento deve reger tudo isso, não apenas document.cookie.

O padrão service worker com consentimento primeiro

O princípio central: o service worker deve ler o estado do consentimento antes de armazenar em cache ou executar qualquer recurso de terceiros não essencial. Um padrão limpo é assim:

• Armazene o sinal de consentimento em algum lugar que o service worker possa ler — IndexedDB ou uma entrada de cache que o CMP atualize a cada escolha.
• No manipulador fetch do service worker, recuse armazenar em cache os endpoints de análise/anúncios a menos que haja consentimento para esse propósito.
• Quando um usuário retira o consentimento, envie uma mensagem ao service worker para limpar os scripts de rastreamento em cache e apagar os armazenamentos IndexedDB relevantes.

Pular esse último passo é a falha de conformidade mais comum em PWAs: o banner diz “rejeitado,” mas um script de análise em cache continua disparando a partir do service worker na próxima inicialização offline.

UX de consentimento offline

Os PWAs podem ser iniciados sem rede. Tanto o seu banner de consentimento quanto a escolha armazenada do usuário devem funcionar offline — armazene em cache a própria interface do CMP e nunca assuma “concedido” por padrão só porque o servidor de consentimento está inacessível. Se você não puder confirmar uma escolha anterior, trate o usuário como não consentido e ofereça apenas a funcionalidade essencial até que possa.

Implicações na receita de anúncios

Para PWAs com anúncios, o estado do consentimento precisa chegar ao seu SDK de anúncios no momento da solicitação, online ou não. Um PWA corretamente conectado passa a string IAB TCF e os sinais do Consent Mode v2 aos parceiros de demanda exatamente como um site normal; um mal configurado armazena em cache um estado desatualizado de “sem consentimento” e derruba seu eCPM para taxas não personalizadas indefinidamente. Trate a atualidade do consentimento como uma métrica de receita.

Como o FlexyConsent ajuda

O FlexyConsent armazena o registro de consentimento em um armazenamento legível pelo service worker, emite sinais de TCF e Consent Mode v2 que sobrevivem às inicializações offline e expõe um hook de retirada que você pode conectar à limpeza de cache — para que seu PWA permaneça em conformidade e sua stack de anúncios mantenha o sinal de consentimento mais atualizado possível em todas as superfícies.

Principais conclusões

• Os PWAs enfrentam plenas obrigações de consentimento GDPR mais as complicações de service workers e cache.
• Condicione cookies, LocalStorage, IndexedDB e Cache Storage ao consentimento — não apenas os cookies.
• Na retirada, limpe os scripts de rastreamento em cache e apague os identificadores armazenados.
• Mantenha o estado do consentimento atualizado e seguro offline para que a receita de anúncios não fique presa em taxas não personalizadas.