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-Nachrichten-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 beim Sitzungsstart 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 einen Payload einer In-App-Nachricht auf ihrem Gerät haben und das Ablaufdatum der Nachricht geändert wird, wird das Ablaufdatum dann auch auf ihrem Gerät aktualisiert?

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

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

Das Feature Ruhezeiten ist für Campaigns mit In-App-Nachrichten nicht verfügbar. Dieses Feature verhindert, dass Nachrichten zu bestimmten Uhrzeiten an Ihre Nutzer:innen gesendet werden. Bei Campaigns mit In-App-Nachrichten erhalten Ihre Nutzer:innen In-App-Nachrichten nur, wenn sie in der App aktiv sind.

Um In-App-Nachrichten trotzdem nur zu einer bestimmten Zeit zu senden, können Sie den folgenden Liquid-Beispielcode verwenden. Damit wird die Nachricht abgebrochen, wenn die In-App-Nachricht nach 19:59 Uhr oder vor 8 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-Nachrichten-Campaigns können Sie Nutzer:innen erneut für den Empfang der Campaign berechtigen, indem Sie in den Zustellungskontrollen die erneute Berechtigung aktivieren (Nutzer:innen die erneute Berechtigung zum Empfang der Campaign erlauben). Wann Nutzer:innen die Campaign erneut erhalten können, hängt vom festgelegten Zeitfenster für die erneute Berechtigung ab. Außerdem spielt eine Rolle, wie Braze den vorherigen Versand erfasst hat. Wie sich Campaigns verhalten und wie die erneute Berechtigung mit dem Nachrichtenempfang zusammenhängt, erfahren Sie unter Erneute Berechtigung für Campaigns und Canvas.

Wenn die erneute Berechtigung deaktiviert ist, erhalten Nutzer:innen dieselbe Campaign in der Regel nicht erneut, nachdem sie sie einmal erhalten haben. Das gilt auch dann, wenn sie die Qualifikationskriterien weiterhin erfüllen.

Canvases

Bei In-App-Nachrichten aus einem Canvas hängt es von den Canvas-Eintrittskontrollen und Ihrer Schrittkonfiguration ab, ob Nutzer:innen die Nachricht erneut sehen können. Zu den Eintrittskontrollen gehört zum Beispiel, ob Nutzer:innen den Canvas erneut betreten dürfen. Die Zustellungskontrollen der Campaign allein sind hier nicht entscheidend.

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

Campaigns

Bei In-App-Nachrichten-Campaigns prüft Braze, ob Nutzer:innen zu Ihrer Zielgruppe gehören, wenn ihr Gerät In-App-Nachrichten herunterlädt. Das geschieht in der Regel zu Beginn einer Session. Das Gerät speichert die berechtigten Nachrichten und zeigt jede an, sobald ihr Trigger eintritt, auch wenn das erst später in der Session passiert.

Bei Campaigns mit einer zukünftigen Startzeit sendet Braze die Nachricht auch an Geräte, die bis zu einer Stunde vor der Startzeit eine Session beginnen. So ist die Nachricht rechtzeitig zur Anzeige bereit. Ein Beispiel: Eine Person, die um 6:30 Uhr eine Session beginnt, erhält eine Campaign, die um 7 Uhr startet. Braze prüft ihre Berechtigung um 6:30 Uhr, und die Nachricht wird angezeigt, sobald ihr Trigger nach 7 Uhr eintritt.

Berechtigung während einer Session

Nutzer:innen, die während einer Session berechtigt werden, erhalten die Nachricht zu Beginn ihrer nächsten Session.

Um die Berechtigung unmittelbar vor der Anzeige der Nachricht erneut zu prüfen, wählen Sie Kampagnenberechtigung vor der Anzeige neu bewerten aus. Wenn Nutzer:innen die Kriterien nicht mehr erfüllen, wird die Nachricht nicht angezeigt. Diese Einstellung sendet die Nachricht nicht an Nutzer:innen, die erst nach Beginn ihrer Session berechtigt wurden. Weitere Informationen finden Sie unter Zielnutzer:innen auswählen.

Canvases

Bei In-App-Nachrichten in einem Canvas prüft Braze die Zielgruppe des Schritts, wenn Nutzer:innen den Schritt erreichen. Die Nachricht wird dann zu Beginn ihrer nächsten Session heruntergeladen.

Warum liefert meine archivierte Campaign mit In-App-Nachrichten noch Impressionen?

Das kann bei Nutzer:innen vorkommen, die die Segmentkriterien erfüllt haben, während die Campaign mit In-App-Nachrichten aktiv war.

Um das zu verhindern, wählen Sie bei der Einrichtung Ihrer Campaign die Option Campaign-Berechtigung vor der Anzeige neu bewerten aus.

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

In-App-Nachrichten verwenden keine Metrik Ö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 zu In-App-Nachrichten enthält, vergleichen Sie Impressionen und Klicks statt Öffnungen wie bei E-Mails. Definitionen finden Sie unter Berichte zu In-App-Nachrichten.

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

Ja, allerdings kann pro Vorkommen eines Trigger-Events nur eine In-App-Nachricht angezeigt werden. Wenn mehrere In-App-Nachrichten-Campaigns denselben Trigger verwenden (zum Beispiel den Sessionstart), wird bei jedem Auftreten dieses Triggers nur die Nachricht mit der höchsten Priorität angezeigt. Bei Sessionstart-Triggern bedeutet das, dass pro Session nur eine Nachricht angezeigt werden kann. Die nächste Gelegenheit, eine weitere geeignete Nachricht anzuzeigen, ist dann die nächste Session.

Wenn mehrere Nachrichten dieselbe Prioritätsstufe haben, wird die zuletzt erstellte Nachricht zuerst angezeigt. Bei Sessionstart-Triggern wird die nächstjüngere Nachricht in einer späteren Session angezeigt. Bei anderen Trigger-Typen wird die nächstjüngere Nachricht beim nächsten Auftreten dieses Trigger-Events angezeigt. Das kann innerhalb derselben Session oder in einer späteren Session sein.

Um die Anzeigereihenfolge innerhalb eines Prioritäts-Buckets festzulegen, öffnen Sie die Zustellungseinstellungen einer der Campaigns, wählen Sie Set Exact Priority aus und ziehen Sie die Campaigns per Drag-and-drop in die gewünschte Reihenfolge. Weitere Informationen finden Sie unter Priorität auswählen.

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

Unter Berichte zu In-App-Nachrichten erfahren Sie, wie Impressionen und Klicks je nach Nutzeraktion protokolliert werden. Beispiele speziell für Vollbild-Nachrichten, die mit dem traditionellen Editor erstellt wurden, finden Sie unter Metriken für Vollbild-Nachrichten nach Nutzeraktion.

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

Braze berechnet eine Ablaufzeit von einem Tag als 24 Stunden ab dem Zeitpunkt, zu dem Nutzer:innen berechtigt sind, eine Nachricht zu erhalten.

Was sind In-App-Nachrichten mit Template?

In-App-Nachrichten werden als In-App-Nachrichten mit Template zugestellt, wenn Campaign-Berechtigung vor der Anzeige neu bewerten ausgewählt ist oder wenn die Nachricht eines der folgenden Liquid-Tags enthält:

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

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

Braze kann die Zustellung mit Template auch nutzen, um die Performance der App zu schützen. Wenn die Vorbereitung von Liquid-Inhalten eine Sitzungsantwort um mehr als einige Sekunden verzögert, verschiebt Braze die verbleibende Verarbeitung. Diese Nachrichten werden gerendert, sobald sie getriggert werden.

Das bedeutet, dass das Gerät beim Sitzungsstart nur den Trigger dieser In-App-Nachricht erhält und nicht die gesamte Nachricht. Wenn Nutzer:innen die In-App-Nachricht triggern, sendet 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 Auflösung der Liquid-Logik zu lange dauert.

Wie Sie die Menge an Liquid reduzieren, die Braze beim Sitzungsstart verarbeitet, erfahren Sie unter Performance von In-App-Nachrichten optimieren.

Wie funktioniert das Abbruchverhalten bei In-App-Nachrichten?

Bei Braze liegt ein Abbruch vor, wenn Nutzer:innen eine Aktion ausführen, durch die sie eine Nachricht erhalten könnten, die Nachricht aber nicht erhalten, weil die Liquid-Logik der Nachricht sie als nicht berechtigt kennzeichnet. Zum Beispiel:

1. Sam führt eine Aktion aus, die eine E-Mail-Campaign triggern soll.
2. Der Text der E-Mail enthält Liquid-Logik, die festlegt, dass diese E-Mail nicht gesendet wird, wenn das angepasste Attribut „score“ kleiner als 50 ist.
3. Sams angepasstes Attribut „score“ hat den Wert 20.
4. Braze erkennt, dass Sam diese E-Mail nicht erhalten soll, 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 auf dem Gerät zwischengespeichert. So kann die Nachricht unabhängig von der Qualität der Internetverbindung sofort an die Nutzer:innen zugestellt werden. Wenn Nutzer:innen beispielsweise innerhalb ihrer Sitzung fünf In-App-Nachrichten erhalten, erhalten sie alle fünf beim Sitzungsstart. Die Nachrichten werden lokal zwischengespeichert und erscheinen, sobald die definierten Trigger-Events eintreten (Sitzungsstart, Klick auf einen Button, der ein angepasstes Event protokolliert, oder Ähnliches).

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

1. Sam startet eine Sitzung, indem Sam eine App mit Braze-Integration auf dem Smartphone ö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 Sams Smartphone abgerufen und zwischengespeichert.
3. Sam hat keine Aktionen ausgeführt, die diese Nachrichten triggern würden, könnte diese Nachrichten in der Sitzung aber erhalten.
4. Das Liquid in zwei der In-App-Nachrichten enthält Regeln, die Sam vom Empfang der Nachricht ausschließen (zum Beispiel weil das angepasste Attribut „score“ nicht hoch genug ist).
5. Sam erhält die beiden In-App-Nachrichten, die Sam ausschließen, nicht, aber die anderen drei Nachrichten.
6. Es werden keine Abbruch-Events protokolliert.

Braze protokolliert in Sams Fall keine Abbruch-Events, da die Definition eines Abbruchs nicht erfüllt ist: 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 feststellt, dass sie die Nachricht nicht sehen sollen.

Abbruchverhalten bei In-App-Nachrichten mit Templates

In-App-Nachrichten mit Templates zwingen das SDK, beim Eintreten des Trigger-Events neu zu bewerten, ob eine Nachricht angezeigt werden soll. Dadurch ergibt sich ein anderes Abbruchverhalten. Betrachten Sie zur Veranschaulichung folgendes Beispiel:

1. Sam startet eine Braze-Sitzung, indem Sam eine App mit Braze-Integration auf dem Smartphone öffnet.
2. Laut den Zielgruppenkriterien der aktiven Campaigns könnte Sam für eine In-App-Nachricht mit Template berechtigt sein. Daher werden die Trigger-Informationen ohne den Payload der Nachricht an Sams Gerät gesendet.
3. Sam wählt einen Button aus, der ein angepasstes Event protokolliert und damit die In-App-Nachricht mit Template 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, und Braze protokolliert dies als Abbruch, da Sam die Trigger-Aktion vor dieser Bewertung ausgeführt hat.

Vergleich des Abbruchverhaltens bei In-App-Nachrichten

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

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

Bei In-App-Nachrichten mit Templates werden Connected-Content und andere Liquid-Tags aufgelöst, wenn das Trigger-Event eintritt und das Gerät den Payload der Nachricht anfordert – nicht, wenn Nutzer:innen auf einen Button in der Nachricht klicken. Jeder Abruf mit Template 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 mit dem Template erstellt wurde. Mehrere Buttons können auf dieselbe Connected-Content-Antwort verweisen, ohne beim Klick zusätzliche Aufrufe auszulösen.

Wie lang kann die Verzögerung nach einem Trigger bei In-App-Nachrichten-Campaigns maximal sein?

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

Warum wird meine In-App-Nachricht mit Verzögerung angezeigt?

Standard-In-App-Nachrichten werden angezeigt, sobald der zwischengespeicherte Payload nach dem Trigger-Event bereit ist. Unter Android und iOS können große Bilder oder andere über ein CDN gehostete Assets, auf die in der Nachricht verwiesen wird, zu einer kurzen Verzögerung führen, während diese Ressourcen heruntergeladen werden, bevor die In-App-Nachricht erscheint.

In-App-Nachrichten mit Templates und Campaigns, bei denen Campaign-Berechtigung vor der Anzeige neu bewerten ausgewählt ist, erfordern nach dem Trigger eine zusätzliche Netzwerkanfrage, bevor die Nachricht erscheint. Dies kann zu einer kurzen Verzögerung führen (bei einer stabilen Verbindung in der Regel unter 100 ms). Weitere Informationen finden Sie unter Zielnutzer:innen auswählen.

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

Zugestellte In-App-Nachrichten können von der Vorschau im Dashboard abweichen, wenn:

• Ihre Integration auf bestimmten Plattformen angepasste Stile anwendet oder die standardmäßige UI für In-App-Nachrichten überschreibt
• die Vorschau ein Testnutzerprofil mit anderen Attributen als denen der Empfänger:innen verwendet
• Inhalte mit Templates zum Sendezeitpunkt anders aufgelöst werden als im Vorschaumodus

Verwenden Sie Testnachrichten senden mit einer Testnutzerin oder einem Testnutzer, deren bzw. dessen Profil Ihrer Zielgruppe entspricht, wenn Sie das Erscheinungsbild prü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, gilt dieser Hintergrund für alle Seiten der Nachricht. Um pro Seite unterschiedliche Hintergründe zu verwenden, nutzen Sie einen angepassten HTML-Block mit JavaScript, der die Bilder zwischen den Seiten austauscht.

Wie teste ich Web-In-App-Nachrichten?

Für Testversände von Web-In-App-Nachrichten muss Push auf dem Testgerät aktiviert sein, da beim Testablauf eine Push-Benachrichtigung zugestellt wird, die die App oder Website öffnet, in der die In-App-Nachricht angezeigt wird. Derselbe Push-basierte Testablauf gilt auf jeder Plattform, auf der Push nicht mit Braze konfiguriert ist. Fehlendes Push tritt jedoch am häufigsten im Web auf, da bei vielen mobilen Integrationen Push bereits aktiviert ist. Verwenden Sie stattdessen eine Live-Campaign für ein internes Testsegment. Die einzelnen Schritte finden Sie unter Testnachrichten senden.

Erfordern In-App-Nachrichten eine Push-Integration?

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

Für Testversände von In-App-Nachrichten muss Push auf Ihren Testgeräten jedoch aktiviert sein. Das liegt daran, dass Test-In-App-Nachrichten über eine Push-Benachrichtigung zugestellt werden, die die Anzeige der In-App-Nachricht triggert. Testnutzer:innen müssen Push aktiviert haben und auf die Test-Push-Benachrichtigung tippen, um die In-App-Nachricht zu sehen.

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

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

Wenn Sie Text aus einer anderen Anwendung (zum Beispiel einem Textverarbeitungsprogramm oder einer Webseite) kopieren, können unsichtbare oder nicht druckbare Zeichen in Ihren Nachrichtentext gelangen. Diese Zeichen können als verirrte Symbole erscheinen oder Liquid und HTML in angepassten Nachrichten beschädigen.

Um verirrte oder nicht dargestellte Zeichen zu beheben, geben Sie den betroffenen Text im Braze-Editor neu 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 den <head> Ihres HTML ein. Einzelheiten finden Sie unter Zeichenkodierung.

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

Auf Geräten mit randlosen Displays (Edge-to-Edge, einschließlich Android 15+) können Vollbild-HTML-In-App-Nachrichten hinter der Statusleiste des Systems gezeichnet werden. Dadurch kann ein Schließen-Element oben im Layout verdeckt werden.

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

Bei ä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 die Anzeigetypen Modal und Vollbild. Den Inhalt innerhalb dieser Container erstellen Sie mit Editor-Blöcken.

Beachten Sie Folgendes:

• Links und Deeplinks: Jede On-Click-Aktion hat standardmäßig ein URL-Feld. Mit Liquid in der URL können Sie Links je nach Gerät, App-Typ oder Nutzerattributen variieren. Im Nachrichten-Container können Sie außerdem plattformspezifisches On-Click-Verhalten aktivieren, um für jede Plattform unterschiedliche Links festzulegen.
• Deckkraft und Hintergründe: Die Deckkraft des Nachrichten-Containers wirkt sich auf den gesamten Hintergrund der Nachricht aus. Einzelne Blöcke können eigene Hintergrundfarben festlegen. Für eine genauere Steuerung fügen Sie angepasstes CSS in einem Block für angepassten Code hinzu.
• Nachrichtenbreite: Die maximale Breite des Nachrichten-Containers kann im Editor nicht unter 325 px eingestellt werden. So bleibt der Inhalt auch auf kleineren Bildschirmen gut lesbar. Verwenden Sie angepasstes CSS, wenn Sie ein schmaleres Layout benötigen.
• Plattformspezifische Hintergründe: Eine einzelne Nachricht verwendet im Web und auf Mobilgeräten dasselbe Hintergrundbild und dieselben Farben. Im Editor können Sie keine unterschiedlichen Hintergründe pro Plattform festlegen.
• Mehrseitige Nachrichten: Hintergrundbilder und On-Click-Aktionen auf Nachrichtenebene gelten für alle Seiten einer mehrseitigen Nachricht. Wenn Sie auf jeder Seite unterschiedliche Vollbilder verwenden möchten, fügen Sie Buttons hinzu, die zur nächsten Seite verlinken.
• Stile auf Nachrichtenebene: Stile auf Nachrichtenebene gelten für die gesamte Nachricht.
• Hintergrundbilder: Hintergrundbilder werden gestreckt, damit sie in das Modal passen.

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

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

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

Wenn Sie dieses Log sehen, obwohl ein angepasstes Event eine In-App-Nachricht triggern soll, prü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, falls die Nachricht von ihnen abhängt.