Zum Inhalt springen

Diese Seite wurde automatisch übersetzt und kann Ungenauigkeiten enthalten. Um einen Übersetzungsfehler zu melden, nutzen Sie das Feedback unten im Inhaltsverzeichnis rechts auf der Seite.

Wiederholungslogik für Connected-Content verwenden

Auf dieser Seite erfahren Sie, wie Sie Ihren Connected-Content-Aufrufen Wiederholungsversuche hinzufügen.

So funktionieren Wiederholungsversuche

Connected-Content ist darauf angewiesen, Daten von APIs zu empfangen. Daher kann es vorkommen, dass eine API vorübergehend nicht verfügbar ist, während Braze den Aufruf durchführt. Für diesen Fall unterstützt Braze eine Retry-Logik, die die Anfrage mit exponentiellem Backoff erneut versucht.

Hinweis

Connected-Content :retry ist für In-App-Nachrichten und Banner nicht verfügbar.

Retry-Verhalten in Canvas-Schritten

Connected-Content-Aufrufe in einem Canvas werden nur dann wiederholt, wenn der Aufruf :retry enthält. Das Verhalten unterscheidet sich je nach Schritttyp:

Nachrichten-Schritte: Connected-Content mit :retry nutzt weiterhin die Messaging-Pipeline. Empfänger:innen werden in der Sende-Warteschlange zurückgehalten, während Braze den Aufruf bis zu fünfmal wiederholt. Schlagen alle Wiederholungsversuche fehl, wird die Nachricht abgebrochen und Nutzer:innen gehen zum nächsten Schritt über. Weitere Details finden Sie unter Wenn der API-Aufruf fehlschlägt und Wiederholungsversuche aktiviert sind.
Kontext- und Nutzer-Update-Schritte: Braze wiederholt den Connected-Content-Aufruf auf Schrittebene (bis zu fünfmal). Schlagen alle Wiederholungsversuche fehl, verlassen Nutzer:innen das Canvas.

Bei Kontext- und Nutzer-Update-Schritten können bestimmte wiederholbare Schrittfehler, etwa ein fehlgeschlagener Abruf eines Promo-Codes oder ein unerwarteter Schrittfehler, zusätzliche Wiederholungsversuche auf Schrittebene mit exponentiellem Backoff auslösen (ungefähr 13-mal), bevor Braze die Nutzer:innen aus dem Canvas entfernt.

Weitere Informationen finden Sie unter Retry-Verhalten.

Retry-Logik verwenden

Um die Retry-Logik zu verwenden, fügen Sie dem Connected-Content-Aufruf den Tag :retry hinzu, wie im folgenden Code-Snippet gezeigt:

{% connected_content https://yourwebsite.com/api/endpoint :retry %}
{% connected_content https://www.braze.com :save my_content :basic_auth auth_name :retry %}

Wenn der Connected-Content-Aufruf einen :retry-Tag enthält, versucht Braze, den Aufruf bis zu fünfmal zu wiederholen.

Verhalten in der Vorschau

Die Retry-Logik gilt nur für Live-Versendungen (einschließlich Testversendungen), nicht für Nachrichten-Vorschauen oder die Vorschau von Nutzerpfaden. Wenn ein Connected-Content-Aufruf mit :retry fehlschlägt, wiederholt Braze den Aufruf nicht. Stattdessen gilt:

In der Nachrichten-Vorschau wird möglicherweise „This message would not have been shown because retry functionality was triggered“ angezeigt, anstatt den Inhalt zu rendern.
In der Vorschau von Nutzerpfaden zeigt ein Nachrichten-Schritt möglicherweise „Message aborted due to connected content retry failure“ an.

Dies ist das erwartete Verhalten und weist nicht auf ein Problem in Braze hin.

Ergebnisse von Wiederholungsversuchen

Wenn ein Wiederholungsversuch erfolgreich ist

Ist ein Wiederholungsversuch erfolgreich, wird die Nachricht versendet und für diese Nachricht werden keine weiteren Wiederholungsversuche unternommen.

Wenn der API-Aufruf fehlschlägt und Wiederholungen aktiviert sind

Schlägt der API-Aufruf fehl und ist diese Option aktiviert, wiederholt Braze den Aufruf und berücksichtigt dabei das Rate-Limit, das Sie für jeden erneuten Versand festgelegt haben. Braze verschiebt fehlgeschlagene Nachrichten an das Ende der Warteschlange und fügt bei Bedarf zusätzliche Minuten zur Gesamtdauer hinzu, die der Versand Ihrer Nachricht benötigt.

Schlägt der Connected-Content-Aufruf mehr als fünfmal fehl, wird die Nachricht abgebrochen – ähnlich wie beim Auslösen eines Abbruch-Tags für Nachrichten.

Connected-Content-Aufrufe mit Abbruch- und Wiederholungslogik

Wenn ein Connected-Content-Aufruf Abbruchlogik für dieselbe Bedingung wie die Wiederholungslogik verwendet, hat die Abbruchlogik Vorrang. Dadurch werden keine Wiederholungsversuche unternommen. Die Wiederholungslogik sendet den Aufruf bereits erneut, bevor sie ihn abbricht, wenn der Statuscode nicht erfolgreich ist. Da beide auf dasselbe Statuscode-Verhalten abzielen, können Sie die Abbruchlogik entfernen, und der Aufruf wird trotzdem abgebrochen, wenn alle Wiederholungsversuche fehlschlagen.

New Stuff!