Web-Push-Benachrichtigungen: Wie sie funktionieren und wie du sie gut einsetzt

Web-Push-Benachrichtigungen sind der einzige Marketingkanal, in dem eine einzige schlechte Designentscheidung dich dauerhaft von einer Person aussperren kann. Frag zum falschen Moment nach der Berechtigung, die Person klickt auf Blockieren, und dieser Browser ist für dich für immer zu. Keine neue Anfrage, keine zweite Kampagne, keine Rückgewinnungs-E-Mail. Diese Asymmetrie ist der Grund, warum sich der Mechanismus lohnt, bevor du die erste Nachricht schreibst.

Was Web-Push-Benachrichtigungen sind

Eine Web-Push-Benachrichtigung ist eine Nachricht, die dein Server an den Browser einer abonnierenden Person sendet, die vom Benachrichtigungszentrum des Betriebssystems angezeigt wird und die auch dann ankommt, wenn deine Website geschlossen ist. Genau der letzte Punkt ist der Sinn der Sache: Anders als ein Popup auf der Seite erreicht Web Push jemanden, der gerade nicht auf deine Website schaut.

Der Kanal ist aus drei Web-Plattform-APIs gebaut, die zusammenarbeiten, und die Aufteilung zwischen ihnen erklärt fast das gesamte Verhalten: die Service Worker API, die Push API und die Notifications API.

Wie Web Push unter der Haube funktioniert

Der Service Worker

Ein Service Worker ist ein JavaScript-Worker, der als Proxy zwischen deiner Web-App, dem Browser und dem Netzwerk arbeitet. Er läuft in einem eigenen Thread, hat keinen DOM-Zugriff und existiert weiter, nachdem die Seite geschlossen wurde, die ihn registriert hat. Diese Beständigkeit erlaubt ihm, eine Push-Nachricht zu empfangen und eine Benachrichtigung anzuzeigen, wenn niemand deinen Tab offen hat. Service Worker laufen nur in sicheren Kontexten, also über HTTPS, wobei http://localhost für die Entwicklung als sicher gilt.

Das Abonnement: ein Endpunkt plus zwei Schlüssel

Sobald ein Service Worker aktiv ist, ruft die Seite registration.pushManager.subscribe() auf. Der Browser spricht mit dem Push-Dienst seines Herstellers und liefert ein PushSubscription zurück, das Folgendes enthält:

• endpoint, eine eindeutige Capability-URL, an der der Push-Dienst Nachrichten annimmt
• keys.p256dh, einen öffentlichen Elliptic-Curve-Diffie-Hellman-Schlüssel auf der P-256-Kurve
• keys.auth, ein Authentifizierungsgeheimnis

Dein Server speichert alle drei und behandelt den Endpunkt als Geheimnis, denn wer ihn besitzt, kann an dieses Abonnement senden. Die Schlüssel existieren, weil Payloads Ende zu Ende verschlüsselt sind. RFC 8291 legt fest, wie: Ein ECDH-Austausch auf P-256 erzeugt ein gemeinsames Geheimnis, HKDF leitet daraus Schlüssel ab, und der Payload wird mit AES-128-GCM unter der Content-Kodierung aes128gcm versiegelt. Der Push-Dienst leitet Chiffretext weiter, den er nicht lesen kann.

Der Push-Dienst

Du sendest Push-Nachrichten nicht direkt an ein Gerät. Du sendest sie an einen Push-Dienst, den der Browser-Hersteller betreibt: Googles FCM-Endpunkte für Chrome, Mozillas Autopush für Firefox, Apples Push-Dienst für Safari. RFC 8030, „Generic Event Delivery Using HTTP Push”, definiert das Protokoll. Dein Server sendet ein POST an den Abonnement-Endpunkt, und der Push-Dienst übernimmt die schwierigen Teile der mobilen Auslieferung: eine batteriesparende Verbindung zum Gerät, Warteschlange im Offline-Fall, Aufwecken des Browsers bei eingehender Nachricht. Genau deshalb lässt sich die Zustellung auch nicht garantieren. Ist das Gerät lange genug aus, laufen Nachrichten gemäß ihrer TTL ab und werden verworfen.

VAPID: nachweisen, wer sendet

Dass der Endpunkt geheim ist, ist dünne Sicherheit. RFC 8292 ergänzt Voluntary Application Server Identification, kurz VAPID, damit ein Push-Dienst erkennen kann, von welchem Anwendungsserver eine Nachricht kam.

Du erzeugst einmalig ein ECDSA-Schlüsselpaar auf der NIST-P-256-Kurve. Der öffentliche Schlüssel wandert beim Abonnieren in applicationServerKey und bindet das Abonnement an deinen Server. Für jeden Push sendet dein Server ein JWT, das mit dem passenden privaten Schlüssel per ES256 signiert ist und einen aud-Claim für die Origin des Push-Dienstes trägt, einen exp-Claim von höchstens 24 Stunden und optional einen sub-Claim mit Kontaktdaten. Der Push-Dienst prüft die Signatur, ein gestohlener Endpunkt allein reicht also nicht mehr, um deine Abonnent:innen zuzuspammen.

Der Zustellweg von Anfang bis Ende

1. Die Seite registriert einen Service Worker und ruft nach erteilter Berechtigung subscribe() mit deinem öffentlichen VAPID-Schlüssel auf.
2. Dein Server speichert den zurückgegebenen Endpunkt und die Schlüssel am Datensatz der abonnierenden Person.
3. Zum Senden verschlüsselt dein Server den Payload mit p256dh und auth, signiert ein VAPID-JWT und sendet ein POST an den Endpunkt.
4. Der Push-Dienst authentifiziert die Anfrage und stellt die verschlüsselte Nachricht zu.
5. Der Browser weckt den Service Worker mit einem push-Event, das den Payload entschlüsselt und ServiceWorkerRegistration.showNotification() aufruft.
6. Ein Klick löst notificationclick im Service Worker aus, wo du die Ziel-URL öffnest.

Warum das Berechtigungsmodell so streng ist

Sieh dir an, was ein Abonnement gewährt: einen Hintergrundprozess, der läuft, ohne dass deine Website offen ist, plus die Möglichkeit, auf die Benachrichtigungsfläche des Betriebssystems zu zeichnen. Browser sichern das deshalb hinter einer ausdrücklichen, pro Origin erteilten Berechtigung ab, und die meisten verlangen, dass die Anfrage auf eine echte Nutzergeste folgt.

Eine zweite Einschränkung überrascht viele. Chrome und Edge verlangen beim Abonnieren userVisibleOnly: true, also das Versprechen, dass jeder Push eine sichtbare Benachrichtigung erzeugt. Stille Hintergrund-Pushes sind damit keine unterstützte Nutzung der API. Firefox begrenzt Push-Nachrichten, die keine Benachrichtigung erzeugen, zusätzlich über ein Kontingent.

Browser- und Plattform-Unterstützung

Laut MDN ist die Push API seit März 2023 als Baseline breit verfügbar, funktioniert also in aktuellen Versionen von Chrome, Edge, Firefox und Safari auf dem Desktop sowie in Chrome und Firefox für Android. Zwei Einschränkungen wiegen schwerer als die Schlagzeile.

Erstens ist die Notifications API nicht überall verfügbar. MDN kennzeichnet sie als eingeschränkt verfügbar, weil der Notification()-Konstruktor in den meisten mobilen Browsern einen TypeError wirft. Für alles, was auf Smartphones laufen muss, nutze stattdessen persistente Benachrichtigungen über ServiceWorkerRegistration.showNotification(), also ohnehin den Service-Worker-Weg.

Zweitens sind die Optionen für Benachrichtigungen ungleich umgesetzt. Aktionsbuttons, Badges, Bilder und requireInteraction unterscheiden sich zwischen Browsern und Betriebssystemen. Gestalte Benachrichtigungen also so, dass sie auch nur mit Titel, Text und Icon korrekt lesbar sind.

Die Anforderung unter iOS und iPadOS

Diese Einschränkung entscheidet, ob Web Push für eine mobil geprägte Zielgruppe überhaupt taugt, und sie wird fast überall falsch wiedergegeben.

Apple hat Web Push in iOS und iPadOS 16.4 eingeführt, und es funktioniert nur für Web-Apps, die zum Home-Bildschirm hinzugefügt wurden. WebKit formuliert es so: „Wir ergänzen die Unterstützung für Web Push in Web-Apps auf dem Home-Bildschirm” und „eine Web-App, die zum Home-Bildschirm hinzugefügt wurde, kann die Berechtigung für Push-Benachrichtigungen anfragen”. Nutzer:innen fügen die App über das Teilen-Menü und „Zum Home-Bildschirm” hinzu, und die Berechtigung muss danach als Reaktion auf eine direkte Interaktion angefragt werden, etwa das Tippen auf einen Abonnieren-Button.

Eine Website, die in einem gewöhnlichen Safari-Tab auf dem iPhone offen ist, kann kein Push-Abonnement anlegen. Das ist eine echte Hürde: Du verlangst einen Installationsschritt, bevor du überhaupt nach der Berechtigung fragen darfst. Auf macOS ist es einfacher, denn Safari 16.1 unter macOS Ventura hat standardbasiertes Web Push für normale Websites ohne Installationsschritt eingeführt.

Ein minimales Beispiel für ein Abonnement

Das ist der gesamte Ablauf auf Client-Seite. Er gehört in einen Klick-Handler, nicht in das Laden der Seite.

async function subscribeToPush(vapidPublicKey) {
  // Push und Service Worker brauchen einen sicheren Kontext (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Muss aus einer Nutzergeste heraus aufgerufen werden, und nur einmal pro Person.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // base64url-kodierter öffentlicher P-256-Schlüssel
  });

  // Endpunkt + Schlüssel serverseitig speichern; Endpunkt als Geheimnis behandeln.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

In sw.js behandelst du das push-Event, rufst self.registration.showNotification(title, options) auf und verarbeitest notificationclick, um die Ziel-URL zu öffnen.

Permission-UX: woran die meisten Programme scheitern

Frag niemals beim Laden der Seite

Lighthouse hat dafür einen eigenen Audit: „Wenn deine Seite beim Laden um die Berechtigung für Benachrichtigungen bittet, sind diese Benachrichtigungen für die Nutzenden oder ihre Bedürfnisse möglicherweise nicht relevant”. Die Empfehlung lautet, einen konkreten Benachrichtigungstyp anzubieten und die Berechtigung erst anzufragen, nachdem sich jemand für diesen Typ entschieden hat. Safari 12.1 und andere Browser gingen weiter und verlangen eine Interaktion mit der Seite, bevor überhaupt gefragt werden darf.

Nutze einen weichen Vorab-Dialog

Zeig zuerst deine eigene Einladung auf der Seite. Sie benennt den Nutzen, sie lässt sich ohne dauerhaften Schaden wegklicken, und erst ein Klick darauf löst den echten Browser-Dialog aus. Wer deinen weichen Dialog heute ignoriert, kann nächsten Monat erneut gefragt werden. Wer auf Blockieren klickt, nicht. Zwei Regeln machen es wirksam: Beschreibe, was du tatsächlich senden wirst, statt „Updates erhalten”, und provoziere nie einen versehentlichen Klick, denn eine versehentliche Zustimmung endet sofort in einer Abmeldung.

Frag im Kontext

Chromes eigene Empfehlung lautet, „die Initiative den Nutzenden zu überlassen und Benachrichtigungen in ihrem eigenen Tempo aktivieren zu lassen”, indem du Schalter dezent in bestehende Oberflächen einbaust, und zu vermeiden, „Dialoge oder Overlays ohne Kontext oder direkt nach dem Betreten der Website zu zeigen”.

Im Handel funktionieren ganz bestimmte Momente: ein Schalter „Benachrichtige mich, wenn wieder verfügbar” bei einem ausverkauften Produkt, eine Bestellbestätigungsseite mit Angebot für Lieferupdates, ein Preisalarm bei einem häufig angesehenen Produkt. Die Berechtigung wird gegen einen konkret benannten Nutzen getauscht statt abgegriffen.

Eine Ablehnung ist faktisch endgültig

Wenn jemand Benachrichtigungen blockiert, speichert der Browser diese Entscheidung für deine Origin. Spätere Aufrufe von Notification.requestPermission() lösen ohne sichtbaren Dialog auf den gespeicherten Wert denied auf. Genau deshalb prüft MDNs eigenes Beispiel Notification.permission, bevor es überhaupt requestPermission() aufruft. Eine Blockade zurückzunehmen heißt, sich durch die Website-Einstellungen zu graben, und das macht faktisch niemand.

Was Browser tun, wenn du es falsch machst

Die Folgen sind längst nicht mehr nur eine niedrige Opt-in-Rate.

• Chrome stuft Origins mit sehr niedrigen Zustimmungsraten automatisch in eine leisere Berechtigungs-UI ein, getrennt nach Gerätetyp, und unterdrückt den Dialog damit für alle.
• Chrome begrenzt Websites, die hohes Push-Volumen mit niedrigem Engagement verbinden, per Rate Limit und gibt HTTP 429 zurück. Die Eskalation läuft einen Tag, dann sieben, dann vierzehn und setzt sich erst nach 42 aufeinanderfolgenden Tagen ohne Störungen zurück.
• Chrome entzieht die Benachrichtigungsberechtigung inzwischen automatisch bei Websites, mit denen jemand zuletzt nicht interagiert hat und bei denen es „sehr geringes Engagement und ein hohes Volumen gesendeter Benachrichtigungen” gibt. Googles Begründung ist nüchtern: „Weniger als 1 % aller Benachrichtigungen erhalten überhaupt eine Interaktion.”

Du kannst also Abonnent:innen verlieren, die du bereits gewonnen hattest, allein weil du schlecht sendest.

Web Push im Vergleich mit E-Mail und SMS

Der Unterschied im Besitz, der die Strategie verändert

Ein Push-Abonnement ist eine Capability-URL, gebunden an ein Browserprofil auf einem Gerät. Es ist keine Person. Dieselbe Kundschaft, die Chrome auf dem Laptop und Firefox auf dem Handy nutzt, sind zwei unabhängige Abonnements, und du kannst nicht wissen, dass dahinter derselbe Mensch steckt, solange er sich nicht selbst zu erkennen gibt.

Es ist außerdem nicht portabel. Eine E-Mail-Liste kannst du exportieren und morgen in eine andere Plattform laden. Push-Abonnements lassen sich nicht zwischen Anbietern verschieben, weil die Schlüssel und die VAPID-Bindung gegen einen bestimmten Application Server Key erzeugt wurden.

Behandle Web Push also als Beschleuniger für einen Kanal, der dir gehört, nie als Ersatz. Nutze den Push-Moment, um eine E-Mail-Adresse oder eine Telefonnummer zu gewinnen, nicht umgekehrt. Der komplette Leitfaden zur Marketing-Automation zeigt, wie du mehrere Kanäle in eine Journey verdrahtest.

Anwendungsfälle, die wirklich funktionieren

Der Kanal belohnt Nachrichten, die zeitkritisch, persönlich relevant und mit einem Tipp erledigt sind.

• Warenkorbabbruch. Ein Push innerhalb einer Stunde, später durch eine E-Mail verstärkt. Der Leitfaden zu Warenkorbabbruch-E-Mails behandelt die Abfolge.
• Verfügbarkeitsalarme. Der stärkste Fall, weil ausdrücklich darum gebeten wurde.
• Preissenkungen bei beobachteten Artikeln. Dieselbe Logik, selbst gewählte Relevanz.
• Liefer- und Bestellstatus. Hohe Öffnungsabsicht, geringes Beschwerderisiko.
• Eilmeldungen in einem abonnierten Thema. Nachrichten, Ergebnisse, Verfügbarkeitsfenster.

Was scheitert, ist genauso klar: allgemeine „wir haben einen neuen Beitrag veröffentlicht”-Rundmails, undifferenzierte Tagesangebote, alles, was mehr als Titel und eine Zeile braucht, Reaktivierungswellen an Abonnent:innen, die schon die letzten zwanzig Benachrichtigungen ignoriert haben, und transaktionale Inhalte, die einen dauerhaften Beleg brauchen.

Frequenz, Timing und Segmentierung

Starte zurückhaltend: eine bis drei Benachrichtigungen pro Abonnement und Woche, und erhöhe nur, wenn Abmelde- und Klickraten stabil bleiben. Ermüdung zeigt sich schneller als bei E-Mail, weil das Stummschalten einen Tipp auf einer Benachrichtigung kostet, die das Betriebssystem ohnehin schon eingeblendet hat.

Timing ist Vorteil und Gefahr zugleich. Push kommt sofort an, eine um 02:00 Uhr gesendete Nachricht landet also um 02:00 Uhr. Speichere oder erschließe die Zeitzone beim Abonnieren und halte Sendungen innerhalb eines definierten Fensters.

Segmentierung ist dadurch begrenzt, dass du ein Abonnement kennst und keine Person. Die brauchbaren Dimensionen sind daher verhaltensbasiert: gesehene Seiten, beobachtete Produkte, Warenkorbstatus, Kaufaktualität, Plattform. Der Leitfaden zur Kundensegmentierung geht tiefer.

Web Push messen

Vier Kennzahlen zählen, und sie lassen sich nicht alle gleich messen.

• Zustellung. Ob der Push-Dienst die Anfrage angenommen hat. Eine 201 bedeutet angenommen, nicht zugestellt. Eine 404 oder 410 bedeutet, dass das Abonnement tot ist.
• Anzeige. Ob die Benachrichtigung angezeigt wurde. Das weißt du nur, wenn der Service Worker zurückmeldet, dass showNotification() aufgelöst hat.
• Klickrate. Klicks geteilt durch Anzeigen. Das ist die Zahl, die sich zu optimieren lohnt.
• Abmelderate. Abmeldungen und entzogene Berechtigungen pro Sendung. Beobachte sie genauer als die Klickrate, denn sie ist der Frühindikator für das Sterben des Kanals.

Fallstricke bei der Attribution

Push-Attribution schmeichelt sich selbst. Die Benachrichtigung landet auf einem Gerät, das die Person ohnehin in der Hand hält, und nimmt deshalb oft eine Sitzung für sich in Anspruch, die auch so stattgefunden hätte. Arbeite mit Holdout-Gruppen, statt Inkrementalität zu unterstellen. Anzeigen werden untererfasst, während jeder Klick erfasst wird, eine gegen Sendungen gerechnete Klickrate übertreibt die Leistung also. Und weil ein Abonnement ein Browser und keine Person ist, sieht ein Push, der auf dem Handy geklickt wird und in einem Kauf am Desktop endet, wie zwei unabhängige Ereignisse aus. Der Leitfaden zu E-Mail-Marketing-Kennzahlen behandelt saubere Messung über Kanäle hinweg.

Einwilligung, GDPR und Opt-out

Der Berechtigungsdialog des Browsers ist eine technische Hürde. Er ist nicht automatisch eine vollständige Rechtsgrundlage für Marketing.

Wenn du Menschen in der EU oder in Großbritannien bewirbst, behandle Push wie E-Mail. Erkläre vor dem Dialog, was du senden wirst, damit die Einwilligung informiert und spezifisch ist. Halte fest, wann und wo das Abonnement entstanden ist, und bündle die Push-Einwilligung nie mit einer unabhängigen Handlung. Wenn du Abonnements identifizierten Personen zuordnest, fallen diese Daten unter deine Pflichten zum Umgang mit personenbezogenen Daten, inklusive Löschanfragen.

Sauberes Opt-out zählt genauso. Biete auf der Website eine Einstellungsseite an, damit Menschen die Frequenz senken können, statt zu blockieren, rufe dann PushSubscription.unsubscribe() auf und lösche den Datensatz serverseitig, und räume Abonnements bei einer 404 oder 410 auf. MDNs Hinweis ist kurz und richtig: Menschen sollte „ein einfacher Weg angeboten werden, künftige Benachrichtigungen abzubestellen”.

Wo Web Push in einen Kanal-Stack passt

Web Push ist ein guter dritter und ein schlechter erster Kanal: schnell, an der Grenze kostenlos und unschlagbar für zeitkritische Hinweise, aber gerätegebunden, nicht exportierbar und einen Klick vom dauerhaften Verlust entfernt.

Damit wird Orchestrierung zum eigentlichen Problem. Welche Nachricht geht in welchen Kanal, wie unterdrückst du die E-Mail, wenn der Push schon konvertiert hat, und wie behältst du eine Sicht auf die Kundschaft über Oberflächen hinweg, die Menschen unterschiedlich identifizieren. Brevo bietet Web- und Mobile-Push neben E-Mail und SMS, und Tajo sitzt auf Brevo auf, um genau diese kanalübergreifende Logik für Shopify-Stores zu koordinieren. Für die SMS-Seite siehe den Leitfaden zur SMS-Automation.

Die wichtigsten Erkenntnisse

• Web Push sind drei kooperierende APIs: ein Service Worker für die Ausführung im Hintergrund, die Push API für Abonnement und Transport, die Notifications API für die Anzeige. Ein Abonnement ist ein Endpunkt plus ein p256dh-Schlüssel und ein auth-Geheimnis, Payloads sind Ende zu Ende verschlüsselt, und VAPID weist den Absender nach.
• Push ist seit März 2023 als Baseline breit verfügbar, unter iOS und iPadOS funktioniert es aber nur für Web-Apps, die zum Home-Bildschirm hinzugefügt wurden.
• Frag nie beim Laden der Seite nach der Berechtigung. Nutze einen weichen Vorab-Dialog, frag im Kontext, und denk daran, dass eine Blockade für diese Origin dauerhaft ist.
• Chrome erzwingt inzwischen leisere Dialoge, Rate Limits und automatischen Entzug der Berechtigung, schlechtes Senden kostet dich also Abonnent:innen, die du bereits hast.
• Ein Abonnement ist ein Browser, keine Person, und lässt sich nicht exportieren. Bau zuerst die E-Mail-Liste und nutze Push, um sie zu beschleunigen.