Fehlerbehebung für In-App-Nachrichten

Verwenden Sie diese Seite, um zu diagnostizieren, warum In-App-Nachrichten nicht zugestellt oder auf einem Gerät angezeigt werden. Informationen zur Dashboard-Einrichtung (Priorität, Trigger, Segmente und Wiederberechtigung) finden Sie in den FAQ zu In-App-Nachrichten.

Bevor Sie mit dem Debugging beginnen, fügen Sie sich als Testnutzer:in hinzu und lesen Sie Testnachrichten senden.

Hier starten: Symptom zuordnen

Standardisierter Untersuchungspfad

Verwenden Sie diesen Workflow für jeden Vorfall. Beginnen Sie bei Schritt 1.

1. Bestätigen Sie, dass ein Sitzungsstart für das Testgerät protokolliert wird. In-App-Nachrichten werden beim Sitzungsstart angefordert.
2. Öffnen Sie die Event-Nutzerprotokolle und suchen Sie die SDK-Anfrage für diesen Sitzungsstart. In den Antwortdaten:
   • Bestätigen Sie im Roh-JSON, dass respond_with "triggers": true enthält.
   • Die Zeile Requested Responses sollte triggers enthalten.
   • Trigger In-App Message-Zeilen listen jede In-App-Nachricht auf, die für diese Anfrage zurückgegeben wurde.
   • Wenn kein triggers-Schlüssel oder keine Trigger In-App Message-Zeilen vorhanden sind, gehen Sie zu Fehlerbehebung: Nachrichten werden nicht angefordert.
   • Wenn triggers vorhanden, aber leer ist ([]), gehen Sie zu Fehlerbehebung: Nachrichten werden nicht zurückgegeben.
   • Wenn Trigger In-App Message-Zeilen vorhanden sind, aber nichts angezeigt wird, gehen Sie zu Plattformspezifische Fehlerbehebung bei der Anzeige.
   • Jeder Trigger-Payload enthält einen type: inapp (Standard) oder templated_iam (erfordert eine Template-Anfrage vor der Anzeige). Siehe Typen von In-App-Nachrichten.
3. Informationen zur Dashboard-seitigen Berechtigung (Segment, Wiederberechtigung, Frequency Caps, Priorität, Kontrollgruppen) finden Sie unter Fehlerbehebung bei der Zustellung und in den FAQ zu In-App-Nachrichten.
4. Bei geräteseitigen Anzeigeproblemen (Delegates, Rate-Limits, Ausrichtung, Sitzungs-Timeout) wählen Sie Ihren SDK-Tab unter Plattformspezifische Fehlerbehebung bei der Anzeige.

Canvas-In-App-Nachrichten

Symptom: Ein:e Nutzer:in ist in einen Canvas-In-App-Nachrichten-Schritt eingetreten, hat die Nachricht aber nicht wie erwartet gesehen.

Drei Verhaltensweisen verursachen die meisten Canvas- und In-App-Nachrichten-Tickets:

1. Anzeige bei nächster Sitzung: Canvas-In-App-Nachrichten sind beim nächsten Sitzungsstart berechtigt, nachdem der Schritt verarbeitet wurde – nicht sofort mitten in der Sitzung. Siehe Wann werden In-App-Nachrichten in Canvas gesendet? in den Canvas-FAQ.
2. Zustellungsvalidierungen beim Schritteintritt: Wenn Zielgruppe beim Nachrichtenversand validieren im Nachrichten-Schritt aktiviert ist, werden Segmentzugehörigkeit und Frequency Caps ausgewertet, wenn der/die Nutzer:in in den Schritt eintritt, nicht zum Anzeigezeitpunkt. Siehe Zustellungsvalidierungen.
3. Verzögerung und Sitzungs-Timeout: Wenn ein:e Nutzer:in in einen Verzögerungsschritt eintritt, der länger als Ihr SDK-Sitzungs-Timeout ist, kann eine neue Sitzung beginnen, bevor der In-App-Nachrichten-Schritt erreicht wird. Die Nachricht wird möglicherweise nicht beim Sitzungsstart abgerufen, wenn Sie erwarten, dass sie angezeigt wird.

Informationen zu Verfügbarkeitsfenstern, Ablauf und null Sends in Canvas-Analytics finden Sie unter In-App-Nachrichten und Zustellung in den Canvas-FAQ.

Wichtig

In-App-Nachrichten in Canvas können nur durch Events getriggert werden, die über das SDK gesendet werden, nicht über die REST API.

In-App-Nachricht wurde für eine:n Nutzer:in nicht angezeigt

Symptom: Ein:e Nutzer:in hat eine erwartete In-App-Nachricht nicht erhalten; andere Nutzer:innen sind möglicherweise nicht betroffen.

Überprüfen Sie Folgendes:

• War der/die Nutzer:in beim Sitzungsstart im Segment, wenn das SDK neue In-App-Nachrichten anfordert?
• War der/die Nutzer:in gemäß den Targeting-Regeln der Campaign oder des Canvas berechtigt oder wiederberechtigt? Siehe Wiederberechtigung für Campaigns und Canvas.
• Galt ein Frequency Cap?
• War der/die Nutzer:in in einer Campaign-Kontrollgruppe? Prüfen Sie, ob die Campaign für A/B-Tests konfiguriert ist.
• Wurde stattdessen eine In-App-Nachricht mit höherer Priorität angezeigt? Siehe Können mehrere In-App-Nachrichten in derselben Sitzung angezeigt werden? in den FAQ zu In-App-Nachrichten.
• War das Gerät in der von der Campaign angegebenen Ausrichtung?
• Wurde die Nachricht durch das standardmäßige Mindestintervall von 30 Sekunden zwischen Triggern unterdrückt? Siehe Überschreiben des Standard-Rate-Limits.

Folgen Sie dann dem standardisierten Untersuchungspfad.

In-App-Nachricht wurde auf einer Plattform nicht angezeigt

Symptom: In-App-Nachrichten werden auf Android, iOS oder Web nicht angezeigt, funktionieren aber möglicherweise auf anderen Plattformen.

In-App-Nachricht wurde für alle Nutzer:innen nicht angezeigt

Symptom: Keine oder weniger Nutzer:innen als erwartet haben die In-App-Nachricht erhalten.

Überprüfen Sie Folgendes:

• Ist die Trigger-Aktion im Dashboard und in der App-Integration korrekt konfiguriert?
• Hat eine In-App-Nachricht mit höherer Priorität die Campaign abgefangen? Siehe die FAQ zu In-App-Nachrichten.
• Verwenden Sie eine aktuelle SDK-Version? Einige In-App-Nachrichtentypen haben Mindestanforderungen an die SDK-Version.
• Sind Sitzungen korrekt integriert? Bestätigen Sie, dass die Sitzungs-Analytics für diese App funktionieren.
• Stört eine angepasste UI-Bibliothek die Anzeige? Siehe Anpassung.

Folgen Sie dann dem standardisierten Untersuchungspfad.

Timing und verzögerte Anzeige

Symptom: Die In-App-Nachricht erschien später als erwartet oder erst bei einer neuen Sitzung.

Häufige Ursachen:

• Sitzungsstart-Prefetch der Campaign: In-App-Nachrichten werden beim Sitzungsstart zwischengespeichert und angezeigt, wenn der Trigger ausgelöst wird. Ein Trigger, der vor dem nächsten Sitzungsstart auftritt, wird erst in dieser Sitzung angezeigt. Siehe Nachrichten triggern.
• Canvas-Verhalten bei nächster Sitzung: Siehe Canvas-In-App-Nachrichten.
• Geplante Dashboard-Verzögerung: Prüfen Sie, ob eine Verzögerung für die Campaign oder den Schritt konfiguriert ist.
• Trigger-Synchronisierungs-Race-Condition: Wenn Nutzer:innen ein Event unmittelbar nach dem Sitzungsstart protokollieren, sind die Trigger möglicherweise noch nicht synchronisiert. Erwägen Sie, den Trigger auf den Sitzungsstart zu setzen und nach dem beabsichtigten Event zu segmentieren, damit die Zustellung in der nächsten Sitzung nach dem Event erfolgt.
• Sequenzielle In-App-Nachrichten: Wenn Sie Nachrichten in einer Tour zurückstellen oder wiederherstellen, siehe Getriggerte In-App-Nachrichten zurückstellen.
• Große Assets oder langsames CDN: Optimieren Sie Bilder und Videos für HTML-In-App-Nachrichten. Auf Mobilgeräten können Bilder bei langsamen Netzwerken vor der Anzeige heruntergeladen werden – wählen Sie unten Ihren SDK-Tab für plattformspezifische Hinweise.

Hinweis

Wenn Ihre In-App-Nachricht durch den Sitzungsstart getriggert wird und Sie ein verlängertes Sitzungs-Timeout festgelegt haben, wird das Schließen und erneute Öffnen der App innerhalb dieses Zeitfensters die Sitzung nicht aktualisieren. Beispiel: Bei einem 300-Sekunden-Timeout wird eine Sitzungsstart-In-App-Nachricht erst angezeigt, wenn die Sitzung tatsächlich aktualisiert wird. Passen Sie das Sitzungs-Timeout oder den Trigger-Typ an, wenn dies Ihren Test beeinflusst.

Fehlerbehebung bei der Zustellung

Die meisten Probleme mit In-App-Nachrichten betreffen die Zustellung (das Gerät hat keine Trigger erhalten) oder die Anzeige (Trigger sind angekommen, wurden aber nicht angezeigt). Bestätigen Sie zuerst die Zustellung und prüfen Sie dann die Anzeige.

Fehlerbehebung bei der Zustellung

Das SDK fordert In-App-Nachrichten beim Sitzungsstart von den Braze-Servern an. Bestätigen Sie, dass das SDK Trigger anfordert und Braze diese zurückgibt.

Prüfen, ob Nachrichten angefordert und zurückgegeben werden

1. Fügen Sie sich als Testnutzer:in hinzu.
2. Richten Sie eine In-App-Nachrichten-Campaign ein, die auf Ihre:n Nutzer:in ausgerichtet ist.
3. Starten Sie eine neue Sitzung in Ihrer Anwendung.
4. Suchen Sie in den Event-Nutzerprotokollen die SDK-Anfrage für das Sitzungsstart-Event. In den Antwortdaten:
   • Bestätigen Sie im Roh-JSON, dass respond_with "triggers": true enthält.
   • Die Zeile Requested Responses listet die Top-Level-Schlüssel in der Antwort auf. Für In-App-Nachrichten erwarten Sie triggers.
   • Trigger In-App Message-Zeilen listen jede In-App-Nachricht auf, die für diese Anfrage zurückgegeben wurde.

   Dann triagieren:

   • Wenn kein triggers-Schlüssel oder keine Trigger In-App Message-Zeilen vorhanden sind, siehe Fehlerbehebung: Nachrichten werden nicht angefordert.
   • Wenn triggers vorhanden, aber leer ist ([]), siehe Fehlerbehebung: Nachrichten werden nicht zurückgegeben.
   • Wenn Trigger In-App Message-Zeilen vorhanden sind, aber nichts auf dem Gerät angezeigt wird, siehe Plattformspezifische Fehlerbehebung bei der Anzeige.
   • Jeder Trigger-Payload enthält einen type: inapp (Standard) oder templated_iam (erfordert eine Template-Anfrage vor der Anzeige). Siehe Typen von In-App-Nachrichten.
5. Bestätigen Sie, dass die richtigen In-App-Nachrichten in den Antwortdaten erscheinen.

Fehlerbehebung: Nachrichten werden nicht angefordert

Wenn In-App-Nachrichten nicht angefordert werden, verfolgt Ihre App möglicherweise Sitzungen nicht korrekt – In-App-Nachrichten werden beim Sitzungsstart aktualisiert. Bestätigen Sie, dass die App eine Sitzung basierend auf Ihrer Sitzungs-Timeout-Semantik startet:

Fehlerbehebung: Nachrichten werden nicht zurückgegeben

Wenn In-App-Nachrichten nicht zurückgegeben werden, liegt wahrscheinlich ein Targeting- oder Berechtigungsproblem vor:

1. Ihr Segment enthält Ihre:n Nutzer:in nicht.
   • Überprüfen Sie den Tab Engagement des/der Nutzer:in auf das erwartete Segment.
2. Ihr:e Nutzer:in hat die Nachricht bereits erhalten und war nicht wiederberechtigt.
   • Überprüfen Sie die Wiederberechtigungseinstellungen und die FAQ zu In-App-Nachrichten.
3. Ihr:e Nutzer:in hat das Frequency Cap erreicht.
   • Überprüfen Sie die Frequency-Cap-Einstellungen.
4. Ihr:e Nutzer:in ist in eine Kontrollgruppe gefallen.
   • Erstellen Sie ein Segment mit einem Filter Received campaign variant, der auf Control gesetzt ist, oder deaktivieren Sie Kontrollgruppen während der Integrationstests.
5. Eine In-App-Nachricht mit höherer Priorität hatte Vorrang. Siehe die FAQ zu In-App-Nachrichten.

Informationen zu archivierten Campaigns, Trigger-Konfiguration und Ruhezeiten finden Sie in den FAQ zu In-App-Nachrichten.

Impressionen und Analytics

Symptom: Impressionen- oder Klickzahlen entsprechen nicht den Erwartungen.

• Impressionen größer als Eindeutige Impressionen: Erwartet, wenn Nutzer:innen mehrere Geräte haben oder wenn eine geplante Verzögerung dazu führt, dass derselbe/dieselbe Nutzer:in sich mehr als einmal qualifiziert. Siehe Wiederberechtigung für Campaigns und Canvas.
• Impressionen niedriger als erwartet: Nutzer:innen haben die Nachricht möglicherweise nicht gesehen (Impressionen werden bei der Anzeige protokolliert), mehrere Nachrichten mit hoher Priorität können sich gegenseitig abfangen, oder Trigger-Synchronisierungs-Race-Conditions können auftreten. Für Canvas-In-App-Nachrichten siehe Canvas-In-App-Nachrichten. Vollständige Metrikdefinitionen finden Sie unter Reporting für In-App-Nachrichten und in den FAQ zu In-App-Nachrichten.
• Impressionen niedriger als zuvor: Überprüfen Sie die Segment- und Campaign-Changelogs. Bestätigen Sie, dass Sie nicht dasselbe Trigger-Event in einer Campaign mit höherer Priorität wiederverwendet haben.

Wenn Sie einen Delegate oder angepassten Handler verwenden, um In-App-Nachrichten manuell anzuzeigen, müssen Sie Impressionen und Klicks selbst protokollieren. Siehe Ihren SDK-Tab unter Plattformspezifische Fehlerbehebung bei der Anzeige für Swift- und Android-Details oder In-App-Nachrichtendaten protokollieren für Web.

Plattformspezifische Fehlerbehebung bei der Anzeige

Wenn Trigger In-App Message-Zeilen in den Event-Nutzerprotokollen erscheinen, aber nichts auf dem Gerät angezeigt wird, wählen Sie Ihren SDK-Tab für Anzeige-Prüfungen (Delegates, Rate-Limits, Ausrichtung und angepasste Handler).

• web
• android
• swift

1
NFX.sharedInstance().ignoreURLs(["https://cdn.braze.com"])

1
[NFX.sharedInstance ignoreURLs:@[@"https://cdn.braze.com"]];

1
NetGuard.blackListHosts.append(contentsOf: ["cdn.braze.com"])

1
2
3
NSMutableArray<NSString *> *blackListHosts = [NetGuard.blackListHosts mutableCopy];
[blackListHosts addObject:@"cdn.braze.com"];
NetGuard.blackListHosts = blackListHosts;

1
2
let brazeAssetsHostFilter = XNHostFilter(host: "https://cdn.braze.com")
XNLogger.shared.addFilters([brazeAssetsHostFilter])

1
2
XNHostFilter *brazeAssetsHostFilter = [[XNHostFilter alloc] initWithHost: @"https://cdn.braze.com"];
[XNLogger.shared addFilters:@[brazeAssetsHostFilter]];