Why PWAs Are a Consent Edge Case

A Progressive Web App behaves like a native app — it installs to the home screen, runs offline, and caches aggressively — but it is still served from a browser, so cookies and web storage rules apply. That hybrid nature is exactly what trips publishers up: the same GDPR consent obligations as any website, layered on top of service workers and persistent caches that can quietly retain data and scripts after a user has said no.

Where PWAs Store Things

Before you can gate storage on consent, you need to know every place a PWA can persist data:

• Cookies — the classic surface, governed by consent as always.
• LocalStorage / IndexedDB — often used for app state, but also for analytics and ad identifiers.
• Cache Storage — the service worker can cache third-party scripts (analytics, ad SDKs) so they run even offline.
• Service worker itself — persists across sessions and can re-register tracking on the next launch.

Consent must govern all of these, not just document.cookie.

The Consent-First Service Worker Pattern

The core principle: the service worker must read the consent state before it caches or executes any non-essential third-party resource. A clean pattern looks like:

• Store the consent signal somewhere the service worker can read it — IndexedDB or a cache entry the CMP updates on every choice.
• In the service worker fetch handler, refuse to cache analytics/ad endpoints unless consent for that purpose is present.
• When a user withdraws consent, send a message to the service worker to purge cached tracking scripts and clear the relevant IndexedDB stores.

Skipping that last step is the most common PWA compliance gap: the banner says “rejected,” but a cached analytics script keeps firing from the service worker on the next offline launch.

Offline Consent UX

PWAs can launch with no network. Your consent banner and the user’s stored choice must both work offline — cache the CMP UI itself, and never default to “granted” just because the consent server is unreachable. If you cannot confirm a prior choice, treat the user as not-consented and serve only essential functionality until you can.

Ad Revenue Implications

For ad-supported PWAs, consent state has to reach your ad SDK at request time, online or off. A correctly wired PWA passes the IAB TCF string and Consent Mode v2 signals to demand partners just like a normal site; a misconfigured one caches a stale “no consent” state and collapses your eCPM to non-personalized rates indefinitely. Treat consent freshness as a revenue metric.

How FlexyConsent Helps

FlexyConsent stores the consent record in a service-worker-readable store, emits TCF and Consent Mode v2 signals that survive offline launches, and exposes a withdrawal hook you can wire to cache purging — so your PWA stays compliant and your ad stack keeps the freshest possible consent signal across every surface.

Key Takeaways

• PWAs face full GDPR consent duties plus service-worker and cache complications.
• Gate cookies, LocalStorage, IndexedDB, and Cache Storage on consent — not just cookies.
• On withdrawal, purge cached tracking scripts and clear stored identifiers.
• Keep consent state fresh and offline-safe so ad revenue isn’t stuck at non-personalized rates.