Die Kurzfassung
Die beiden Kanäle sehen sich ähnlich, weil beide in Ihrem Produkt kleine Nachrichten anzeigen, aber sie liegen auf entgegengesetzten Seiten zweier Grenzen: Reichweite und Einwilligung. Web-Push verlässt Ihre Website und landet auf dem Gerät, nachdem der Nutzer eine Browser-Berechtigung erteilt hat. In-App-Nachrichten bleiben in einer aktiven Sitzung und brauchen keine eigene Berechtigung. Behandeln Sie sie als zwei Werkzeuge, nicht als eines.
So funktioniert Web-Push
Web-Push beruht auf drei Bausteinen im Browser, die zusammenspielen: einem Service Worker (ein Hintergrundskript, das der Browser am Laufen hält), der Push API (die den Browser bei einem Push-Dienst anmeldet und Nachrichten empfängt) und der Notifications API (die die Systembenachrichtigung anzeigt). Der Nutzer muss in der Berechtigungsabfrage des Browsers ausdrücklich auf „Zulassen“ klicken; bis dahin können Sie nichts senden. Nach dem Opt-in erhalten Sie einen Subscription-Endpunkt und Schlüssel für die Verschlüsselung, und Ihr Server sendet über den Push-Dienst des Browsers, selbst wenn der Tab geschlossen ist. Weil die Nachricht außerhalb der Website ankommt, ist Web-Push in dieser Gruppe der Kanal für die Reaktivierung – von der Aufgabe her näher an SMS oder E-Mail als an allem, was innerhalb Ihrer App stattfindet. Der Haken: Web-Push ist an die Unterstützung durch Browser und Betriebssystem gebunden, und der Nutzer kann die Berechtigung jederzeit widerrufen.
Die Einschränkung unter iOS
Auf iPhone und iPad funktioniert Web-Push nicht in einem normalen Safari-Tab. Apple hat Web-Push ab Safari 16.4 (März 2023) nur für Web-Apps eingeführt, die der Nutzer zum Home-Bildschirm hinzugefügt hat. Die Berechtigungsabfrage muss auf ein direktes Tippen hin erscheinen – etwa auf einen Button „Abonnieren“ –, nicht beim Laden der Seite. Unter iOS erreichen Sie also nur die Teilmenge der Nutzer, die Ihre Website als Web-App installiert und dann die Berechtigung erteilt haben. Planen Sie diese Lücke ein, statt dieselbe Abdeckung wie am Desktop anzunehmen.
So funktionieren In-App-Nachrichten
In-App-Nachrichten erscheinen in einer aktiven Sitzung – als Banner, Modal, Slideout oder Tooltip, das Ihr Produkt anzeigt, während der Nutzer es verwendet. Ein eigenes Opt-in gibt es nicht, weil der Nutzer schon in Ihrem Produkt ist; die Nachricht ist Teil des Erlebnisses. Der Preis dafür ist die Reichweite: In-App erreicht nur Menschen, die gerade jetzt da sind. Einen inaktiven Nutzer holt es nicht zurück, und ein abgewanderter Nutzer sieht die Nachricht nie.
Wann Sie welchen Kanal nutzen
| Aufgabe | Der passende Kanal |
|---|---|
| Einen inaktiven Nutzer zurückholen | Web-Push (oder E-Mail / SMS) |
| Aktiven Nutzern eine Funktion ankündigen | In-App-Banner oder -Modal |
| Neue Nutzer durch die Einrichtung führen | In-App-Tooltip oder -Slideout |
| Außerhalb der Website auf ein zeitkritisches Ereignis hinweisen | Web-Push |
| Mitten in einer Aufgabe ein Upgrade anbieten | In-App-Modal |
Die ehrliche Aufteilung: In-App kümmert sich um die Menschen, die schon im Raum sind, Web-Push sucht die, die gegangen sind. Die meisten Produkte nutzen beides, koordiniert in einer Customer Journey, damit dieselbe Person nicht innerhalb weniger Minuten einen In-App-Hinweis und einen Push zum selben Thema bekommt. Zu entscheiden, welcher Kanal welche Nachricht in welcher Reihenfolge ohne Überschneidung trägt, ist der Schritt von vielen nebeneinander laufenden Kanälen hin zu einem gemeinsamen Ganzen – das Thema von Multichannel vs. Omnichannel. Eigenständige Tools wie OneSignal oder Novu sind auf die Zustellung von Push und Benachrichtigungen spezialisiert; eine Engagement-Plattform bindet Push und In-App in dieselbe Journey-Logik ein wie Ihre übrigen Kanäle.