Ihr habt Connected Content eingerichtet, um jedem Kunden personalisierte Produktempfehlungen in der Mail zu zeigen. Die Vorschau im Dashboard sieht perfekt aus. Aber bei 3.000 von 60.000 Empfängern kommt die Mail mit leerem Produktblock an. Kein Fehler im Campaign Log. Kein Alert. Einfach leere Platzhalter, weil die API bei Spitzenlast nicht schnell genug geantwortet hat und der Fallback fehlt.
Was Connected Content verspricht und was es hält
Connected Content ist Brazes Ansatz für Echtzeit-Personalisierung. Bei jedem Versand wird ein API-Call an einen externen Endpunkt ausgelöst, der dynamische Daten zurückliefert: Produktempfehlungen, Lagerbestände, personalisierte Preise, Wetterdaten, was auch immer der Endpunkt hergibt. Der Content wird direkt in die Mail gerendert, per Liquid-Template.
Theoretisch brillant. In der Praxis fragil.
Das Problem ist nicht Connected Content selbst. Das Feature funktioniert, wie dokumentiert. Das Problem ist, dass die meisten Implementierungen nicht für den Ernstfall gebaut sind. Sie funktionieren in der Vorschau, sie funktionieren beim Testversand an 50 Empfänger. Aber bei einem Kampagnenversand an 100.000 Empfänger gelten andere Regeln. APIs antworten langsamer, Rate Limits greifen, Caching-Verhalten ändert sich. Und genau dort zeigen sich die Fehler, die im Test unsichtbar waren.
Wir sehen in Braze-Instanzen immer wieder dieselben fünf Muster.
Die fünf häufigsten Connected-Content-Fehler
Kein Fallback definiert. Braze gibt Connected-Content-Anfragen ein Standardtimeout von zwei Sekunden. Wenn die API nicht rechtzeitig antwortet, wird kein Retry ausgelöst. Der Block rendert leer, oder schlimmer: Liquid-Tags erscheinen im Klartext in der Mail. Die Lösung ist ein :default-Parameter im Connected-Content-Tag und ein {% if %}-Guard um den gesamten Block. Wer beides weglässt, riskiert bei jedem Versand, dass ein Teil der Empfänger kaputte Mails bekommt. In den Instanzen, die wir prüfen, fehlt der Fallback in mehr als der Hälfte aller Connected-Content-Implementierungen.
Rate Limits der Ziel-API ignoriert. Ein Versand an 100.000 Empfänger erzeugt tausende parallele API-Requests. Viele Empfehlungs-Engines und Produktkataloge verkraften 100 bis 500 Requests pro Sekunde. Braze selbst drosselt nicht automatisch auf die Kapazität des Endpunkts. Ohne serverseitiges Queueing oder eine Rate-Limit-Konfiguration im API-Gateway fallen Anfragen einfach weg. Das Team sieht im Dashboard eine erfolgreiche Kampagne, aber 5 bis 10 Prozent der Mails hatten leere Personalisierungsblöcke.
Caching-Defaults nie angepasst. Braze cached Connected-Content-Antworten standardmäßig für fünf Minuten. Bei dynamischen Daten wie Lagerbeständen oder Flash-Sale-Preisen kann das zu veralteten Inhalten führen. Bei statischen Daten wie Profilinformationen ist der Cache zu kurz und erzeugt unnötige API-Last. Die Cache-TTL lässt sich pro Connected-Content-Tag konfigurieren, aber die meisten Teams ändern den Standardwert nie, weil sie nicht wissen, dass er existiert.
Liquid-Fehler bei leeren Responses. Wenn die API ein leeres JSON zurückgibt oder das erwartete Feld fehlt, bricht Liquid nicht ab. Es rendert nichts oder zeigt den rohen Tag. Ein typisches Szenario: Die API liefert normalerweise ein Array mit drei Produkten. Unter Last antwortet sie mit einem leeren Array. Ohne Guard rendert der Block drei leere Platzhalter. Mit einem einfachen {% if connected.products.size > 0 %} wäre das verhindert, aber diese Guards werden selten gebaut, weil der Testversand immer funktioniert.
Kein Monitoring für partielle Fehler. Braze loggt Connected-Content-Errors im Message Activity Log, aber nur aggregiert. Es gibt keinen nativen Alert, der sagt: Bei dieser Kampagne hatten 8% der Mails leere Connected-Content-Blöcke. Teams merken das Problem erst, wenn Kunden sich beschweren oder wenn die Click Rate einer Kampagne unerklärlich einbricht. Zwischen Versand und Entdeckung vergehen oft Wochen.
Wie ein Debugging-Workflow aussieht
Wenn ihr den Verdacht habt, dass Connected Content Probleme macht, gibt es drei Stellen, an denen ihr anfangen könnt.
Das Message Activity Log in Braze zeigt Connected-Content-Fehler pro Nachricht. Filtert nach eurer Kampagne und sucht nach Einträgen mit „Connected Content” im Error-Feld. Die Fehlermeldungen sind oft kryptisch, aber die Häufigkeit allein ist aufschlussreich. Wenn bei einem Versand an 60.000 Empfänger 3.000 Fehler auftauchen, wisst ihr, dass etwas nicht stimmt.
Der Connected Content Tester in Braze erlaubt es, einen einzelnen API-Call zu simulieren. Nutzt ihn nicht nur mit eurer Test-User-ID, sondern mit verschiedenen Profilen. Manche Fehler treten nur bei bestimmten Datenkombinationen auf, etwa wenn ein Nutzer kein Kaufhistorie-Feld hat und die API deshalb anders antwortet.
Fallback-Ketten bauen heißt: Nicht nur einen Default-Wert setzen, sondern mehrere Ebenen. Wenn die API nicht antwortet, zeige den letzten gecachten Wert. Wenn kein Cache vorhanden ist, zeige einen generischen Produktblock. Wenn selbst das fehlschlägt, blende den gesamten Block aus, statt leeren Platz zu rendern. Das klingt aufwändig, ist aber in Liquid mit verschachtelten {% if %}-Blöcken in 20 Minuten umsetzbar.
Einen ähnlichen Debugging-Ansatz haben wir bereits bei Push-Notifications beschrieben, wo Konfigurationsfehler genauso unsichtbar bleiben, bis Nutzer reagieren.
Was ihr daraus mitnehmt
Fünf Punkte als Checkliste für jede Connected-Content-Kampagne:
Fallback definiert? Jeder Connected-Content-Block braucht einen :default-Parameter und einen {% if %}-Guard. Kein Block ohne Fallback in Produktion.
Cache-TTL angepasst? Dynamische Daten brauchen kurze TTLs oder gar keinen Cache. Statische Daten profitieren von längeren TTLs, die API-Last reduzieren.
Rate Limit des Endpunkts bekannt? Sprecht mit eurem API-Team. Wie viele Requests pro Sekunde verträgt der Endpunkt? Passt eure Versandgeschwindigkeit an oder baut ein API-Gateway mit Throttling dazwischen.
Liquid-Guards gebaut? Prüft auf leere Arrays, fehlende Felder und unerwartete Datentypen. Testet nicht nur mit eurem eigenen Profil, sondern mit Edge Cases.
Monitoring eingerichtet? Richtet einen wöchentlichen Check ein: Message Activity Log nach Connected-Content-Errors filtern. Wenn die Fehlerrate über 1% liegt, debuggen.
Connected Content ist kein Feature, das man einmal konfiguriert und dann vergisst. Es ist eine Live-Integration, die bei jedem Versand funktionieren muss. Wer die fünf Punkte oben prüft, bevor eine Kampagne live geht, verhindert die Fehler, die wir in fast jeder Braze-Instanz sehen. Wenn ihr wissen wollt, wie eure Connected-Content-Konfiguration aufgestellt ist: Dafür gibt es unseren Instanz-Check.
