Connected-Content-Debugger
Verwenden Sie den Connected-Content-Debugger, um die Live-Anfrage und -Antwort für jeden Connected-Content-Aufruf anzuzeigen. So können Sie Ihren Endpunkt, Ihre Header und Ihre Liquid-Tags überprüfen, bevor Sie eine Campaign oder ein Canvas starten.
Über den Debugger
Connected-Content ermöglicht es Ihnen, Nachrichten mit Echtzeitdaten anzureichern, indem zur Renderzeit ein HTTP-Aufruf an eine externe API erfolgt und die Antwort dann per Liquid in Ihre Nachricht eingefügt wird. Da dieser Aufruf außerhalb von Braze stattfindet, kann es schwierig sein, genau zu sehen, welche Anfrage Braze gesendet hat, was der Endpunkt zurückgegeben hat oder warum ein Aufruf fehlgeschlagen ist – bevor eine Campaign oder ein Canvas live ist.
Der Connected-Content-Debugger hilft bei der Fehlerbehebung dieser Probleme vor dem Start. Er zeigt Ihnen die Live-Anfrage und -Antwort für jeden Connected-Content-Aufruf in Ihrer Nachricht im Bereich Vorschau & Test an. So können Sie bestätigen, dass Ihr Endpunkt, Ihre Header und Ihre Liquid-Tags korrekt konfiguriert sind – alles direkt im Braze-Dashboard.
Unterstützte Bereiche
Der Connected-Content-Debugger ist für die folgenden Bereiche verfügbar:
- Banner
- Canvas-Kontextschritte
- Content Cards
- E-Mail
- Einschließlich Templates
- Ausgenommen Fußzeilen und Abo-Seiten
- In-App-Nachrichten
- Push-Benachrichtigungen
- SMS/MMS/RCS
- Webhooks
- Einschließlich Templates
Der Debugger ist für die meisten Kanäle verfügbar, jedoch noch nicht für KakaoTalk, LINE oder kanalunspezifische Kompositionsoberflächen (wie Content Blocks und den Canvas-Nutzer:innen-Update-Schritt). Wenn Sie den Debugger nicht sehen, wird das Connected-Content-Debugging für dieses Feature möglicherweise noch nicht unterstützt.
Debugger verwenden
Jedes Mal, wenn Sie eine Vorschau ausführen, rendert Braze automatisch die Ergebnisse der Connected-Content-Aufrufe im Tab Vorschau. So verwenden Sie den Debugger:
- Konfigurieren Sie Ihre Nachricht mit dem
{% connected_content %}-Tag. - Gehen Sie zum Abschnitt Vorschau & Test. Wenn Ihre Nachricht ein Connected-Content-Tag enthält, sehen Sie eine Zusammenfassung mit der Anzahl der Connected-Content-Aufrufe sowie den Erfolgs- und Fehlerstatus.
- Wählen Sie Details anzeigen aus, um den Debugger neben Ihrer Vorschau zu öffnen. Das Drawer-Fenster zeigt eine Tabelle mit der URL und dem Ergebnis für jeden Connected-Content-Aufruf an.
- Wählen Sie neben jeder URL und jedem Ergebnis Anzeigen aus, um die Anfrage- und Antwort-Header, den Payload, die Methode, die Dauer und Caching-Informationen einzusehen.
- Überprüfen Sie die Ergebnisse und passen Sie Ihr Tag, Ihre Header oder Ihren Endpunkt nach Bedarf an. Erstellen Sie dann eine neue Vorschau, um die Korrektur zu bestätigen.
Wenn Ihr Template mehr als ein {% connected_content %}-Tag enthält, listet der Debugger jeden ausgeführten Aufruf auf. Bei Kanälen, die mehrere Nachrichtentexte aus einem Template rendern (zum Beispiel E-Mail, die separate HTML-, Klartext- und AMP-Texte rendert, oder Quick Push, das separate gerätespezifische Texte rendert), zeigt der Debugger jeden Connected-Content-Aufruf über alle Texte hinweg an – nicht nur den, den Sie gerade in der Vorschau anzeigen.
Debug-Ausgabe verstehen
Jeder Connected-Content-Aufruf wird mit eigenen Tabs Response und Request angezeigt. Der Tab Response wird standardmäßig angezeigt, da er in der Regel der erste Indikator ist, ob ein Aufruf erfolgreich war.
URL-Details
| Feld | Beschreibung |
|---|---|
| URL | Die vollständig gerenderte URL, die Braze aufgerufen hat, mit allen aufgelösten Liquid-Tags. |
| Method | Die verwendete HTTP-Methode (GET oder POST). |
| Statuscode | Der HTTP-Statuscode, den Ihr Endpunkt zurückgegeben hat (zum Beispiel 200, 404, 500). Unter Fehlerbehebung bei Antwortcodes finden Sie Braze-spezifische Codes. |
Tab „Response“
| Feld | Beschreibung |
|---|---|
| Duration | Wie lange die Anfrage bis zum Abschluss gedauert hat, in Sekunden. Die Dauer wird nur für Live-Aufrufe (nicht zwischengespeichert) angezeigt. |
| Served from cache | Gibt an, ob diese Antwort aus dem Connected-Content-Cache von Braze bereitgestellt wurde, anstatt einen Live-Aufruf an Ihren Endpunkt zu senden (Yes oder No). Ein zwischengespeichertes Ergebnis spiegelt eine frühere Antwort wider, nicht unbedingt den aktuellen Zustand Ihres Endpunkts. |
| Response body | Der von Ihrem Endpunkt zurückgegebene Inhalt (Body). |
Tab „Request“
| Feld | Beschreibung |
|---|---|
| Headers | Header aus Ihrem Connected-Content-Tag (:headers, Zugangsdaten und Optionen wie :content_type). |
| Body | Der gesendete Anfrage-Body, falls vorhanden (POST-Anfragen). |
Welche Anfrage-Header im Debugger angezeigt werden
Der Tab Request listet Header aus Ihrem Connected-Content-Tag auf: angepasste :headers, gespeicherte Zugangsdaten und Header, die durch Tag-Optionen wie :content_type und :basic_auth gesetzt werden. Braze fügt der ausgehenden Anfrage an Ihren Endpunkt außerdem Standard-Header hinzu (zum Beispiel User-Agent und Host). Diese von Braze hinzugefügten Header erscheinen im Debugger, wenn Sie sie in :headers setzen.
Um einen konsistenten User-Agent zu senden, setzen Sie ihn in :headers. Braze verwendet Ihren Wert, und der Debugger zeigt diesen Header an.
Braze fügt ausgehenden Connected-Content-Anfragen die folgenden Header hinzu. Die meisten werden nur gesetzt, wenn Sie sie nicht bereits im Tag angegeben haben. Header, die Sie über :headers, Zugangsdaten oder Tag-Optionen bereitstellen, werden wie angegeben gesendet.
| Header | Wann Braze ihn setzt |
|---|---|
User-Agent |
Wenn Sie ihn nicht bereits gesetzt haben, sendet Braze Braze Sender <version>. Der Versions-String kann sich ändern. Wenn Sie Traffic nach User-Agent filtern, lassen Sie alle Werte zu, die mit Braze Sender beginnen. Um einen konsistenten Wert zu senden, setzen Sie User-Agent in :headers. |
X-Braze-Sender-Version |
Wird immer auf die Connected-Content-Sender-Version gesetzt. |
Accept-Encoding |
Wenn Sie ihn nicht bereits gesetzt haben, sendet Braze gzip. |
Authorization |
Wenn die URL einen Nutzernamen und ein Passwort enthält (user:pass@host), fügt Braze einen Basic-Authorization-Header hinzu, der aus diesen Zugangsdaten abgeleitet wird. Ein expliziter Authorization-Header überschreibt ihn. Bevorzugen Sie :basic_auth oder :headers, anstatt Zugangsdaten in die URL einzufügen. |
Host |
Hostname aus der Anfrage-URL (zum Beispiel www.example.com für https://www.example.com/abc/123), sofern Sie keinen Host-Header gesetzt haben. |
Content-Length |
Größe des Anfrage-Bodys in Bytes, wenn ein Body vorhanden ist. |
BrazeToBraze |
Wird nur für Anfragen an Braze-REST-Endpunkte auf true gesetzt. Wird für andere Ziele weggelassen. |
Bereinigung von Zugangsdaten
Wenn Ihr Connected-Content-Tag :basic_auth, gängige geheime Header, Schlüssel oder andere Optionen für Authentifizierungszugangsdaten verwendet, werden diese Werte vom Debugger im Tab Request bereinigt und durch eine Reihe von Sternchen (*) ersetzt. So können Sie bestätigen, dass Zugangsdaten in der Anfrage enthalten waren, ohne die Werte in Preview & Test offenzulegen.
Authentifizierungsfehler sind auch dann sichtbar, wenn Zugangsdaten bereinigt wurden: Wenn Ihr Endpunkt einen 401- oder 403-Statuscode zurückgibt, wird dieser im Tab Response normal angezeigt. So erkennen Sie, dass Ihre Anfrage aufgrund der Authentifizierung abgelehnt wurde, obwohl die Zugangsdaten selbst verborgen sind.
Fehlerbehebung bei Antwortcodes
Endpunktfehler versus von Braze auferlegte Limits
Nicht jeder Statuscode, der nicht 2XX lautet, im Tab Response stammt von Ihrem Endpunkt. Braze erzwingt eigene Limits für Connected-Content-Aufrufe, und diese können Antworten erzeugen, die einem Endpunktfehler ähneln.
Wenn Sie Antwortcodes wie 408, 429, 502, 503, 504 oder 599 sehen, liegt das Problem in der Regel auf der Braze-Seite des Aufrufs – im Zusammenhang mit der Host-Verfügbarkeit, Timeouts oder der Payload-Größe. Wenn Ihr Endpunkt regelmäßig große Antworten zurückgibt, sollten Sie erwägen, die Antwort-Payload auf die Felder zu reduzieren, die Ihre Nachricht tatsächlich benötigt.
Endpunkt hat einen unerwarteten Statuscode zurückgegeben
Verwenden Sie den Tab Request, um die URL, die Header aus Ihrem Tag und den Body zu überprüfen. Eine häufige Ursache für unerwartete 4XX-Antworten ist ein Liquid-Tag in der URL, den Headern oder dem Body, der nicht wie erwartet aufgelöst wurde. Stellen Sie sicher, dass alle {{ }}-Referenzen auf Felder verweisen, die für die Nutzer:in oder den Kontext existieren, mit dem Sie die Vorschau anzeigen.
Antwort scheint veraltet
Überprüfen Sie Served from cache im Tab Response. Wenn dort Yes angezeigt wird, zeigt der Debugger eine zuvor zwischengespeicherte Antwort an, anstatt einen neuen Aufruf durchzuführen. Fügen Sie Ihrem Tag vorübergehend :no_cache hinzu oder warten Sie, bis der Cache abläuft (gemäß :cache_max_age), um das aktuelle Endpunktverhalten zu bestätigen.