Zuerst muss die App wissen, wohin die Nachricht gesendet werden soll
Bevor eine Benachrichtigung gesendet werden kann, benötigt die App eine Kennung für eine bestimmte App-Installation auf einem Gerät.
Bei Firebase Cloud Messaging wird dafür unter anderem eine Firebase Installation ID (FID) und das System für Registrierungstokens verwendet. Das Backend speichert diese Kennung, damit später gezielt eine bestimmte App-Installation angesprochen werden kann. Die Kennung bleibt jedoch nicht zwangsläufig für immer gleich. Sie kann sich beispielsweise nach einer Neuinstallation der App oder beim Wechsel auf ein anderes Gerät ändern. Die App muss daher in der Lage sein, solche Änderungen zu verarbeiten.
Vereinfacht gesagt:
Nutzer installiert die App → die App registriert sich → das Backend speichert die Kennung → später kann die Nachricht gezielt an das Gerät gesendet werden.
Auch der Nutzer selbst spielt hier eine wichtige Rolle. Denn die technische Möglichkeit, eine Push-Benachrichtigung zu senden, bedeutet noch nicht, dass der Nutzer sie tatsächlich sehen wird.
Unter iOS muss die App die Berechtigung für Benachrichtigungen, Töne oder Badges erhalten. Der Nutzer kann diese Berechtigung ablehnen oder später in den Systemeinstellungen ändern. Unter Android ist seit Android 13 für reguläre Benachrichtigungen die Laufzeitberechtigung POST_NOTIFICATIONS erforderlich.
Wenn der Nutzer Benachrichtigungen also nicht erlaubt hat, kann technisch alles korrekt funktionieren – und trotzdem erscheint kein Banner.
Was passiert nach dem Klick auf „Send“?
Stellen wir uns vor, ein Marketingteam erstellt eine Nachricht und klickt auf Send.
Das Marketing-Tool oder die Administrationsoberfläche sendet eine Anfrage an das Backend. Dieses erstellt die Nachricht mit ihrem Inhalt, dem Zielgerät oder einem Nutzersegment sowie weiteren Einstellungen.
Bei Firebase Cloud Messaging kann die Anwendung Nachrichten über einen eigenen Server an das FCM-Backend senden, das sie anschließend an das entsprechende Gerät weiterleitet.
Dabei ist ein wichtiger Unterschied zu beachten:
„Message accepted“ ≠ „message delivered“.
Wenn FCM die Anfrage akzeptiert, bedeutet das, dass die Nachricht zur Zustellung angenommen wurde. Es bedeutet nicht, dass sie bereits auf dem Smartphone angekommen ist.
Die Nachricht läuft anschließend über den passenden Push-Dienst
Der nächste Teil des Weges hängt von der Plattform ab.
Unter Android wird Firebase Cloud Messaging (FCM) verwendet. Bei Apple-Geräten ist Apple Push Notification service (APNs) der zentrale Dienst. Bei der Kommunikation mit Apple-Geräten kann FCM APNs als plattformspezifische Transportschicht verwenden.
Vereinfacht kann der Weg beispielsweise so aussehen:
Marketing-Tool → Backend → FCM → Android-Gerät
oder:
Marketing-Tool → Backend → FCM → APNs → iPhone
Eine Push-Benachrichtigung ist also nicht einfach nur eine Funktion innerhalb der App. Sie ist eine Kommunikation zwischen mehreren verschiedenen Systemen.
Was passiert, wenn das Smartphone offline ist?
Das Smartphone muss beim Versand nicht unbedingt erreichbar sein. Der Nutzer kann beispielsweise keinen Empfang haben, keine mobile Datenverbindung nutzen oder das Gerät ausgeschaltet haben.
Das Push-System kann die Nachricht deshalb für eine bestimmte Zeit zwischenspeichern und später erneut versuchen, sie zuzustellen. Bei FCM lässt sich auch die Lebensdauer einer Nachricht festlegen – also wie lange das System versuchen soll, sie zuzustellen. Nach Ablauf dieser Zeit kann die Nachricht verfallen.
Deshalb ist es wichtig, zwischen zeitkritischen Benachrichtigungen und Nachrichten zu unterscheiden, bei denen eine Verzögerung kein großes Problem darstellt.
Auch ein online befindliches Smartphone bedeutet nicht automatisch eine sofortige Anzeige
Die Zustellung kann auch von der Priorität der Nachricht und vom Zustand des Geräts beeinflusst werden.
FCM unterscheidet beispielsweise zwischen normaler und hoher Priorität. Nachrichten mit normaler Priorität können unter bestimmten Umständen später zugestellt werden, während eine hohe Priorität für zeitkritischere, für den Nutzer sichtbare Inhalte gedacht ist.
Auch das Betriebssystem wendet eigene Regeln für Akkunutzung, Apps im Hintergrund und andere Einschränkungen an.
Eine Push-Benachrichtigung ist daher kein garantierter Teleport vom Backend auf den Bildschirm.
Sobald die Nachricht ankommt, kommt auch das Betriebssystem ins Spiel
Wenn die Nachricht das Gerät erreicht, hängt das weitere Verhalten davon ab, welcher Nachrichtentyp gesendet wurde und in welchem Zustand sich die App befindet.
FCM unterscheidet beispielsweise zwischen Notification Messages und Data Messages. Eine Notification Message kann vom System für den Nutzer angezeigt werden, während eine Data Message es der App ermöglicht, die enthaltenen Daten mit ihrer eigenen Logik zu verarbeiten.
Unter iOS berücksichtigt das System außerdem die Benachrichtigungsberechtigungen und Einstellungen des Nutzers – beispielsweise Hinweise, Töne oder Badges.
Zwischen:
„Der Server hat die Nachricht gesendet“
und
„Der Nutzer hat die Benachrichtigung gesehen“
liegen also noch mehrere Entscheidungen.
Push-Benachrichtigungen sind dafür ausgelegt, auch dann zu funktionieren, wenn die App gerade nicht geöffnet ist. Das bedeutet jedoch nicht, dass die App im Hintergrund beliebige Vorgänge ausführen kann. Betriebssysteme haben eigene Regeln für die Hintergrundverarbeitung und den Umgang mit empfangenen Nachrichten.
Entwickler müssen daher genau festlegen, was beim Empfang eines bestimmten Push-Typs passieren soll.
Das kann einfach sein:
„Zeige diese Nachricht an.“
Oder es kann ein komplexerer Ablauf sein:
„Daten empfangen → Status aktualisieren → Bildschirm vorbereiten → Benachrichtigung anzeigen → beim Antippen einen bestimmten Bereich der App öffnen.“
Mit dem Antippen endet der Weg noch nicht
Schließlich tippt der Nutzer auf die Benachrichtigung und die App wird geöffnet.
Der Push kann Informationen enthalten, die der App mitteilen, wohin der Nutzer weitergeleitet werden soll – beispielsweise zu einem bestimmten Produkt, einer Bestellung, einem Chat oder einem Artikel.
Deshalb sind auch Deep Linking und das Verhalten nach dem Klick wichtige Bestandteile einer Push-Implementierung.
Ein guter Push ist also nicht einfach:
„Wir haben eine Neuigkeit!“
Es geht um die gesamte Kette:
relevante Nachricht → Klick → richtiger Bildschirm in der App.
Was passiert, wenn das Gerät nicht mehr gültig ist?
In einer produktiven Anwendung sammeln sich mit der Zeit veraltete Registrierungen an.
Ein Nutzer kann die App deinstallieren, auf ein neues Gerät wechseln oder die App-Daten löschen. Dadurch kann sich die Registrierungskennung ändern oder ungültig werden.
Das Backend sollte ungültige und über längere Zeit inaktive Registrierungen regelmäßig entfernen. Andernfalls werden weiterhin Anfragen an nicht mehr existierende Ziele gesendet und die Daten zur Zustellung können verfälscht werden.
Der gesamte Weg einer Push-Benachrichtigung
Wenn wir den gesamten Prozess zusammenfassen, sieht er ungefähr so aus:
Nutzer installiert die App
↓
Die App registriert sich beim Push-Dienst
↓
Das Backend speichert die Geräte-/Installationskennung
↓
Der Nutzer erlaubt Benachrichtigungen
↓
Das Marketing-Tool oder Backend erstellt die Nachricht
↓
Das Backend sendet sie an FCM oder APNs
↓
Der Push-Dienst leitet sie an das Gerät weiter
↓
Das Betriebssystem verarbeitet sie nach seinen eigenen Regeln
↓
Der Nutzer sieht die Benachrichtigung
↓
Nach dem Klick verarbeitet die App die Aktion und kann einen bestimmten Bildschirm öffnen
Und jeder dieser Schritte kann eine mögliche Fehlerquelle sein.
Eine Push-Benachrichtigung ist nicht nur ein Button
Wenn ein Nutzer sagt:
„Ich habe die Benachrichtigung nicht bekommen.“
sollte ein Entwickler deshalb nicht nur die Nachricht selbst überprüfen.
Geprüft werden sollte beispielsweise:
- ob die App korrekt registriert wurde,
- ob sie über eine aktuelle Kennung verfügt,
- ob der Nutzer Benachrichtigungen erlaubt hat,
- ob das Backend die Nachricht korrekt erstellt hat,
- ob der Push-Dienst sie angenommen hat,
- ob das Gerät erreichbar war,
- welche Priorität und Lebensdauer eingestellt waren,
- wie das Betriebssystem mit der Nachricht umgegangen ist,
- und was nach dem Empfang oder Antippen passiert ist.
FCM bietet außerdem verschiedene Möglichkeiten zur Überwachung der Zustellung und zur Fehlerdiagnose, darunter Berichte in der Konsole sowie detailliertere Daten über die Data API und BigQuery.
Deshalb lohnt es sich, Push-Benachrichtigungen als verteiltes System zu betrachten und nicht einfach als einen „Send“-Button.
Für den Nutzer ist es ein Banner auf dem Bildschirm.
Für die Anwendung ist es eine Reise durch Server, Kennungen, APIs, Netzwerkverbindungen und die Regeln des Betriebssystems.
Und wenn man diesen Weg versteht, wird auch deutlich, warum eine Push-Benachrichtigung manchmal sofort ankommt, manchmal später – und warum „gesendet“ nicht automatisch „zugestellt“ bedeutet.