Häufig gestellte Fragen

Dieser Artikel enthält Antworten auf einige häufig gestellte Fragen zu In-App-Nachrichten.

Was ist eine In-Browser-Nachricht und wie unterscheidet sie sich von einer In-App-Nachricht?

In-Browser-Nachrichten sind In-App-Nachrichten, die an Webbrowser gesendet werden. Um eine In-Browser-Nachricht zu erstellen, wählen Sie beim Erstellen Ihrer In-App-Nachricht-Campaign oder Ihres Canvas im Feld Senden an die Option Web Browser aus.

Wird eine In-App-Nachricht angezeigt, wenn ein Gerät offline ist?

Das kommt darauf an. Da In-App-Nachrichten zu Beginn der Sitzung zugestellt werden, kann das Gerät die Payload herunterladen, bevor es offline geht. In diesem Fall kann die In-App-Nachricht auch offline angezeigt werden. Wurde die Payload nicht heruntergeladen, wird die In-App-Nachricht nicht angezeigt.

Wenn Nutzer:innen bereits eine In-App-Nachrichten-Payload auf ihrem Gerät haben und das Ablaufdatum der Nachricht geändert wird, wird das Ablaufdatum auf ihrem Gerät aktualisiert?

Wenn Nutzer:innen eine Sitzung starten, prüft Braze, ob Änderungen an In-App-Nachrichten vorgenommen wurden, für die sie berechtigt sind, und aktualisiert diese entsprechend. Wenn sich also das Ablaufdatum geändert hat und sie eine Sitzung protokollieren, wird die In-App-Nachricht mit den aktualisierten Informationen an das Gerät gesendet.

Wie richte ich Ruhezeiten für eine In-App-Nachricht-Campaign ein?

Das Feature „Ruhezeiten“ ist für In-App-Nachricht-Campaigns nicht verfügbar. Dieses Feature wird verwendet, um zu verhindern, dass Nachrichten während bestimmter Stunden an Ihre Nutzer:innen gesendet werden. Bei In-App-Nachricht-Campaigns erhalten Ihre Nutzer:innen In-App-Nachrichten nur dann, wenn sie in der App aktiv sind.

Als Workaround zum Senden von In-App-Nachrichten während eines bestimmten Zeitraums können Sie den folgenden Liquid-Beispielcode verwenden. Dieser ermöglicht es, die Nachricht abzubrechen, wenn die In-App-Nachricht nach 19:59 Uhr oder vor 8:00 Uhr in der angegebenen Zeitzone angezeigt wird.

1
2
3
4
5

{% assign time = 'now' | time_zone: ${time_zone} %}{% assign hour = time | date: '%H' | plus: 0 %}
{% if hour > 19 or hour < 8 %}
{% abort_message("Outside allowed time window") %}
{% endif %}
MESSAGE HERE

Können Nutzer:innen eine In-App-Nachricht erneut erhalten, nachdem sie sie geschlossen haben?

Campaigns

Bei In-App-Nachricht-Campaigns können Sie Nutzer:innen erlauben, erneut für den Empfang der Campaign berechtigt zu werden, indem Sie die Wiederberechtigung unter Zustellungskontrollen aktivieren (Nutzer:innen erlauben, erneut für den Empfang der Campaign berechtigt zu werden). Wie schnell sie die Nachricht erneut erhalten können, hängt vom eingestellten Wiederberechtigungszeitraum und davon ab, wie Braze den vorherigen Versand erfasst hat. Weitere Informationen zum Campaign-Verhalten, einschließlich des Zusammenhangs zwischen Wiederberechtigung und Nachrichtenempfang, finden Sie unter Wiederberechtigung für Campaigns und Canvas.

Wenn die Wiederberechtigung deaktiviert ist, erhalten Nutzer:innen dieselbe Campaign in der Regel nicht erneut, allein basierend auf den Qualifizierungskriterien, nachdem sie sie bereits erhalten haben.

Canvases

Bei In-App-Nachrichten, die aus einem Canvas gesendet werden, hängt es davon ab, ob Nutzer:innen die Nachricht erneut sehen können, von den Canvas-Eintrittskontrollen (z. B. ob Nutzer:innen erneut in den Canvas eintreten dürfen) und Ihrer Schritt-Konfiguration – nicht nur von den Campaign-Zustellungskontrollen.

Wann wird die Berechtigung für eine In-App-Nachricht berechnet?

Die Berechtigung für eine In-App-Nachricht wird zum Zeitpunkt der Zustellung berechnet. Wenn eine In-App-Nachricht für 7 Uhr morgens geplant ist, wird die Berechtigung für diese In-App-Nachricht um 7 Uhr morgens geprüft.

Wenn die In-App-Nachricht angezeigt wird, hängt die Berechtigung davon ab, wann die In-App-Nachricht heruntergeladen und getriggert wurde.

Warum liefert meine archivierte In-App-Nachrichten-Campaign weiterhin In-App-Nachrichten-Impressionen?

Dies kann bei Nutzer:innen auftreten, die die Segmentkriterien erfüllt haben, als die In-App-Nachrichten-Campaign noch aktiv war.

Um dies zu verhindern, wählen Sie während der Campaign-Einrichtung Re-evaluate campaign eligibility before displaying aus.

Warum sehe ich keine Öffnungen für In-App-Nachrichten?

In-App-Nachrichten verwenden keine Metrik für Öffnungen. Braze protokolliert Impressionen, wenn die Nachricht auf dem Bildschirm sichtbar wird, und Klicks, wenn Nutzer:innen mit dem Nachrichtentext oder den Buttons interagieren. Wenn ein Mehrkanalexport oder -bericht Zeilen mit In-App-Nachrichten enthält, vergleichen Sie Impressionen und Klicks anstelle von E-Mail-typischen Öffnungen. Definitionen finden Sie unter In-App-Nachrichten-Reporting.

Können mehrere In-App-Nachrichten in derselben Sitzung angezeigt werden?

Ja, aber pro Auftreten eines Trigger-Events kann nur eine In-App-Nachricht angezeigt werden. Wenn mehrere In-App-Nachricht-Campaigns denselben Trigger teilen (z. B. Sitzungsstart), wird jedes Mal, wenn dieser Trigger ausgelöst wird, nur die Nachricht mit der höchsten Priorität angezeigt. Bei Sitzungsstart-Triggern bedeutet dies, dass pro Sitzung nur eine Nachricht angezeigt werden kann und die nächste Gelegenheit, eine weitere berechtigte Nachricht anzuzeigen, die nächste Sitzung ist.

Wenn mehrere Nachrichten dieselbe Prioritätsstufe haben, wird die zuletzt erstellte Nachricht zuerst angezeigt. Bei Sitzungsstart-Triggern wird die nächstaktuellste Nachricht in einer nachfolgenden Sitzung angezeigt; bei anderen Trigger-Typen wird die nächstaktuellste Nachricht beim nächsten Auftreten dieses Trigger-Events angezeigt, was innerhalb derselben Sitzung oder in einer späteren Sitzung sein kann.

Um die Anzeigereihenfolge innerhalb einer Prioritätsstufe zu steuern, gehen Sie zu den Zustellungseinstellungen einer der Campaigns und wählen Sie Set exact priority aus. Ziehen Sie die Campaigns dann per Drag-and-drop in die gewünschte Reihenfolge. Weitere Informationen finden Sie unter Priorität wählen.

Wie werden Impressionen und Klicks von In-App-Nachrichten protokolliert?

Unter In-App-Nachrichten-Reporting erfahren Sie, wie Impressionen und Klicks nach Nutzer:innen-Aktion protokolliert werden. Beispiele speziell für Vollbild-Nachrichten, die mit dem traditionellen Editor erstellt wurden, finden Sie unter Vollbild-Nachrichten-Metriken nach Nutzer:innen-Aktion.

Wie berechnet Braze den Ablauf einer In-App-Nachricht, die auf „nach 1 Tag(en)“ eingestellt ist?

Braze berechnet eine Ablaufzeit von einem Tag als 24 Stunden, nachdem Nutzer:innen berechtigt sind, eine Nachricht zu empfangen.

Was sind Template-basierte In-App-Nachrichten?

In-App-Nachrichten werden als Template-basierte In-App-Nachrichten zugestellt, wenn Campaign-Berechtigung vor der Anzeige erneut prüfen ausgewählt ist oder wenn einer der folgenden Liquid-Tags in der Nachricht vorhanden ist:

• canvas_entry_properties
• connected_content
• SMS-Variablen wie {sms.${*}}
• catalog_items
• catalog_selection_items
• event_properties

Braze verwendet die Template-basierte Zustellung auch für inaktive In-App-Nachrichten-Campaigns (Campaigns, die noch aktiv sind, aber nicht mehr gesendet werden oder nicht mehr benötigt werden). Diese Campaigns folgen weiterhin ihren konfigurierten Zielgruppen- und Trigger-Regeln.

Braze kann die Template-basierte Zustellung auch zum Schutz der App-Performance einsetzen. Wenn die Vorbereitung von Liquid-Inhalten eine Session-Antwort um mehr als wenige Sekunden verzögert, verschiebt Braze die verbleibende Verarbeitung. Diese Nachrichten werden beim Triggern gerendert.

Das bedeutet, dass das Gerät beim Session-Start den Trigger dieser In-App-Nachricht empfängt und nicht die gesamte Nachricht. Wenn die Nutzerin oder der Nutzer die In-App-Nachricht triggert, stellt das Gerät eine Netzwerkanfrage, um die eigentliche Nachricht abzurufen.

Hinweis

Die Nachricht wird nicht zugestellt, wenn das Gerät keinen Internetzugang hat. Die Nachricht wird möglicherweise nicht zugestellt, wenn die Liquid-Logik zu lange für die Auflösung benötigt.

Um die Menge an Liquid zu reduzieren, die Braze beim Session-Start verarbeitet, lesen Sie Performance von In-App-Nachrichten optimieren.

Wie funktioniert das Abbruchverhalten bei In-App-Nachrichten?

Bei Braze tritt ein Abbruch auf, wenn ein:e Nutzer:in eine Aktion ausführt, die sie:ihn für den Empfang einer Nachricht qualifiziert, die Nachricht jedoch nicht zugestellt wird, weil die Liquid-Logik sie:ihn als nicht qualifiziert kennzeichnet. Zum Beispiel:

1. Sam führt eine Aktion aus, die eine E-Mail-Campaign triggern soll.
2. Der E-Mail-Textkörper enthält Liquid-Logik, die besagt: Wenn das angepasste Attribut „Score“ kleiner als 50 ist, soll diese E-Mail nicht gesendet werden.
3. Sams Wert für das angepasste Attribut „Score“ beträgt 20.
4. Braze erkennt, dass Sam diese E-Mail nicht erhalten sollte, und die E-Mail wird abgebrochen.
5. Ein Abbruch-Event wird protokolliert.

Da In-App-Nachrichten jedoch ein Pull-Kanal sind, funktionieren Abbrüche bei ihnen etwas anders.

Standard-Abbruchverhalten bei In-App-Nachrichten

In-App-Nachrichten werden beim Sitzungsstart vom Gerät abgerufen und dort zwischengespeichert, sodass die Nachricht unabhängig von der Qualität der Internetverbindung sofort zugestellt werden kann. Wenn ein:e Nutzer:in beispielsweise fünf In-App-Nachrichten innerhalb einer Sitzung erhält, werden alle fünf beim Sitzungsstart abgerufen. Die Nachrichten werden lokal zwischengespeichert und erscheinen, wenn ihre definierten Trigger-Events eintreten (Sitzungsstart, Nutzer:in klickt einen Button, der ein angepasstes Event protokolliert, oder andere).

Anders ausgedrückt: Die Logik, die bestimmt, ob eine In-App-Nachricht abgebrochen werden soll, wird ausgeführt, bevor der Trigger ausgelöst wurde. Um dies zu veranschaulichen, nehmen wir an, Sam aus dem E-Mail-Beispiel hat Push-Benachrichtigungen abonniert.

1. Sam startet eine Sitzung, indem er eine mit Braze betriebene App auf seinem Telefon öffnet.
2. Basierend auf den Zielgruppenkriterien der aktiven Campaigns im Workspace könnte Sam für fünf verschiedene Campaigns qualifiziert sein. Alle fünf werden auf sein Telefon geladen und zwischengespeichert.
3. Sam hat keine Aktionen ausgeführt, die diese Nachrichten triggern würden, könnte sie aber während der Sitzung erhalten.
4. Die Liquid-Logik in zwei der In-App-Nachrichten enthält Regeln, die Sam vom Empfang ausschließen (z. B. ist sein angepasstes Attribut „Score“ nicht hoch genug).
5. Sam erhält die zwei In-App-Nachrichten, die ihn ausschließen, nicht – aber er erhält die anderen drei Nachrichten.
6. Es werden keine Abbruch-Events protokolliert.

Braze protokolliert in Sams Fall keine Abbruch-Events, da dies nicht der Definition eines Abbruchs entspricht: Sam hat keine Aktionen ausgeführt, die die Nachrichten triggern würden. Bei In-App-Nachrichten führen Nutzer:innen den Trigger nie tatsächlich aus, bevor Braze entscheidet, dass sie die Nachricht nicht sehen sollen.

Abbruchverhalten bei Template-basierten In-App-Nachrichten

Template-basierte In-App-Nachrichten veranlassen das SDK, bei Eintreten des Trigger-Events erneut zu prüfen, ob eine Nachricht angezeigt werden soll. Dies führt zu einem anderen Abbruchverhalten. Betrachten Sie dieses Beispiel:

1. Sam startet eine Braze-Sitzung, indem er eine mit Braze betriebene App auf seinem Telefon öffnet.
2. Die Zielgruppenkriterien der aktiven Campaigns besagen, dass Sam für eine Template-basierte In-App-Nachricht qualifiziert sein könnte. Daher werden die Trigger-Informationen ohne den Nachrichteninhalt an sein Gerät gesendet.
3. Sam wählt einen Button, der ein angepasstes Event protokolliert und die Template-basierte In-App-Nachricht triggert.
4. Sams Gerät stellt eine Netzwerkanfrage, um die In-App-Nachricht abzurufen.
5. Die Liquid-Logik der Nachricht führt zu einem Abbruch, daher protokolliert Braze dies als Abbruch; Sam hat die Trigger-Aktion vor dieser Auswertung ausgeführt.

Vergleich des Abbruchverhaltens bei In-App-Nachrichten

Diese Tabelle vergleicht die In-App-Nachrichten-Abläufe, die Sam erlebt hat:

Wann wird Connected Content bei In-App-Nachrichten ausgeführt?

Bei Template-basierten In-App-Nachrichten werden Connected Content und andere Liquid-Tags aufgelöst, wenn das Trigger-Event eintritt und das Gerät den Nachrichteninhalt anfordert – nicht wenn die:der Nutzer:in einen Button innerhalb der Nachricht klickt. Jeder Template-basierte Abruf kann Connected-Content-Aufrufe für diese Anzeige enthalten.

Wenn Ihr HTML auf REST-Daten verweist, die von Connected Content zurückgegeben werden, stehen diese Daten für die Sitzung zur Verfügung, in der die Nachricht als Template verarbeitet wurde. Mehrere Buttons können dieselbe Connected-Content-Antwort referenzieren, ohne beim Klicken zusätzliche Aufrufe auszulösen.

Was ist die maximale Verzögerung nach einem Trigger bei In-App-Nachrichten-Campaigns?

In-App-Nachrichten-Campaigns können die Zustellung nach dem Trigger-Event um bis zu zwei Stunden (7.200 Sekunden) verzögern. Die Verzögerungsoptionen sind Sofort und Nach einer Verzögerung. Für eine längere Wartezeit fügen Sie einen Verzögerungsschritt vor einem In-App-Nachrichten-Schritt in einem Canvas hinzu. Informationen zur Einrichtung von Verzögerungen finden Sie unter Aktionsbasierte Zustellung.

Warum gibt es eine Verzögerung, bevor meine In-App-Nachricht angezeigt wird?

Standard-In-App-Nachrichten werden angezeigt, sobald der zwischengespeicherte Inhalt nach dem Trigger-Event bereit ist. Auf Android und iOS können große Bilder oder andere über CDN gehostete Ressourcen, die in der Nachricht referenziert werden, eine kurze Verzögerung verursachen, während diese Ressourcen heruntergeladen werden, bevor die In-App-Nachricht erscheint.

Template-basierte In-App-Nachrichten und Campaigns mit aktivierter Option Campaign-Qualifikation vor der Anzeige erneut prüfen erfordern nach dem Trigger eine zusätzliche Netzwerkanfrage, bevor die Nachricht erscheint. Dies kann eine kurze Verzögerung verursachen (typischerweise unter 100 ms bei einer stabilen Verbindung). Weitere Informationen finden Sie unter Zielgruppe für Nutzer:innen auswählen.

Warum sieht meine In-App-Nachricht anders aus als die Dashboard-Vorschau?

Zugestellte In-App-Nachrichten können sich von der Dashboard-Vorschau unterscheiden, wenn:

• Ihre Integration angepasste Stile anwendet oder die Standard-UI für In-App-Nachrichten auf bestimmten Plattformen überschreibt
• Die Vorschau ein Testnutzer:innen-Profil mit anderen Attributen als die:der Empfänger:in verwendet
• Template-basierte Inhalte zum Sendezeitpunkt anders aufgelöst werden als im Vorschaumodus

Verwenden Sie Testnachrichten senden mit Testnutzer:innen, deren Profil Ihrer Zielgruppe entspricht, um das Erscheinungsbild zu überprüfen.

Warum verwendet eine mehrseitige In-App-Nachricht auf jeder Seite denselben Hintergrund?

Wenn Hintergrundbild auf einer Seite einer mehrseitigen In-App-Nachricht aktiviert ist, wird dieser Hintergrund auf alle Seiten der Nachricht angewendet. Um verschiedene Hintergründe pro Seite zu verwenden, nutzen Sie einen angepassten HTML-Block mit JavaScript, um Bilder zwischen den Seiten zu wechseln.

Wie teste ich Web-In-App-Nachrichten?

Für den Testversand von Web-In-App-Nachrichten muss Push auf dem Testgerät aktiviert sein, da der Testablauf eine Push-Benachrichtigung sendet, die die App oder Website öffnet, in der die In-App-Nachricht angezeigt wird. Derselbe Push-basierte Testpfad gilt auf jeder Plattform, auf der Push nicht mit Braze konfiguriert ist, wobei fehlendes Push am häufigsten im Web auftritt, da viele mobile Integrationen Push bereits aktiviert haben. Verwenden Sie stattdessen eine Live-Campaign an ein internes Testsegment. Schritte finden Sie unter Testnachrichten senden.

Benötigen In-App-Nachrichten eine Push-Integration?

In-App-Nachrichten benötigen keine Push-Benachrichtigungen, um in der Produktion zu funktionieren. In-App-Nachrichten werden über das Braze SDK zugestellt und erscheinen während einer aktiven App-Sitzung, ohne dass eine Push-Integration erforderlich ist.

Allerdings erfordern Testsendungen für In-App-Nachrichten, dass Push auf Ihren Testgeräten aktiviert ist. Denn Test-In-App-Nachrichten werden über eine Push-Benachrichtigung zugestellt, die die Anzeige der In-App-Nachricht triggert. Testnutzer:innen müssen Push aktiviert haben und die Test-Push-Benachrichtigung antippen, um die In-App-Nachricht zu sehen.

Bei Produktions-Campaigns sehen Nutzer:innen In-App-Nachrichten basierend auf Ihren Campaign-Triggern (wie Sitzungsstart oder angepasste Events), ohne dass Push involviert ist.

Warum erscheinen zusätzliche oder nicht gerenderte Zeichen in meiner In-App-Nachricht?

Das Kopieren von Text aus einer anderen App (wie einem Textverarbeitungsprogramm oder einer Webseite) kann unsichtbare oder nicht druckbare Zeichen in Ihren Nachrichtentext einfügen. Diese Zeichen können als fehlgeleitete Symbole erscheinen oder Liquid und HTML in angepassten Nachrichten beeinträchtigen.

Um fehlgeleitete oder nicht gerenderte Zeichen zu beheben, tippen Sie den betroffenen Text im Braze-Editor erneut ein oder löschen Sie die unerwünschten Zeichen direkt, anstatt nur den sichtbaren Text auszuwählen und zu ersetzen. Fügen Sie für angepasste HTML-Nachrichten mit Sonderzeichen <meta charset="UTF-8"> in Ihren HTML-<head>-Bereich ein. Details finden Sie unter Zeichenkodierung.

Warum ist der Schließen-Button bei HTML-In-App-Nachrichten im Vollbild auf Android ausgeblendet?

Auf Geräten mit Edge-to-Edge-Displays (einschließlich Android 15+) können HTML-In-App-Nachrichten im Vollbild hinter der System-Statusleiste dargestellt werden und ein Schließ-Steuerelement am oberen Rand des Layouts verdecken.

Ab Version 37.0.0 des Braze Android SDK werden Window-Insets standardmäßig auf HTML-In-App-Nachrichten angewendet, sodass Steuerelemente im sicheren Bereich bleiben. Falls Nutzer:innen weiterhin Überlappungen sehen, führen Sie ein Upgrade auf die neueste Version des Braze Android SDK durch.

In älteren SDK-Versionen konnten Entwickler:innen BrazeConfig.setIsHtmlInAppMessageApplyWindowInsetsEnabled(true) aktivieren, bevor dieses Verhalten zum Standard wurde.

Was sollte ich beim Anpassen von Drag-and-Drop-In-App-Nachrichten beachten?

Der Drag-and-Drop-Editor unterstützt modale Ansichten und Vollbild-Anzeigetypen. Sie erstellen Inhalte innerhalb dieser Container mit Editor-Blöcken.

Bitte beachten Sie:

• Links und Deeplinks: Jede Klick-Aktion hat standardmäßig ein URL-Feld. Verwenden Sie Liquid in der URL, um Links je nach Gerät, App-Typ oder Nutzer:innenattributen zu variieren. Im Nachrichten-Container können Sie außerdem plattformspezifisches Klickverhalten aktivieren, um unterschiedliche Links pro Plattform festzulegen.
• Transparenz und Hintergründe: Die Transparenz des Nachrichten-Containers wirkt sich auf den gesamten Nachrichtenhintergrund aus. Einzelne Blöcke können eigene Hintergrundfarben festlegen. Für eine feinere Kontrolle fügen Sie angepasstes CSS in einem Custom-Code-Block hinzu.
• Nachrichtenbreite: Die maximale Breite des Nachrichten-Containers kann im Editor nicht unter 325 px eingestellt werden, um die Lesbarkeit auf kleineren Bildschirmen zu gewährleisten. Verwenden Sie angepasstes CSS, wenn Sie ein schmaleres Layout benötigen.
• Plattformspezifische Hintergründe: Eine einzelne Nachricht verwendet dasselbe Hintergrundbild und dieselben Farben auf Web und Mobilgeräten. Im Editor können Sie keine unterschiedlichen Hintergründe pro Plattform festlegen.
• Mehrseitige Nachrichten: Hintergrundbilder und Klick-Aktionen auf Nachrichtenebene gelten für alle Seiten einer mehrseitigen Nachricht. Um auf jeder Seite unterschiedliche Bilder im Vollformat zu verwenden, fügen Sie Buttons hinzu, die auf die nächste Seite verlinken.
• Stile auf Nachrichtenebene: Stile auf Nachrichtenebene gelten für die gesamte Nachricht.
• Hintergrundbilder: Hintergrundbilder werden gestreckt, um das Modal auszufüllen.

Weitere Hinweise zum Editor finden Sie im Vorbereitungsleitfaden für In-App-Nachrichten.

Was bedeutet „Event was published, but no subscribers were found“ in den Android-SDK-Logs?

Diese Log-Zeile ist in der Regel kein Fehler. Sie erscheint häufig, wenn Braze ein internes Event veröffentlicht (z. B. NoMatchingTriggerEvent) und zu diesem Zeitpunkt kein Listener für In-App-Nachrichten oder Content Cards registriert ist.

Wenn Sie diesen Log-Eintrag sehen, obwohl Sie erwarten, dass ein angepasstes Event eine In-App-Nachricht auslöst, überprüfen Sie, ob das Event geloggt wurde, ob die Nutzer:innen zur Zielgruppe der Campaign oder des Canvas gehören und ob Content Cards synchronisiert sind, sofern die Nachricht davon abhängt.