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-Message-Campaign oder Ihres Canvas im Feld Senden an die Option Webbrowser 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 vor dem Offlinegehen herunterladen. In diesem Fall kann die In-App-Nachricht auch im Offlinemodus angezeigt werden. Wenn die Payload nicht heruntergeladen wurde, wird die In-App-Nachricht nicht angezeigt.

Wenn Nutzer:innen bereits eine In-App-Nachrichten-Payload auf ihrem Gerät haben und die Nachrichtenablaufzeit geändert wird, wird die Ablaufzeit 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 die Ablaufzeit geändert hat und eine Sitzung protokolliert wird, 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, um In-App-Nachrichten während eines bestimmten Zeitraums zu senden, verwenden Sie den folgenden Liquid-Beispielcode. 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 festgelegten 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 auf Grundlage der Qualifizierungskriterien, nachdem sie diese bereits erhalten haben.

Canvases

Bei In-App-Nachrichten, die über einen 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 den Canvas erneut betreten dürfen) und der 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 kanalübergreifender Export 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-Nachricht-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 verwenden (zum Beispiel Sitzungsstart), wird bei jedem Auftreten dieses Triggers 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. Anschließend können Sie die Campaigns per Drag-and-Drop in die gewünschte Reihenfolge bringen. Weitere Informationen finden Sie unter Priorität auswählen.

Wie werden Impressionen und Klicks für In-App-Nachrichten protokolliert?

Unter In-App-Nachricht-Reporting erfahren Sie, wie Impressionen und Klicks basierend auf Nutzer:innenaktionen protokolliert werden. Für Beispiele speziell zu Vollbildnachrichten, die mit dem traditionellen Editor erstellt wurden, siehe Vollbildnachricht-Metriken nach Nutzer:innenaktion.

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 erhalten.

Was sind vorlagenbasierte In-App-Nachrichten?

In-App-Nachrichten werden als vorlagenbasierte 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 außerdem die vorlagenbasierte Zustellung für inaktive In-App-Nachrichten-Campaigns (Campaigns, die noch aktiv sind, aber nicht mehr senden oder nicht mehr benötigt werden). Diese Campaigns folgen weiterhin ihren konfigurierten Zielgruppen- und Trigger-Regeln.

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

Das bedeutet, dass das Gerät beim Sitzungsstart den Trigger dieser In-App-Nachricht anstelle der gesamten Nachricht erhält. Wenn die Nutzer:innen die In-App-Nachricht triggern, stellt ihr 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 Sitzungsstart verarbeitet, lesen Sie Performance von In-App-Nachrichten optimieren.

Wie funktioniert das Abbruchverhalten bei In-App-Nachrichten?

Bei Braze erfolgt ein Abbruch, wenn Nutzer:innen eine Aktion ausführen, die sie für den Empfang einer Nachricht qualifiziert, sie die Nachricht jedoch nicht erhalten, weil die Liquid-Logik sie als nicht berechtigt kennzeichnet. Zum Beispiel:

1. Sam führt eine Aktion aus, die eine E-Mail-Campaign triggern sollte.
2. Der E-Mail-Text enthält Liquid-Logik, die besagt: Wenn ein angepasstes Attribut „score“ kleiner als 50 ist, soll diese E-Mail nicht gesendet werden.
3. Sams angepasstes 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 vom Gerät beim Sitzungsstart abgerufen und auf dem Gerät zwischengespeichert. Unabhängig von der Qualität der Internetverbindung kann die Nachricht dadurch sofort zugestellt werden. Wenn Nutzer:innen beispielsweise fünf In-App-Nachrichten innerhalb ihrer Sitzung erhalten, werden alle fünf beim Sitzungsstart abgerufen. Die Nachrichten werden lokal zwischengespeichert und erscheinen, wenn ihre definierten Trigger-Events eintreten (Sitzungsstart, Klick auf einen Button, der ein angepasstes Event protokolliert, oder andere).

Mit anderen Worten: Die Logik, die bestimmt, ob eine In-App-Nachricht abgebrochen werden soll, wird vor dem Eintreten des Triggers ausgeführt. Um dies zu verdeutlichen, nehmen wir an, dass Sam aus dem E-Mail-Beispiel Push-Benachrichtigungen abonniert hat.

1. Sam startet eine Sitzung, indem er eine Braze-basierte App auf seinem Telefon öffnet.
2. Basierend auf den Zielgruppenkriterien der aktiven Campaigns im Workspace könnte Sam für fünf verschiedene Campaigns berechtigt 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 in der Sitzung empfangen.
4. Die Liquid-Logik in zwei der In-App-Nachrichten enthält Regeln, die Sam vom Empfang ausschließen (z. B. weil sein angepasstes Attribut „score“ nicht hoch genug ist).
5. Sam erhält die beiden 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 niemals tatsächlich aus, bevor Braze entscheidet, dass sie die Nachricht nicht sehen sollen.

Abbruchverhalten bei Template-In-App-Nachrichten

Template-In-App-Nachrichten veranlassen das SDK, beim 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 Braze-basierte App auf seinem Telefon öffnet.
2. Die Zielgruppenkriterien der aktiven Campaigns besagen, dass Sam für eine Template-In-App-Nachricht berechtigt sein könnte. Die Trigger-Informationen werden daher ohne den Nachrichteninhalt an sein Gerät gesendet.
3. Sam klickt auf einen Button, der ein angepasstes Event protokolliert und die Template-In-App-Nachricht triggert.
4. Sams Gerät sendet eine Netzwerkanfrage, um die In-App-Nachricht abzurufen.
5. Die Liquid-Logik der Nachricht führt zu einem Abbruch. Braze protokolliert dies als Abbruch, da Sam die Trigger-Aktion vor dieser Auswertung ausgeführt hat.

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-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 Nutzer:innen auf einen Button in der Nachricht klicken. Jeder Template-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 auf dieselbe Connected-Content-Antwort verweisen, ohne zusätzliche Aufrufe beim Klicken auszulösen.

Welche maximale Verzögerung gibt es nach einem Trigger für 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ögerung-Schritt vor einem In-App-Nachrichten-Schritt in einem Canvas hinzu. Informationen zur Einrichtung der Verzögerung 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 CDN-gehostete Ressourcen, auf die in der Nachricht verwiesen wird, eine kurze Verzögerung verursachen, während diese Ressourcen heruntergeladen werden, bevor die In-App-Nachricht erscheint.

Template-In-App-Nachrichten und Campaigns mit aktivierter Option Campaign-Berechtigung vor der Anzeige erneut prüfen erfordern eine zusätzliche Netzwerkanfrage nach dem Trigger, bevor die Nachricht erscheint. Dies kann eine kurze Verzögerung verursachen (in der Regel unter 100 ms bei einer stabilen Verbindung). Weitere Informationen finden Sie unter Zielnutzer: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 Empfänger:innen verwendet
• Template-Inhalte zur Sendezeit 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 unterschiedliche 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?

Zum Testen von Web-In-App-Nachrichten muss Push auf dem Testgerät aktiviert sein, da der Testvorgang 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, obwohl 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. Die Schritte finden Sie unter Testnachrichten senden.

Erfordern In-App-Nachrichten eine Push-Integration?

In-App-Nachrichten erfordern 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.

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

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

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

Das Kopieren von Text aus einer anderen App (z. B. einem Textverarbeitungsprogramm oder einer Webseite) kann unsichtbare oder nicht druckbare Zeichen in Ihren Nachrichtentext einfügen. Diese Zeichen können als unerwünschte Symbole erscheinen oder Liquid und HTML in angepassten Nachrichten beschädigen.

Um unerwünschte oder nicht gerenderte Zeichen zu beheben, geben 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 bei angepassten 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 Vollbild-HTML-In-App-Nachrichten auf Android ausgeblendet?

Auf Geräten mit randlosem Display (einschließlich Android 15+) können Vollbild-HTML-In-App-Nachrichten hinter der Systemstatusleiste gezeichnet werden und ein Schließen-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, aktualisieren Sie auf die neueste Version des Braze Android SDK.

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

Was sollte ich bei der Anpassung von Drag-and-Drop-In-App-Nachrichten beachten?

Der Drag-and-Drop-Editor unterstützt die Anzeigetypen „Modal“ und „Vollbild“. Sie erstellen Inhalte innerhalb dieser Container mithilfe von Editor-Blöcken.

Beachten Sie Folgendes:

• Links und Deeplinks: Jede On-Click-Aktion verfügt standardmäßig über 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 auch plattformspezifisches On-Click-Verhalten aktivieren, um unterschiedliche Links pro Plattform festzulegen.
• Deckkraft und Hintergründe: Die Deckkraft des Nachrichten-Containers wirkt sich auf den gesamten Nachrichtenhintergrund aus. Einzelne Blöcke können eigene Hintergrundfarben festlegen. Für eine feinere Steuerung 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, damit Inhalte auf kleineren Bildschirmen lesbar bleiben. Verwenden Sie angepasstes CSS, wenn Sie ein schmaleres Layout benötigen.
• Plattformspezifische Hintergründe: Eine einzelne Nachricht verwendet auf Web und Mobilgeräten dasselbe Hintergrundbild und dieselben Farben. Unterschiedliche Hintergründe pro Plattform können im Editor nicht festgelegt werden.
• Mehrseitige Nachrichten: Hintergrundbilder und On-Click-Aktionen auf Nachrichtenebene gelten für alle Seiten einer mehrseitigen Nachricht. Um auf jeder Seite unterschiedliche Vollbilder 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 Überlegungen 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 diese Meldung erscheint, obwohl Sie erwarten, dass ein angepasstes Event eine In-App-Nachricht auslöst, überprüfen Sie, ob das Event geloggt wird, ob sich die Nutzer:innen in der Zielgruppe der Campaign oder des Canvas befinden und ob Content Cards synchronisiert sind, wenn die Nachricht davon abhängt.