Push Benachrichtigungen, die Nutzer wirklich öffnen: Wie wir 0,6 % bei MediaMarktSaturn angegangen sind
0,6 % Öffnungsrate bei 2,7 Mio. Push Nachrichten bei MediaMarktSaturn. Das JITAI-Framework aus der Gesundheitsforschung hat verändert, wie wir über Push Benachrichtigungen nachdenken.
Basierend auf meinem Vortrag bei Flutter Berlin (Flutter OctoberFest). Setzt Mobile-Development-Erfahrung voraus. Kein ML- oder Data-Science-Hintergrund nötig.
📺 Den ganzen Vortrag auf YouTube ansehen
TL;DR: Kampagnen-Push-Benachrichtigungen bei MediaMarktSaturn hatten eine Öffnungsrate von 0,6 % bei 2,7 Millionen Sends. Das Problem war nicht der Inhalt — es waren Timing, Relevanz und Volumen. Wir haben ein Framework namens Just-In-Time Adaptive Interventions (JITAI) gefunden, ursprünglich aus der medizinischen Gesundheitsforschung, und ein System entworfen, das für jeden Nutzer entscheidet, ob, wann und was gesendet wird. Das System war noch in der Discovery-Phase, als ich den Vortrag gehalten habe, aber das Denken dahinter gilt für jede App, die um Nutzer-Aufmerksamkeit kämpft.
Die Zahlen, die alles ins Rollen gebracht haben
Bei MediaMarktSaturn habe ich im Consumer-Apps-Team gearbeitet — eines der größeren Flutter-Teams in Deutschland. Wir haben Apps in 13 Ländern betreut. Im Quartal davor hatten wir einen Push-Notification-Service ausgeliefert.
So sah eine schlechte Kampagne aus:
| Metrik | Zahl |
|---|---|
| Push Nachrichten gesendet | 2.700.000 |
| Geöffnet | ~17.000 (0,6 %) |
| Konvertiert (von Öffnungen) | 66 (0,36 %) |
Das sind 66 Käufe aus 2,7 Millionen Unterbrechungen. Nicht 66 Tausend. Sechsundsechzig.
Das war nicht mal unsere schlechteste Kampagne. Aber sie machte die Frage unausweichlich: Bieten wir unseren Nutzern Mehrwert, oder machen wir einfach nur Lärm?
Warum Push Benachrichtigungen scheitern
Wir sind immer wieder auf vier Probleme zurückgekommen:
Timing. Schickt man eine Push Nachricht, während jemand im Meeting oder in der Bahn sitzt, ist es einfach nur eine Störung. Jeder Nutzer hat unterschiedliche Aufmerksamkeitsfenster über den Tag.
Relevanz. Eine Aktion für Küchengeräte ist nützlich für jemanden, der gerade eine neue Wohnung einrichtet. Für alle anderen ist es Ballast. Batch-Kampagnen unterscheiden nicht zwischen den beiden.
Volumen. Zu viele Push Benachrichtigungen und Nutzer werden taub. Oder sie widerrufen die Benachrichtigungs-Berechtigung komplett. Wenn das passiert, ist der Kanal tot.
Konkurrenz. Der durchschnittliche Nutzer hat rund 50 Apps installiert. Jede will ein Stück eines begrenzten Aufmerksamkeitsbudgets. Wenn deine Push Nachricht ihren Platz nicht verdient, wird sie weggewischt.
Alle vier Probleme laufen auf dasselbe hinaus: Rezeptivität — die Fähigkeit und Bereitschaft des Nutzers, genau jetzt eine Unterbrechung zu empfangen und darauf zu reagieren.
Was Rezeptivität wirklich bedeutet
Rezeptivität ist kein Schalter. Sie verschiebt sich über den Tag basierend auf zwei Arten von Signalen:
- Intern: Stimmung, kognitive Belastung, worauf der Nutzer gerade fokussiert ist
- Extern: Standort, Tageszeit, ob er fährt, läuft oder sitzt
Die Idee ist einfach: Wenn jemand nicht in der Lage ist, sich für deine Nachricht zu interessieren, bringt das Senden im besten Fall nichts und nervt im schlimmsten Fall. Push Nachrichten an nicht-rezeptive Nutzer oft genug senden, und sie werden sich abmelden.
Unsere These: Wenn wir Push Benachrichtigungen besser timen und personalisieren, werden Nutzer sie als nützlich statt nervend wahrnehmen. Nützliche Benachrichtigungen werden geöffnet. Geöffnete Benachrichtigungen konvertieren.
Was ist JITAI? Ein Framework aus der Gesundheitsforschung
Just-In-Time Adaptive Interventions (JITAI) kommt aus der medizinischen Gesundheitsforschung, konkret aus Suchtunterstützung und Abnehm-Apps. Diese Systeme überwachen den internen und externen Zustand eines Nutzers und greifen nur ein, wenn zwei Bedingungen erfüllt sind:
- Der Nutzer ist in einem vulnerablen Zustand (in einer Gesundheits-App: Rückfallgefahr; bei uns: profitiert wahrscheinlich von einer Produktbenachrichtigung)
- Der Nutzer ist in einem rezeptiven Zustand (fähig und bereit, die Nachricht gerade zu verarbeiten)
Das Framework hat vier Teile:
1. Entscheidungspunkte
Der Moment, in dem das System entscheidet, ob eine Push Benachrichtigung angezeigt wird. Bei server-gesendeten Push Nachrichten ist das der Zeitpunkt, zu dem der Server normalerweise feuern würde. Bei lokalen On-Device-Benachrichtigungen kann man Intervalle setzen und alle X Minuten prüfen, ob die Bedingungen stimmen.
Der wichtige Punkt: Die Entscheidung ist nicht nur „senden”. Sie lautet „senden, verzögern oder gar nicht senden”.
2. Tailoring-Variablen
Die Daten, die in die Entscheidung einfließen. Zwei Quellen:
Passiv (keine Nutzeraktion nötig):
- Gerätetyp (Android- und iOS-Nutzer haben oft unterschiedliche Benachrichtigungsgewohnheiten)
- Standort (Ist der Nutzer in der Nähe einer Filiale?)
- Zeitmuster (Wann öffnet dieser Nutzer typischerweise die App?)
- Sensordaten (Beschleunigungssensor, Umgebungslicht, mit Zustimmung)
Aktiv (Nutzer teilt direkt mit):
- Wunschlisten-Artikel
- Suchverlauf
- Kategorie-Präferenzen
Das System muss mit dem arbeiten, was der Nutzer bereit ist zu teilen. Jemand, der nur Standortzugriff gewährt, sollte trotzdem eine spürbar bessere Erfahrung bekommen als eine Batch-Kampagne.
3. Interventionsoptionen
Was das System tatsächlich tun kann:
| Aktion | Beispiel |
|---|---|
| Informations-Benachrichtigung | Neuheiten, Nachlieferungen |
| Werbe-Benachrichtigung | Sales, Rabatte |
| Standortbasierte Benachrichtigung | Filialspezifische Angebote in der Nähe |
| Rich Push | Bildlastige, interaktive Push Nachrichten |
| Verschieben | Benachrichtigung auf besseren Zeitpunkt verzögern |
| Kein Push | Benachrichtigung komplett unterdrücken |
Die letzte Zeile ist die wichtigste. Manchmal ist die beste Push Nachricht keine.
4. Der Entscheider
Das ist der Kern. Er nimmt die Tailoring-Variablen und Interventionsoptionen und entscheidet, welche Intervention wem und wann angeboten wird.
Zwei Ansätze:
Algorithmisch: Entscheidungsbäume und Regeln. Einfacher zu bauen, testen und erklären. Beispiel: Wenn der Nutzer innerhalb von 500 m einer Filiale ist UND ein Wunschlisten-Artikel in dieser Filiale im Angebot ist, sende einen standortbasierten Push.
Machine Learning: Ein On-Device Reinforcement-Learning-Modell, das aus den Interaktionsmustern jedes Nutzers lernt. Das Modell verbessert sich pro Nutzer über die Zeit, ohne Daten zwischen Geräten zu teilen. Schwieriger zu bauen und zu testen, aber es kann Muster erkennen, die Regeln übersehen.
In der Praxis: Man startet mit Regeln und ergänzt ML dort, wo die Regeln aufhören, sich zu verbessern.
Zwei praktische Beispiele
Der Vorbeilauf am Store
Du gehst über den Alexanderplatz. Deine Saturn-App kennt deine Wunschliste, und du hast ein Paar Kopfhörer im Auge. Im Hintergrund prüft das System: Hat der Saturn am Alexanderplatz diese Kopfhörer vorrätig? Gibt es eine laufende Aktion?
Wenn ja, sende einen Push. Du wolltest das Produkt bereits. Der Store ist 200 Meter entfernt. Die Aktion gibt dir einen Grund, jetzt reinzugehen.
Du erfährst von einem Deal für etwas, das du schon wolltest. Der Store bekommt einen Walk-in. Eine Push Nachricht, kein Spam.
Distales Ergebnis: Kauf in der Filiale. Proximales Ergebnis: Nutzer nimmt den Deal wahr. Selbst wenn er die Benachrichtigung nicht antippt, hat er die Information aufgenommen.
Der abgebrochene Warenkorb
Du bist zu Hause, browst durch die MediaMarkt-App. Du legst drei Artikel in den Warenkorb. Dein Partner kommt rein, du legst das Handy weg, und der Warenkorb bleibt einfach liegen.
Das System erkennt, dass der Warenkorb seit ein paar Stunden inaktiv ist. Einer der Artikel hat jetzt 20 % Rabatt, der bald ausläuft. Du hast den Warenkorb wahrscheinlich vergessen, und vom Preisverfall weißt du definitiv nichts.
Sende eine Push Benachrichtigung über den Rabatt. Du bekommst eine nützliche Erinnerung. Der Händler rettet einen Verkauf, der leise verschwunden wäre.
Beide Beispiele folgen derselben Logik: Unterbreche jemanden nur, wenn du vernünftig sicher bist, dass die Benachrichtigung seine Aufmerksamkeit wert ist.
Die schwierigen Teile
Datenschutz und DSGVO
Wir sind in Deutschland. Die DSGVO ist keine Formalität — sie ist die Betriebsumgebung. Das System berührt sensible Daten: Standort, Kaufhistorie, Browserverlauf. Der Deal mit den Nutzern muss klar sein: Diese Daten verbessern deine Benachrichtigungserfahrung, Punkt. Sie werden nie verkauft oder geteilt.
Wenn Nutzer dem System nicht vertrauen, werden sie die nötigen Berechtigungen nicht erteilen. Und dann gibt es nichts, womit man arbeiten kann.
Tailoring-Variablen testen
Welche Variablen sagen Rezeptivität tatsächlich vorher? Gerätetyp? Tageszeit? Entfernung zum Store? Eine Kombination? Das braucht ernsthaftes A/B-Testing und sorgfältige Messung. Der Suchraum ist groß, und Bauchgefühle darüber, was wichtig ist, liegen meistens daneben.
Unvollständige Daten
Das System muss funktionieren, wenn Nutzer nur einige oder gar keine Berechtigungen erteilen. Jemand, der Standort, Wunschliste und Browserverlauf teilt, gibt dem Entscheider reichlich Signal. Jemand, der nichts teilt, bekommt die Batch-Erfahrung — wie vorher, keine Nachteile.
Dieses Qualitätsgefälle ist systembedingt, und das ist okay. Aber es muss ehrlich gemessen werden, nicht im Dashboard schöngerechnet.
Wo wir aufgehört haben
Als ich diesen Vortrag bei Flutter Berlin gehalten habe, war das System in der Discovery-Phase. Wir hatten Research, Architektur und einen Vortrag — aber noch keinen Produktionscode. Die akademische Literatur zu JITAI ist solide, aber die Anwendung auf E-Commerce-Push-Benachrichtigungen im großen Maßstab, über 13 Länder und Millionen Nutzer, wirft Probleme auf, die die Papers nicht behandeln.
Was mir immer wieder durch den Kopf geht: Das Problem mit Push Benachrichtigungen sind nicht Push Benachrichtigungen. Es ist das Senden der falschen Nachricht zum falschen Zeitpunkt. Und ehrlich gesagt: die fehlende Disziplin, gar nichts zu senden, wenn man keinen guten Grund hat.
Die meisten Apps behandeln Push Nachrichten immer noch als Broadcast-Kanal. Die Messlatte, um aufzufallen, ist niedrig: Hört einfach auf, Leute anzuschreien, die nicht gefragt haben.
Danke an Flutter Berlin und MediaMarktSaturn für das Event.
Wenn du eine mobile App baust, die smartere Push Benachrichtigungen braucht — oder das bestehende System überdenken willst — genau solche Architekturarbeit mache ich.
Die wichtigsten Erkenntnisse
- Öffnungsraten bei Push Benachrichtigungen sind ein Symptom, nicht die Krankheit. Das echte Problem ist die falsche Nachricht zur falschen Zeit an den falschen Nutzer.
- Das JITAI-Framework gibt Personalisierung Struktur. Entscheidungspunkte, Tailoring-Variablen, Interventionsoptionen und ein Entscheider — vier Komponenten, die „smartere Push Nachrichten senden” in ein Engineering-Problem verwandeln.
- Starte mit Regeln, ergänze ML später. Algorithmische Entscheidungsbäume sind einfacher zu bauen, testen und erklären. Machine Learning erkennt Muster, die Regeln übersehen — aber erst nachdem du verstehst, wie „besser” aussieht.
- Die beste Push Benachrichtigung ist manchmal keine. Das Unterdrücken eines Low-Value-Pushes bewahrt das Vertrauen des Nutzers und hält den Kanal am Leben für den Moment, in dem es zählt.
Verwandte Beiträge
- WebView in App einbetten — Warum es komplizierter ist, als du denkst — die versteckte Komplexität hinter WebViews in mobilen Apps
- WebView-App: Payment Flows, State Sync und Plattform-Hacks (Teil 2) — wo die WebView-Integration richtig unübersichtlich wird
- Fix: Flutter WebView Tap-Gesten funktionieren nicht mehr nach Scrollen in NestedScrollView (iOS) — ein Plattform-Bug, den wir in Produktion lösen mussten
- Das Phoenix Pattern in Flutter: App neu starten, ohne sie neu zu starten — ein Pattern für erzwungene App-Neustarts ohne den Prozess zu beenden
Weiterführende Literatur
- Nahum-Shani et al. — „Just-in-Time Adaptive Interventions (JITAIs) in Mobile Health” — das grundlegende JITAI-Paper
- Hardeman et al. — „Developing and testing a digital intervention for health behavior change” — adaptive Interventionen in der Praxis anwenden
- Firebase Cloud Messaging Dokumentation — Push-Notification-Infrastruktur, die die meisten Flutter-Apps nutzen
- DSGVO und Push Benachrichtigungen — EU-Verordnungen zu Nutzerdaten bei Notification-Targeting