Öffnen Sie fast jedes B2B-Produkt, und oben rechts sitzt eine Glocke mit einer roten Zahl. Klicken Sie darauf, finden Sie einen Kommentar einer Kollegin, vier automatische Statusmeldungen, Werbung für einen Tarif, den Sie bereits nutzen, und etwas aus dem März. Die Zahl verschwindet. Gelernt hat niemand etwas. Nächste Woche ist die Zahl wieder da, und inzwischen schaut niemand mehr hin.
In-App-Benachrichtigungen gehören zu den wenigen Produktflächen, die auf null Nutzen absinken können und auf einem Dashboard trotzdem völlig gesund aussehen. Der Feed wird weiter geöffnet, weil das Badge es verlangt. Das Badge wird weiter geleert, weil es nervt. Keine dieser beiden Tatsachen bedeutet, dass irgendjemand etwas gelesen hat.
Dieser Leitfaden behandelt gezielt die Benachrichtigungsebene: den dauerhaften, adressierten, vom Nutzer selbst abgerufenen Teil Ihrer In-App-Kommunikation. Breit ausgespielte Nachrichten, die unterbrechen (Modals, Banner, Slideouts, Tooltips), sind ein anderes System mit anderen Regeln, das wir in unserem Leitfaden zu In-App-Messaging behandeln. Zu wissen, welches der beiden Sie bauen, ist schon der größte Teil der Designaufgabe.
Das Wichtigste in Kürze
- Benachrichtigungen sind adressiert und dauerhaft, Nachrichten breit ausgespielt und unterbrechend. Wer beides vermischt, zerstört den Feed.
- Vier Kategorien gehören in einen Feed: persönlich, Workflow, System und relevante Produktneuigkeiten. Alles andere ist Marketing mit Glocke.
- Das Badge ist ein Versprechen. Eine Zahl, die nie auf null fällt, bringt Nutzern bei, sie dauerhaft zu ignorieren.
- Bündeln Sie nach Objekt oder nach Tag. Fünf Ereignisse zum selben Dokument sind eine Benachrichtigung, nicht fünf.
- Schreiben Sie nach dem Muster Person, Aktion, Objekt, verlinken Sie den ganzen Eintrag auf das genaue Ziel, und zeigen Sie einen relativen Zeitstempel.
- Die Stummschaltungsrate ist die ehrliche Kennzahl. Die Klickrate bleibt gut, bis Nutzer die Kategorie abschalten.
Was In-App-Benachrichtigungen wirklich sind
In-App-Benachrichtigung, in einem Absatz
Eine In-App-Benachrichtigung ist eine Nachricht, die innerhalb Ihres Produkts an einen bestimmten Nutzer geht, und zwar über etwas, das passiert ist oder seine Aufmerksamkeit braucht. Sie liegt normalerweise in einem dauerhaften Notification Center, das über ein Glockensymbol geöffnet wird, hat einen Status gelesen/ungelesen und bleibt verfügbar, bis sich der Nutzer darum kümmert. Entscheidend sind zwei Eigenschaften: Sie ist adressiert, betrifft also genau diese Person, und sie ist dauerhaft: Sie wartet, statt zu unterbrechen, und der Nutzer entscheidet, wann er hinschaut.
Drei Flächen werden ständig miteinander verwechselt, und die Unterscheidung ist nicht akademisch: Sie bestimmt, wo eine Mitteilung hingehört und welche Regeln für sie gelten.
| In-App-Benachrichtigung | In-App-Nachricht | Push-Benachrichtigung | |
|---|---|---|---|
| Zielgruppe | Ein Nutzer, persönlich adressiert | Ein Segment, breit ausgespielt | Ein Nutzer, außerhalb des Produkts |
| Zustellung | Wartet im Feed, Nutzer ruft ab | Erscheint auf dem Screen, unterbricht | Über das Betriebssystem, braucht Erlaubnis |
| Lebensdauer | Dauerhaft, bis gelesen oder gelöscht | Einmal angezeigt, dann weg | Flüchtig, oft übersehen |
| Typischer Einsatz | Kommentar, Freigabe, fertiger Job, relevantes Release | Onboarding-Schritt, Ankündigung, Hinweis | Inaktive Nutzer zurückholen |
| Hauptrisiko | Wird zu Rauschen, das niemand liest | Unterbricht im falschen Moment | Erlaubnis verweigert oder App deinstalliert |
Die Zuordnungsregel. Muss der Nutzer es jetzt sehen, damit der aktuelle Screen Sinn ergibt, ist es eine Nachricht. Braucht er einen Beleg dafür und kann später reagieren, ist es eine Benachrichtigung. Ist es keines von beiden, also etwas, das Sie ihm mitteilen wollen, und nicht etwas, das er braucht, gehört es vermutlich in Ihr Changelog und sonst nirgendwohin.
Zwei Zustellmodelle: Unterbrechung und Posteingang
Jedes Benachrichtigungssystem muss pro Eintrag entscheiden, ob es sofort Aufmerksamkeit verlangt oder darauf wartet, gefunden zu werden. Die meisten Produkte geraten in Schwierigkeiten, weil sie alles standardmäßig einem der beiden Modelle zuordnen.
Unterbrechung (an die Oberfläche gebracht)
- Toast, Snackbar oder ein Banner, das direkt an Ort und Stelle erscheint
- Richtig für: etwas, das gerade als Folge einer eigenen Aktion des Nutzers passiert ist, oder etwas Zeitkritisches
- Kosten: Aufmerksamkeit, sofort und ohne Verhandlungsspielraum
- Budget: eine Handvoll pro Sitzung, bevor es chaotisch wirkt
Posteingang (wartet im Feed)
- Notification Center hinter einer Glocke, mit Lesestatus und Verlauf
- Richtig für: alles, worauf der Nutzer später reagieren kann, und alles, was er vielleicht wiederfinden will
- Kosten: fast keine, bis der Feed seine Glaubwürdigkeit verliert
- Budget: großzügig, aber nur solange die Trefferquote hoch bleibt
Wenige Einträge verdienen beides: eine Freigabe, die die Arbeit eines anderen blockiert, eine fehlgeschlagene Zahlung, ein Export, auf den der Nutzer gerade wartet. Das Muster, das funktioniert, ist ein kurzer Toast im Moment des Ereignisses plus ein dauerhafter Eintrag im Feed, damit ein Nutzer, der den Toast verpasst hat, trotzdem einen Beleg hat. Das Muster, das nicht funktioniert, ist ein Toast allein: eine Benachrichtigung, die Sie absichtlich weggeworfen haben.
Der Aufbau eines Notification Centers
Ein Feed, dem Nutzer weiter vertrauen, besteht aus sieben Teilen, und die Teams lassen beständig die letzten drei weg.
Vier Einträge, vier Kategorien, ein gruppiertes Ereignis, und jede Zeile sagt, wer was mit welchem Objekt getan hat.
- Einstiegspunkt und Badge. Ein einheitliches, gut auffindbares Symbol mit einem Status, der etwas bedeutet. Eine Zahl für Einträge, die einzeln Aufmerksamkeit brauchen, ein einfacher Punkt für alles andere.
- Einträge mit Struktur. Person, Aktion, Objekt, Zeitstempel, und die ganze Zeile klickbar bis zum genauen Ziel, nicht zu einem Dashboard, von dem aus der Nutzer erst weiternavigieren muss.
- Ein Lesestatus, der bestehen bleibt. Ungelesenes sollte sofort erkennbar sein, gelesene Einträge sollten verfügbar bleiben, und das Öffnen des Panels sollte nicht stillschweigend alles als gelesen markieren; so gehen Dinge verloren.
- Gruppierung. Fünf Kommentare zu einem Dokument sind ein aufklappbarer Eintrag, nicht fünf Zeilen. Bei allem, was mit Zusammenarbeit zu tun hat, schlägt die Gruppierung nach Objekt die Gruppierung nach Zeit.
- Kategorien oder Filter. Sobald es mehr als etwa drei Arten von Benachrichtigungen gibt, müssen Nutzer „Dinge, die auf mich warten“ von „Dingen, die passiert sind“ trennen können.
- Ein Empty State, der keine Leere ist. „Sie sind auf dem neuesten Stand“ plus ein Hinweis auf die Einstellungen ist ein wirklich guter Empty State; das allgemeine Muster beschreibt unser Leitfaden zu Empty States.
- Ein sichtbarer Weg zu den Einstellungen. Wer eine Kategorie abschalten kann, schaltet nicht alle ab. Der Link gehört ins Panel selbst, nicht drei Ebenen tief in die Einstellungen.
Was in den Feed gehört und was nicht
| Kategorie | Beispiele | Soll sie das Badge auslösen? |
|---|---|---|
| Persönlich | Erwähnung, Kommentar, Antwort, geteiltes Element, Zuweisung | Ja, immer |
| Workflow | Wartende Freigabe, angefragtes Review, fällige Aufgabe, Übergabe | Ja, das ist die wertvollste Kategorie |
| System | Export bereit, Import fehlgeschlagen, Integration getrennt, Kontingent erreicht | Nur, wenn eine Aktion nötig ist |
| Produktneuigkeiten | Eine neue Funktion in dem Bereich, in dem dieser Nutzer tatsächlich arbeitet | Selten: ein Punkt, keine Zahl |
| Werbung | Upgrade-Hinweise, Webinare, Launches ohne Bezug | Nein, das gehört überhaupt nicht in den Feed |
Die vierte Zeile verlangt Urteilsvermögen. Produktneuigkeiten können durchaus in einen Feed gehören (es ist einer der wenigen Orte, an denen ein zurückkehrender Nutzer nachsieht, was sich geändert hat), aber nur, wenn sie für diesen Nutzer relevant sind, und nur als Eintrag mit niedriger Priorität. Sobald Release-Ankündigungen ein Zahlen-Badge auslösen, bedeutet das Badge nicht mehr „etwas braucht Sie“, sondern „wir haben etwas veröffentlicht“, und das ist der Anfang vom Ende. Unser Playbook für Feature-Ankündigungen zeigt, wie Sie einen Launch über mehrere Flächen hinweg staffeln, und der Beitrag zu Release Notes behandelt das dauerhafte Archiv, auf das der Feed verlinken sollte, statt es zu ersetzen.
Das schleichende Werbeproblem. Jeder überfüllte Feed ist auf dieselbe Weise entstanden: Ein Team, das nichts anzukündigen hatte, bemerkte die guten Öffnungsraten des Notification Centers und nutzte sie. Öffnungsraten sind eine Eigenschaft des Badges, nicht des Inhalts; sie halten monatelang, während das Vertrauen schwindet, und wenn sich die Kennzahl endlich bewegt, kommen die Nutzer, die stummgeschaltet haben, nicht zurück. Es ist derselbe Mechanismus wie die Banner-Blindheit, angewendet auf eine Komponente, an der man nicht vorbeiscrollen kann.
Die Benachrichtigung formulieren
Benachrichtigungstexte haben eine ungewöhnlich strenge Aufgabe: Sie werden in weniger als einer Sekunde gelesen, ohne Kontext, neben neun anderen Zeilen. Drei Regeln erledigen den Großteil der Arbeit.
1. Person, Aktion, Objekt, in dieser Reihenfolge
Der Nutzer überfliegt die ersten Wörter. Setzen Sie die Person und die Aktion dorthin, und nennen Sie das konkrete Objekt statt seines Typs.
2. Den ganzen Eintrag auf das genaue Ziel verlinken
Nicht auf das Modul, nicht auf eine Liste, die der Nutzer dann durchsuchen muss. Verlinken Sie direkt auf den Kommentar, die Freigabe, die Datei. Eine Benachrichtigung, nach deren Klick man noch navigieren muss, hat die Arbeit auf den Nutzer verlagert und keinen der Vorteile behalten.
3. Die Sprache der Nutzer verwenden, nicht die des Systems
Interne Objektnamen sickern schneller in Benachrichtigungsvorlagen als irgendwo sonst in einem Produkt, weil Benachrichtigungen meist von der Person geschrieben werden, die das Ereignis gebaut hat. „Entity-Sync abgeschlossen“ bedeutet für den Leser nichts. Unser Leitfaden zu UX-Microcopy zeigt die Muster zum Umschreiben; die Abkürzung: Lesen Sie die Zeile laut vor und fragen Sie sich, ob ein neuer Kunde sie verstehen würde.
Frequenz, Bündelung und das Badge
Es gibt kein allgemeingültiges Tageslimit, denn welche Menge erträglich ist, hängt vollständig von der Trefferquote ab. Ein Feed, in dem sich vier von fünf Einträgen lohnen, verträgt viel; ein Feed, in dem drei von vier Einträgen Rauschen sind, wird bei fast jedem Volumen stummgeschaltet. Drei Mechanismen halten das Verhältnis gesund.
1. Erst nach Objekt bündeln, dann nach Zeit
Fünf Kommentare zu einem Dokument werden zu „3 Personen haben Onboarding-Plan Q3 kommentiert“, aufklappbar. Eine Zusammenfassung von allem, was während der Abwesenheit passiert ist, schlägt eine Wand aus einzelnen Zeilen, die ungelesen weggeklickt werden. Bündelung ist der wirksamste Hebel, den ein überladener Feed hat.
2. Jeder Kategorie eine eigene Badge-Regel geben
Persönliche Einträge und Workflow-Einträge erhöhen die Zahl. Systemeinträge erhöhen sie nur, wenn der Nutzer etwas tun muss. Produktneuigkeiten bekommen höchstens einen Punkt. Als Tabelle aufgeschrieben ist das eine Entscheidung von fünf Minuten, die die häufigste Form des Feed-Verfalls verhindert.
3. Timing und Kontext des Nutzers respektieren
Benachrichtigungen, die durch eine eigene Aktion des Nutzers entstehen, sollten sofort erscheinen; alles andere kann auf eine natürliche Pause warten. Wenn Sie für dieselben Ereignisse auch E-Mails oder Push senden, unterdrücken Sie das Duplikat, solange der Nutzer im Produkt aktiv ist; dreimal dasselbe auf drei Wegen zu erfahren, macht aus einem nützlichen System ein lästiges. Unser Leitfaden zu Triggern behandelt die allgemeinen Regeln für das Timing von Unterbrechungen im Produkt.
Ein Feed für Produktneuigkeiten funktioniert, wenn er relevant ist und niedrige Priorität hat: ein Punkt, keine rote Zahl.
Einstellungen: die günstigste Retention-Funktion im ganzen System
Fein abgestufte Einstellungen wirken wie ein nettes Extra und verhalten sich wie eine Versicherung. Ein Nutzer, den eine Kategorie stört und der nur zwischen allem und nichts wählen kann, wählt nichts, und damit haben Sie die Freigabe-Benachrichtigungen zusammen mit dem Marketing verloren. Drei Ebenen reichen meist: An/Aus pro Kategorie, eine Kanalwahl pro Kategorie, wo es mehr als einen Kanal gibt, und eine vorübergehende Stummschaltung.
Die Stummschaltungsrate pro Kategorie ist außerdem das ehrlichste Instrument, das Sie je haben werden, um zu beurteilen, ob diese Kategorie existieren sollte. Sie ist keine Vanity-Metrik und hinkt nicht hinterher: Nutzer schalten Dinge in der Woche ab, in der sie genervt sind.
In-App-Benachrichtigungen messen
| Kennzahl | Was sie Ihnen sagt | Worauf Sie achten sollten |
|---|---|---|
| Öffnungsrate des Feeds | Ob der Einstiegspunkt auffindbar ist und dem Badge geglaubt wird | Bleibt allein durch den Druck des Badges hoch, lange nachdem die Qualität der Inhalte eingebrochen ist |
| Klick- / Aktionsrate pro Eintrag | Ob es sich lohnt, auf einzelne Benachrichtigungen zu reagieren | Muss pro Kategorie gelesen werden; eine starke Kategorie verdeckt drei schwache |
| Zeit bis zur Aktion | Ob der Feed tatsächlich Arbeit freigibt | Nur aussagekräftig für Workflow-Einträge, bei denen jemand wartet |
| Stummschaltungs- / Abmelderate | Ob eine Kategorie willkommen ist | Die eine Zahl, die sich nicht schönrechnen lässt; behandeln Sie jeden Anstieg als Urteil |
| Ungeöffnet gelöscht | Ob Nutzer wegklicken statt zu lesen | Ein hoher Wert hier bei gesunder Öffnungsrate heißt: Der Feed ist nur Theater |
Messen Sie all das pro Kategorie statt in Summe, und vergleichen Sie Kategorien miteinander statt mit veröffentlichten Benchmarks anderer Produkte; die Leistung eines Feeds hängt fast vollständig davon ab, was Sie hineingepackt haben, und das macht Vergleiche zwischen Unternehmen bedeutungslos.
Sechs Wege, auf denen Notification Center sterben
- Marketing im Feed. Der schnellste Weg zu einer dauerhaft ignorierten Glocke, und der am schwersten umkehrbare, denn das Vertrauen kommt nicht zurück, wenn die Werbung aufhört.
- Ein Badge, das nie leer wird. Wenn null unerreichbar ist, hören Nutzer auf, es zu versuchen, und das Badge wird zur farbigen Tapete.
- Keine Gruppierung. Ein aktives Dokument, das zwanzig Zeilen erzeugt, macht den Feed für alles andere darin unbrauchbar.
- Links ins Leere. Auf eine Benachrichtigung zu klicken und auf einem Dashboard zu landen, ist in der Interaktion das Gegenstück zu „Finden Sie es selbst heraus“.
- Stilles Als-gelesen-Markieren beim Öffnen. Wird beim Öffnen des Panels alles als gelesen markiert, gehen Einträge endgültig verloren, und Nutzer erleben das so, als würde das Produkt Dinge verstecken.
- Einstellungen nach dem Alles-oder-nichts-Prinzip. Wer eine Kategorie abschalten wollte, schaltet alles ab, auch die Kategorien, die echte Arbeit geleistet haben.
In-App-Benachrichtigungen: Tun und Lassen
✅ Tun
- Nach dem Muster Person, Aktion, Objekt schreiben und das konkrete Objekt nennen
- Die ganze Zeile direkt auf das genaue Ziel verlinken
- Zusammengehörige Ereignisse zu einem aufklappbaren Eintrag gruppieren
- Jeder Kategorie eine eigene Badge-Regel geben
- Einstellungen einen Klick vom Panel entfernt platzieren
- Die Stummschaltungsrate pro Kategorie messen und danach handeln
❌ Lassen
- Werbung in den Benachrichtigungs-Feed stellen
- Ein Zahlen-Badge unwichtige Einträge zählen lassen
- Alles als gelesen markieren, sobald das Panel geöffnet wird
- Dasselbe Ereignis gleichzeitig per E-Mail, Push und Feed senden
- Interne Objektnamen im Text verwenden
- Den Feed nur nach der Öffnungsrate beurteilen
Eine Benachrichtigungsebene ergänzen, ohne sie selbst zu bauen
Ein vollständiges Benachrichtigungssystem (Ereignismodell, Lesestatus, Gruppierung, Einstellungen, Deep Links) ist ein echtes Engineering-Projekt, und es ist die richtige Investition, wenn die Benachrichtigungen aus den Workflows Ihres eigenen Produkts entstehen. Ein großer Teil dessen, wofür Teams die Glocke wollen, ist aber gar kein Workflow: Es geht darum, Nutzern im Produkt zu zeigen, was sich geändert hat, an einem Ort, an dem sie es später wiederfinden.
Dieser Teil braucht kein Engineering-Projekt. Ein In-App-Ankündigungs-Widget liefert Ihnen eine dauerhafte, vom Nutzer abgerufene Liste von Updates, jeweils auf das Segment ausgerichtet, für das ein Update relevant ist, und ohne Release veröffentlicht. Damit ist die Kategorie Produktneuigkeiten sauber abgedeckt und bleibt aus dem Workflow-Badge heraus, wo sie Schaden anrichtet. Kombinieren Sie es mit einem kurzen Walkthrough für alles, was Nutzer lernen müssen, und aus der Ankündigung wird Nutzung.
Zeigen Sie den richtigen Nutzern, was sich geändert hat, dort, wo sie es sehen
Kompassify ergänzt Ihr bestehendes Produkt um ein In-App-Ankündigungs-Widget, gezielte Tooltips und geführte Walkthroughs, damit Produktneuigkeiten das Segment erreichen, für das sie zählen, ohne mit den Benachrichtigungen zu konkurrieren, auf die sich Ihre Nutzer verlassen. Kostenlos bis 100 monatlich aktive Nutzer, Tarife ab 129 $/Monat, DSGVO-konform und in der EU gehostet.
Kostenlos starten →Die Kurzfassung in einem Absatz
In-App-Benachrichtigungen sind adressiert, dauerhaft und werden vom Nutzer abgerufen. Das macht den Feed zu einer wirklich wertvollen und zugleich empfindlichen Fläche. Beschränken Sie ihn auf Dinge, von denen ein bestimmter Nutzer einen Beleg braucht, gruppieren Sie konsequent, lassen Sie nur echte Arbeit ein Zahlen-Badge auslösen, schreiben Sie nach dem Muster Person, Aktion, Objekt mit Deep Link, bieten Sie Einstellungen pro Kategorie an, und beobachten Sie die Stummschaltungsrate statt der Öffnungsrate. Breit ausgespielte Neuigkeiten gehören in eine eigene Ankündigungsfläche, neben die Glocke statt in sie hinein.
Häufig gestellte Fragen
Was sind In-App-Benachrichtigungen?
In-App-Benachrichtigungen sind Nachrichten, die innerhalb eines Produkts an einen bestimmten Nutzer gehen, und zwar über etwas, das passiert ist oder seine Aufmerksamkeit braucht: der Kommentar einer Kollegin, ein fertiger Export, eine wartende Freigabe, eine neue Funktion in dem Bereich, in dem er arbeitet. Sie liegen meist in einem dauerhaften Notification Center, das über ein Glockensymbol erreichbar ist, haben einen Status gelesen oder ungelesen und bleiben verfügbar, bis der Nutzer sich darum kümmert. Diese Dauerhaftigkeit unterscheidet sie von einer breit ausgespielten In-App-Nachricht wie einem Modal oder Banner, die einmal erscheint, unterbricht und wieder verschwindet.
Was ist der Unterschied zwischen In-App-Benachrichtigungen und Push-Benachrichtigungen?
Push-Benachrichtigungen werden vom Betriebssystem an einen Nutzer zugestellt, der gerade nicht in Ihrem Produkt ist, und sie erfordern eine ausdrückliche Erlaubnis, die viele Menschen verweigern. In-App-Benachrichtigungen werden innerhalb Ihrer Oberfläche an einen Nutzer zugestellt, der bereits da ist. Sie brauchen also keine Erlaubnis, lassen sich nicht auf Betriebssystemebene entziehen und können deutlich reichhaltiger sein, erreichen aber nur Menschen, die zurückkommen. In der Praxis ergänzen sie sich: Push holt jemanden zurück, der In-App-Feed zeigt alles, was er in der Zwischenzeit verpasst hat.
Was ist der Unterschied zwischen In-App-Benachrichtigungen und In-App-Nachrichten?
Eine In-App-Nachricht wird breit ausgespielt und unterbricht: ein Modal, Banner, Tooltip oder Slideout, das einem Segment von Nutzern zu einem gewählten Zeitpunkt angezeigt wird, meist um etwas anzukündigen, anzuleiten oder anzustoßen. Eine In-App-Benachrichtigung ist adressiert und dauerhaft: Sie betrifft einen Nutzer, wartet mit Lesestatus in einem Feed, und der Nutzer entscheidet, wann er sie öffnet. Als Faustregel gilt: Alles, worauf der Nutzer später reagieren muss, gehört in den Feed. Alles, was jetzt sofort gesehen werden muss, damit der aktuelle Screen Sinn ergibt, gehört in eine Nachricht.
Was gehört in ein Notification Center?
Vier Kategorien decken fast alles ab: persönliche Benachrichtigungen, wenn jemand mit Ihrer Arbeit etwas tut, Workflow-Benachrichtigungen über etwas, das auf Sie wartet, Systembenachrichtigungen über Jobs und Statusänderungen und Produktneuigkeiten über Funktionen, die für Ihre Arbeit relevant sind. Alles andere ist Marketing mit Glockensymbol. Der Test lautet: Ist der Eintrag an genau diesen Nutzer adressiert, und würde er vernünftigerweise einen Beleg dafür haben wollen? Lautet eine der beiden Antworten Nein, gehört er in eine Nachricht, eine E-Mail oder nirgendwohin.
Wie schreibt man eine Benachrichtigung?
Beginnen Sie mit der handelnden Person und der Aktion, nennen Sie das konkrete Objekt, und machen Sie den gesamten Eintrag zu einem Link genau an die Stelle, an die der Nutzer muss. „Sam hat Ihre Budgetanfrage für Q3 freigegeben“ schlägt „Sie haben eine neue Freigabe“. Bleiben Sie möglichst bei einer Zeile, setzen Sie einen relativen Zeitstempel daneben, und vermeiden Sie Produktjargon, der nur von innen verständlich ist. Jede Benachrichtigung sollte drei Fragen sofort beantworten: Wer hat was getan, mit welchem Objekt, und was passiert, wenn ich klicke?
Wie viele In-App-Benachrichtigungen sind zu viele?
Entscheidend ist nicht die Menge pro Tag, sondern die Menge pro Einheit Nutzen. Ein Feed, in dem sich die meisten Einträge lohnen, verträgt ein hohes Volumen; ein Feed, in dem drei von vier Einträgen Rauschen sind, wird bei fast jedem Volumen stummgeschaltet. Bündeln Sie zusammengehörige Ereignisse zu einem Eintrag, statt fünf zu senden, gruppieren Sie nach Objekt oder nach Tag, und legen Sie streng fest, welche Kategorien das Badge auslösen dürfen. Steigt die Stummschaltungsrate einer Kategorie, ist genau diese Kategorie die Antwort auf die Frage.
Sollte ein Benachrichtigungs-Badge eine Zahl anzeigen?
Zeigen Sie eine Zahl nur für Einträge, die wirklich einzeln Aufmerksamkeit brauchen, und verwenden Sie für alles andere einen einfachen Punkt. Ein Zahlen-Badge verspricht, dass es genau so viele einzelne Dinge zu erledigen gibt. Wird die Zahl durch unwichtige Einträge aufgebläht, lernen Nutzer, dass sich das Abarbeiten nicht lohnt, und ignorieren sie dauerhaft. Ein Badge, das nie auf null fällt, ist kein Signal mehr, sondern Dekoration.
Welche Kennzahlen sollte man für In-App-Benachrichtigungen messen?
Messen Sie vier Dinge pro Kategorie statt in Summe: die Öffnungsrate des Feeds selbst, die Klick- oder Aktionsrate einzelner Einträge, die Zeit von der Zustellung bis zur Aktion und die Stummschaltungs- oder Abmelderate. Die letzte ist der ehrliche Maßstab dafür, ob eine Kategorie willkommen ist. Die Klickrate kann respektabel bleiben, bis Nutzer das Ganze abschalten. Vergleichen Sie Kategorien miteinander statt mit externen Benchmarks, denn die Leistung eines Feeds hängt fast vollständig davon ab, was Sie hineinpacken.