So wechseln Sie von Braze

Lesen Sie das zuerst

Braze-Migrationen sind Engineering-Projekte, keine Marketing-Projekte — Ihr Braze-Wert steckt in SDK-Instrumentierung und Event-Pipelines, und genau das zieht tatsächlich um. Die gute Nachricht: Die Oberfläche von WeZend ist bewusst einfacher (reines REST, kein SDK erforderlich), das Ziel ist also weniger Code als der Ausgangspunkt.

Schritt 1 — Das Identitätsmodell mappen

Braze schlüsselt Nutzer über external_id; WeZend gleicht Kontakte über E-Mail/Telefon ab und akzeptiert Ihre eigenen IDs als benutzerdefinierte Felder. Legen Sie das Mapping vorab fest: Exportieren Sie external_id → E-Mail/Telefon-Paare und speichern Sie external_id als benutzerdefiniertes Feld (braze_external_id), damit historische Referenzen während des Übergangs nie ins Leere laufen.

Schritt 2 — Nutzer exportieren, Kontakte importieren

Exportieren Sie Ihre Nutzerbasis über die User-Export-APIs von Braze (segmentbezogene Exporte funktionieren gut — Segment für Segment exportieren, um die Herkunft zu erhalten). Globale Abmeldungen und E-Mail-Bounces kommen zuerst, in Zielgruppe → Sperrlisten — dieselbe eiserne Regel wie bei jeder Migration auf dieser Website. Importieren Sie danach Nutzer mit Attributen, die auf benutzerdefinierte Felder gemappt sind.

Schritt 3 — Den Event-Stream umleiten

Überall dort, wo Ihr Backend die Track-Endpunkte von Braze aufruft, rufen Sie stattdessen POST /v1/events auf — oder parallel während des Übergangs; Events zwei Wochen lang doppelt zu schreiben ist das sicherste Muster:

await fetch("https://api.wezend.com/v1/events", {
  method: "POST",
  headers: { "X-API-Key": process.env.WEZEND_API_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({
    contact: { email: user.email },
    event: "order_completed",
    properties: { value: 499, currency: "DKK" },
  }),
});

Halten Sie die Event-Namen identisch zu Ihrer Braze-Taxonomie — neu aufgebaute Segmente und Journeys lesen sich natürlich, und Ihre Analysten behalten ihr Vokabular.

Schritt 4 — Aus Canvases werden Journeys

Canvas-Schritte lassen sich direkt in Journey-Knoten übersetzen: Entry Rules → Trigger, Delay/Decision Split/Action Paths → Verzögerungs- und Verzweigungsknoten, Nachrichtenschritte → Sendeknoten (alle sechs Kanäle). Frequency Capping und Quiet Hours wandern von der Konfiguration je Canvas in eine plattformweite Versandrichtlinie — ein Ort, jeder Versand, kein Drift je Canvas.

Bauen Sie in der Reihenfolge des Umsatzes neu auf, melden Sie jede Journey testweise an und lassen Sie die Parallelphase entscheiden: Pausieren Sie ein Canvas erst, wenn sein Journey-Zwilling sauber auf echtem Traffic gelaufen ist.

Schritt 5 — Currents ersetzen

Wenn Currents Ihr Warehouse oder BI speist, ersetzen Sie es durch Warehouse-Sync (Profile + Events in Ihre eigene Datenbank) plus Zustellungs-Webhooks für Echtzeit-Konsumenten. Die meisten Teams stellen fest, dass diese beiden jeden Currents-Konsumenten abdecken, den sie tatsächlich hatten.

Was NICHT mitkommt

• Engagement-Historie der Nachrichten — exportieren Sie Berichte für Ihre Unterlagen; die WeZend-Analytics starten bei null.
• Brazes ML-Segmente (Predicted Churn usw.) — mit den integrierten prädiktiven Scores neu berechnen, sobald Events fließen; sie lassen sich genauso segmentieren.
• Content-Cards-Inhalte — als In-App-Postfach-Nachrichten neu erstellen; das Embed-Modell ist vergleichbar.