Warum PWAs ein Sonderfall der Einwilligung sind

Eine Progressive Web App verhält sich wie eine native App — sie installiert sich auf dem Startbildschirm, läuft offline und cached aggressiv — wird aber dennoch über einen Browser ausgeliefert, sodass die Regeln für Cookies und Web-Speicher gelten. Genau diese hybride Natur bringt Publisher ins Straucheln: dieselben DSGVO-Einwilligungspflichten wie bei jeder Website, überlagert von Service Workern und persistenten Caches, die Daten und Skripte stillschweigend behalten können, nachdem ein Nutzer Nein gesagt hat.

Wo PWAs Dinge speichern

Bevor Sie die Speicherung an die Einwilligung koppeln können, müssen Sie jeden Ort kennen, an dem eine PWA Daten persistieren kann:

• Cookies — die klassische Fläche, wie immer durch die Einwilligung geregelt.
• LocalStorage / IndexedDB — oft für den App-Zustand genutzt, aber auch für Analytics und Werbe-Identifier.
• Cache Storage — der Service Worker kann Drittanbieter-Skripte (Analytics, Werbe-SDKs) cachen, sodass sie sogar offline laufen.
• Der Service Worker selbst — bleibt über Sitzungen hinweg bestehen und kann beim nächsten Start Tracking erneut registrieren.

Die Einwilligung muss all dies regeln, nicht nur document.cookie.

Das Consent-First-Service-Worker-Muster

Das Kernprinzip: der Service Worker muss den Einwilligungsstatus lesen, bevor er irgendeine nicht-essenzielle Drittanbieter-Ressource cached oder ausführt. Ein sauberes Muster sieht so aus:

• Speichern Sie das Einwilligungssignal an einem Ort, den der Service Worker lesen kann — IndexedDB oder ein Cache-Eintrag, den der CMP bei jeder Wahl aktualisiert.
• Verweigern Sie im fetch-Handler des Service Workers das Cachen von Analytics-/Werbe-Endpunkten, sofern keine Einwilligung für diesen Zweck vorliegt.
• Wenn ein Nutzer die Einwilligung widerruft, senden Sie eine Nachricht an den Service Worker, um gecachte Tracking-Skripte zu löschen und die relevanten IndexedDB-Stores zu leeren.

Diesen letzten Schritt zu überspringen ist die häufigste PWA-Compliance-Lücke: das Banner sagt “abgelehnt”, aber ein gecachtes Analytics-Skript feuert beim nächsten Offline-Start weiter aus dem Service Worker.

Offline-Einwilligungs-UX

PWAs können ohne Netzwerk starten. Ihr Einwilligungsbanner und die gespeicherte Wahl des Nutzers müssen beide offline funktionieren — cachen Sie die CMP-Oberfläche selbst und setzen Sie niemals auf “erteilt” als Standard, nur weil der Einwilligungsserver nicht erreichbar ist. Wenn Sie eine frühere Wahl nicht bestätigen können, behandeln Sie den Nutzer als nicht-einwilligend und liefern Sie nur essenzielle Funktionen aus, bis Sie es können.

Auswirkungen auf die Werbeeinnahmen

Für werbefinanzierte PWAs muss der Einwilligungsstatus Ihr Werbe-SDK zum Zeitpunkt der Anfrage erreichen, online oder offline. Eine korrekt verdrahtete PWA übergibt den IAB-TCF-String und die Consent Mode v2-Signale genau wie eine normale Website an die Demand-Partner; eine fehlkonfigurierte cached einen veralteten “keine Einwilligung”-Zustand und drückt Ihren eCPM auf unbestimmte Zeit auf nicht-personalisierte Tarife. Behandeln Sie die Aktualität der Einwilligung als Umsatzmetrik.

Wie FlexyConsent hilft

FlexyConsent speichert den Einwilligungsdatensatz in einem für den Service Worker lesbaren Store, gibt TCF- und Consent Mode v2-Signale aus, die Offline-Starts überleben, und stellt einen Widerrufs-Hook bereit, den Sie mit dem Cache-Löschen verdrahten können — sodass Ihre PWA konform bleibt und Ihr Werbe-Stack über jede Fläche hinweg das frischestmögliche Einwilligungssignal behält.

Wichtigste Erkenntnisse

• PWAs unterliegen vollen DSGVO-Einwilligungspflichten plus Service-Worker- und Cache-Komplikationen.
• Koppeln Sie Cookies, LocalStorage, IndexedDB und Cache Storage an die Einwilligung — nicht nur Cookies.
• Löschen Sie beim Widerruf gecachte Tracking-Skripte und entfernen Sie gespeicherte Identifier.
• Halten Sie den Einwilligungsstatus frisch und offline-sicher, damit die Werbeeinnahmen nicht bei nicht-personalisierten Tarifen feststecken.