In-App-Messaging ist einer der wirkungsvollsten Wege, Nutzer direkt in Ihrer App zu erreichen. Die Standardlösung war bisher immer der klassische HTML-In-App-Editor: stark bei individuellen, komplexen Designs, aber zu schwerfällig für die schnellen Tests und Hypothesen, die ein Marketing-Team im Tagesgeschäft braucht.
Jetzt geben native In-App-Nachrichten Marketing-Teams volle Autonomie. Sie wählen ein fertiges Layout direkt im Editor, personalisieren es und starten in wenigen Minuten — ganz ohne Designer oder Entwicklerteam.
Die Personalisierung läuft dabei über dieselbe Infrastruktur, die Pushwoosh für den gesamten Cross-Channel-Stack einsetzt: SOC 2 Type II und ISO 27001:2022 zertifiziert, mit Rechenzentren in der EU. Gerätetags und Nutzerattribute, die Sie in ein natives In-App-Layout einsetzen, verlassen also nicht den Rechtsrahmen, den Sie für Ihre App vorgeben.
Dieser Leitfaden zeigt, was native In-Apps sind, wie Sie sie personalisieren und wie Sie das richtige Layout für Onboarding, Conversion, Winback oder Retention auswählen.
📖 Neu im Kanal? Starten Sie mit was In-App-Nachrichten sind und warum sie funktionieren.
Was ist eine native In-App-Nachricht?
Es gibt 2 Wege, eine In-App-Nachricht zu bauen.
Ein klassisches HTML-In-App ist eine individuelle Webseite, die das SDK als Overlay über Ihrer nativen UI anzeigt — mit voller Designkontrolle und Web-Rendering. Die richtige Wahl, wenn Sie etwas brauchen, das die fertigen Layouts nicht abdecken: ein Feedback- oder Umfrageformular, interaktive Individualinhalte oder ein komplett eigenes Design, das Sie als ZIP hochladen.
Ein natives In-App funktioniert anders: Das SDK zeichnet es mit den nativen Komponenten der Plattform aus einem fertigen Layout, das Sie im Editor befüllen — kein HTML, keine WebView. Es öffnet schneller, animiert flüssiger und wirkt wie ein Teil der App selbst.
7 native In-App-Typen und wann Sie welchen einsetzen
Pushwoosh stellt Ihnen 7 native Layouts direkt im In-App-Editor bereit. Doch woran erkennen Sie, welches Sie brauchen?
Die Wahl des Layouts ist im Kern eine Frage der Unterbrechung: Wie viel Bildschirmfläche und wie viel Aufmerksamkeit verdient diese Nachricht gerade? Beantworten Sie das zuerst, dann wählt sich das Layout von selbst.
- Nicht unterbrechen: Banner. Eine kompakte Leiste oben oder unten. Der Nutzer macht weiter, weswegen er da ist; die Nachricht ist einfach präsent. Geeignet für Hinweise, die einen Tap oder zwei warten können: ein unvollendeter Schritt, ein neues Feature, eine kleine Belohnung.
- Kurz unterbrechen: Sheet. Ein Panel gleitet von unten hoch, mit einem Handle zum Wegziehen. Es sagt: „noch eine Sache zu dem, was Sie sich gerade ansehen.” Kontextuelle Aktionen innerhalb einer Session gehören hierher: dieses Element speichern, diese Einstellung aktivieren, diese Auswahl bestätigen.
- Kurz stoppen: Modal. Eine zentrierte Karte über einem abgedunkelten Bildschirm. Sie stoppt den Nutzer, aber nur für eine Entscheidung. Angebote, Updates und Ja/Nein-Momente.
- Den ganzen Bildschirm nehmen: Vollbild, Stories, Karussell, Video. Für Momente, in denen der Nutzer bereit ist, innezuhalten. Onboarding, eine große Promo, eine Produkt-Tour. Setzen Sie sie ein, wenn der Mehrwert eine volle Pause rechtfertigt — nicht, weil das Layout im Editor beeindruckend aussieht.
Die Stufenleiter sagt Ihnen, wie viel Bildschirm angemessen ist. Jetzt zu jedem Layout im Detail: was es ist, wann es passt, in welcher Lifecycle-Phase, und welche KPI Sie beobachten sollten.
| Layout | Was es ist | Bester Moment | Lifecycle-Phase | Zu beobachtende KPI |
|---|---|---|---|---|
| Banner | Kompakte Leiste, oben oder unten, nicht blockierend | Ein Hinweis, der die Session nicht unterbrechen soll | Engagement, Retention | CTR |
| Sheet | Bottom-Panel mit Drag-Handle | Eine kontextuelle Aktion auf dem aktuellen Bildschirm | Engagement, Conversion | Interaktionsrate, Journey-Ziel |
| Modal | Zentrierte Karte über abgedunkeltem Hintergrund | Ein Angebot oder Update, das eine Entscheidung braucht | Conversion, Winback | CTR, Journey-Ziel |
| Vollbild | Randloses Coverbild mit Text und Buttons | Onboarding, eine große Promo | Onboarding, Conversion | Journey-Ziel (Aktivierung, Kauf) |
| Stories | Sequenzielle Vollbild-Slides mit Fortschrittsbalken | Eine Abfolge von Schritten oder Features | Onboarding, Feature-Adoption | Interaktionen, Journey-Ziel (Feature genutzt) |
| Karussell | Vollflächige, wischbare Karten mit Paginierungspunkten | Eine Auswahl oder ein Katalog | Engagement, Conversion | CTR zum Produkt, Journey-Ziel |
| Video | Vollbild-HLS- oder MP4-Player mit Overlay-Text und Buttons | Eine Produkt- oder Feature-Demo | Onboarding, Conversion | Interaktionen mit dem Overlay-Button, Journey-Ziel |
Personalisieren Sie Ihre In-App-Nachricht
Ein natives Layout ist nur die halbe Miete. Die andere Hälfte: Jedes Feld darin lässt sich pro Nutzer verändern.
3 Personalisierungstechniken decken das meiste ab, was ein Marketer braucht:
Dynamische Inhalte. Ziehen Sie jedes Nutzerattribut in den Text — Vorname, Tarif, Stadt, zuletzt gekaufte Kategorie — mit Format-Modifikatoren für ein sauberes Ergebnis, dann Liquid für die bedingte Logik: ein Angebot für Test-Nutzer, ein anderes für Abonnenten, den CTA nach Segment tauschen. Da diese Attribute aus Ihrer Nutzerdatenbank stammen, bleiben sie innerhalb der EU-Infrastruktur von Pushwoosh — relevant, sobald Gerätetags personenbezogene Daten enthalten.
Lokalisierung. Ein natives In-App startet in 1 Sprache. Fügen Sie weitere hinzu, und Pushwoosh kopiert die Standardinhalte — Text, Bilder und Button-Beschriftungen — in jede neue Sprache zur Übersetzung. Jeder Nutzer sieht dann die Version, die zu seiner Gerätesprache passt — eine Nachricht, einmal gebaut, spricht jede Zielgruppe in ihrer Sprache.
Barcode- und QR-Generator. Der native Editor erzeugt Barcodes oder QR-Codes und kann den Wert aus einem Gerätetag im Format {Coupon|String|} ziehen. Jeder Nutzer erhält seinen eigenen scanbaren Code, gerendert direkt auf dem Gerät — nichts zu hosten, kein Bild extern zu erzeugen, und keine Coupon-Daten, die Ihre EU-Infrastruktur verlassen.
Native In-Apps in der Praxis: Use Cases & Beispiele
So sieht das in echten Apps aus. Jeder Fall startet mit einem Problem, das Sie vermutlich aus Ihrem eigenen Funnel kennen, nennt das passende Layout und führt durch den Aufbau in Pushwoosh.
👋 Onboarding: Nutzer mit Vollbild oder Stories willkommen heißen
Das Problem: Ein neuer Nutzer öffnet die App zum ersten Mal und muss den Mehrwert allein herausfinden. Die meisten ersten Sessions enden, ohne dass er ihn findet.
Die Lösung: Vollbild beansprucht den ersten Screen für ein klares Willkommen und eine einzige Aktion. Stories führt durch die Kernfunktionen als antippbare Slides, mit Fortschrittsbalken, die zeigen, wie viel noch kommt.
In Pushwoosh: Lösen Sie beim ersten app_open ein Vollbild mit dem Hauptnutzen und einem CTA aus. Folgen Sie mit einer Stories-Nachricht — ein Slide pro Kernfeature — um die erste Nutzung zu treiben.
📖 Mehr dazu: Willkommens-In-App-Nachrichten.
💸 Winback: ein Modal mit scanbarem Coupon
Das Problem: Ein inaktiver Käufer braucht einen echten Grund zurückzukommen, nicht nur ein „Wir vermissen Sie”.
Die Lösung: Ein natives In-App-Template als Klick-Aktion des Push gesetzt, sodass der Tap ein Modal mit einem persönlichen QR-Code aus dem Gerätetag {Coupon|String|} öffnet.
In Pushwoosh: Segmentieren Sie Käufer, die 21+ Tage inaktiv sind, und zeigen Sie ein Modal mit ihrem persönlichen Code — scanbar an der Kasse, kein Bild von Drittanbietern nötig.
📖 Vollständige Aufschlüsselung scanbarer Coupon-Flows: Coupon-Marketing für Mobile Apps.
🛍️ In-Session: ein Karussell, das wie ein Katalog funktioniert
Das Problem: Ein einziges statisches Angebot trifft selten das, was ein bestimmter Shopper tatsächlich sucht.
Die Lösung: Das Karussell-Layout — vollflächige, wischbare Karten —, bei dem Liquid Kategoriename und Text aus der zuletzt angesehenen Kategorie des Nutzers zieht. Dasselbe Muster funktioniert branchenübergreifend: im E-Commerce für Produktkategorien, im Automotive-Bereich ebenso gut für zuletzt angesehene Ersatzteile oder Zubehör.
In Pushwoosh: Lösen Sie bei einem Kategorie-View-Event aus, zeigen Sie ein 4-Karten-Karussell: „Für Sie ausgewählt in {LastCategory}”, jede Karte mit Produktbild, Preis und einem Button zur Produktseite.
💳 Retention-Hinweis: ein Banner, der nicht unterbricht
Das Problem: Eine Investment- oder Budgeting-App hat Nutzer, die sich registriert, ein Konto verknüpft und die Verifizierung nie abgeschlossen haben — eine Anforderung, die viele deutsche FinTech-Apps ohnehin aus regulatorischen Gründen (BaFin, Geldwäscheprävention) durchsetzen müssen. Ein Modal bei jedem Öffnen trainiert Nutzer nur darauf, Modals wegzuklicken.
Die Lösung: Das Banner-Layout, unten fixiert, auf jedem Screen sichtbar bis der Schritt erledigt ist, wegwischbar ohne die Session zu verlieren.
In Pushwoosh: Zeigen Sie bei unvollendeter Verifizierung oder ungenutztem Feature ein Banner — „Verifizierung abschließen, um Überweisungen freizuschalten” — ein Tap, null Unterbrechung.
Bauen Sie Ihre 1. native In-App in 5 Schritten
Der vollständige Weg vom Template zur Live-Nachricht im Customer Journey Builder:
-
Layout nach Unterbrechungsgrad wählen
Entscheiden Sie, wie viel Bildschirm die Nachricht verdient, dann wählen Sie den Anzeigetyp.
-
Im nativen Editor bauen
Inhalte → In-Apps → In-App erstellen → Native Rich Media erstellen. Felder sind gruppiert in Content (Text, Bilder aus einer URL oder dem Media Storage), Config (Farben, Hintergrund, Verhalten) und Actions (Buttons und deren Aktion). Der Schritt-für-Schritt-Guide deckt jedes Feld ab.
-
Tags und Liquid hinzufügen
Fügen Sie Name, Segment, Angebot oder einen Coupon-Code ein, damit jeder Nutzer seine eigene Version sieht.
-
Live-Vorschau prüfen
Der Editor rendert die Nachricht so, wie sie auf dem Gerät erscheint. Prüfen Sie sie hier, bevor sie live geht.
-
Live schalten
Legen Sie Trigger und Zielgruppe fest, platzieren Sie den In-App-Knoten im Flow, und gehen Sie live.
🚨 Die Fehler, die native In-Apps still und leise kaputt machen:
- Auf einem alten SDK ausliefern. Sheet, Karussell und Banner brauchen iOS 7.2.1+ / Android 6.10.1+; Video braucht Android 6.11.0+. Unterhalb des Minimums erscheint nichts.
- In HTML denken. Native ist keine WebView. Sie bauen aus Blocks und gestalten für das Layout, nicht für eine Seite.
- Ohne Vorschau live gehen. Die Live-Vorschau existiert, damit ein kaputtes Rendering nie einen Nutzer erreicht. Nutzen Sie sie jedes Mal.
Binden Sie Nutzer in-session mit nativen Pushwoosh-In-Apps
Native In-App-Nachrichten geben Ihnen 7 fertige Layouts, Personalisierung pro Nutzer in jedem davon, und eine Live-Vorschau, die Probleme abfängt, bevor sie live gehen — kein HTML, kein Design-Flaschenhals, alles auf EU-Infrastruktur mit ISO-27001-Zertifizierung. Wählen Sie den Moment, der für Ihre App am wichtigsten ist: einen Onboarding-Schritt, ein Winback, einen Mid-Session-Hinweis — und bauen Sie die In-App dahinter.
