Zwei CRM-Teams, ähnliches Setup. E-Commerce, rund 200.000 Kontakte, Onboarding-Serie mit drei Mails. Das eine Team arbeitet auf Braze, das andere auf Klaviyo. Beide liefern nach dem Launch solide Ergebnisse: Öffnungsraten über 40 Prozent, Conversion im erwarteten Bereich.
Sechs Monate später sehen die Setups völlig unterschiedlich aus.
Das Braze-Team hat den Canvas um sieben Varianten erweitert, mit verschachtelten Audience Paths nach Kaufverhalten, Gerätetyp und Engagement-Score. Das Reporting zeigt Zahlen, aber nur noch der ursprüngliche Ersteller versteht, welcher Pfad was bewirkt. Das Klaviyo-Team hat vier parallele Flows angelegt: einen für Erstkäufer, einen für Browse-Abandoner, einen für High-Value-Kunden und den ursprünglichen Onboarding-Flow. Drei davon sprechen teilweise dieselben Nutzer an und kommen sich bei der Frequenz in die Quere.
Beide Teams haben ein Problem. Und in beiden Fällen liegt die Ursache nicht im Skill der Leute, sondern in der Architektur des Tools.
Canvas: Schritte mit Varianten als Grundprinzip
Ein Braze Canvas besteht aus Steps. Jeder Step kann ein Message Step sein, ein Audience Path, ein Experiment Path, ein Action Path oder ein Delay. Der Nutzer tritt in den Canvas ein und wird an jedem Entscheidungspunkt in einen Pfad geleitet. Das Grundprinzip ist Verzweigung.
Audience Paths splitten auf beliebigen Attributen und Events. Experiment Paths randomisieren zwischen Varianten mit statistischer Auswertung. Action Paths reagieren auf Nutzerverhalten in Echtzeit. Jeder dieser Bausteine kann verschachtelt werden. Ein Canvas kann dadurch eine gesamte Lifecycle-Phase abbilden, vom ersten Kontakt bis zur Reaktivierung, in einer einzigen Struktur.
Das ist mächtig. Es ist auch eine Einladung zur Komplexität.
In der Praxis sehen wir immer wieder dasselbe Muster: Canvas-Teams fügen Pfade hinzu, statt neue Canvases zu erstellen. Jede neue Anforderung wird als Audience Path oder Experiment Path in die bestehende Struktur integriert. Nach ein paar Monaten hat der Canvas fünf oder sechs Ebenen von Verschachtelungen. Die Exit-Conditions sind schwer nachvollziehbar, weil sie auf Canvas-Ebene gelten, aber die Pfad-Logik auf Step-Ebene lebt. Und das Debugging wird zum Detektivspiel: Warum hat dieser Nutzer Step 3 erreicht, aber Step 4 nicht? War es der Audience Path, der Exit Event oder der Timing-Delay?
Das ist kein Fehler im Tool. Es ist die logische Konsequenz einer Architektur, die Verzweigung als Grundprinzip hat. Canvas belohnt Komplexität innerhalb einer Struktur. Und CRM-Teams folgen diesem Anreiz, oft ohne es zu merken.
Flows: Trigger und Sequenzen als Grundprinzip
Ein Klaviyo Flow beginnt mit einem Trigger. Metric Trigger, List Trigger, Segment Trigger, Date Trigger, Price Drop Trigger. Danach folgt eine Sequenz: Actions, Time Delays, Conditional Splits, Trigger Splits. Die Grundbewegung ist linear. Von oben nach unten.
Conditional Splits fügen Logik hinzu. Ihr könnt nach Attributen, Events, Listzugehörigkeit oder Profilmerkmalen splitten. Trigger Splits segmentieren nach Eigenschaften des auslösenden Events. Aber die mentale Struktur bleibt: Ein Auslöser, eine Sequenz, Abzweigungen wo nötig.
Das ist intuitiv. Es ist auch eine Einladung zur Proliferation.
In der Praxis sehen wir: Flow-Teams erstellen für jeden Use Case einen neuen Flow. Onboarding, Winback, Browse Abandonment, Post-Purchase, Sunset, Geburtstag. Jeder Flow ist für sich genommen sauber aufgebaut. Aber niemand hat den Überblick, welche Flows sich überschneiden. Ein Nutzer, der seit zwei Wochen nicht gekauft hat, kann gleichzeitig im Winback-Flow, im Browse-Abandonment-Flow und in einer Kampagne stecken. Klaviyos Smart Sending schützt vor zu vielen Mails in kurzer Zeit, aber das ist ein globaler Timer, keine inhaltliche Orchestrierung. Smart Sending verhindert, dass jemand drei Mails am selben Tag bekommt. Es verhindert nicht, dass jemand drei thematisch widersprüchliche Mails in einer Woche erhält.
Das ist kein Fehler im Tool. Es ist die logische Konsequenz einer Architektur, die pro Use Case einen eigenen Trigger vorsieht. Flows belohnen Granularität auf Flow-Ebene. Und CRM-Teams folgen diesem Anreiz, oft ohne es zu merken.
Wo die Modelle bei Skalierung kollidieren
Die strategischen Unterschiede werden bei wachsender Komplexität sichtbar.
Ein Canvas-Team, das nach zwölf Monaten zehn Canvases mit je fünf bis acht Audience Paths betreibt, hat ein Wartungsproblem. Änderungen an der Segmentierungslogik müssen in jedem Canvas einzeln angepasst werden. Die Variant-Ergebnisse sind schwer interpretierbar, weil die Kombinationseffekte zwischen Audience Paths und Experiment Paths die Stichproben fragmentieren. Und neue Teammitglieder brauchen Wochen, um die Canvas-Architektur zu verstehen. Wer Connected Content in diese verschachtelten Canvases einbaut, addiert eine weitere Fehlerquelle pro Pfad.
Ein Flow-Team, das nach zwölf Monaten dreißig Flows betreibt, hat ein Orchestrierungsproblem. Kein einzelner Flow ist zu komplex, aber die Gesamtheit der Flows erzeugt Konflikte. Flows, die auf ähnliche Trigger reagieren, können sich gegenseitig auslösen oder blockieren. Die Flow-übergreifende Analyse fehlt: Klaviyo zeigt Performance pro Flow, aber nicht die Journey eines einzelnen Nutzers über alle Flows hinweg. Und die Frage “Was passiert mit einem Nutzer, der gleichzeitig in drei Flows ist?” lässt sich nur manuell beantworten.
Beide Skalierungsprobleme sind vorhersehbar. Aber sie fallen erst auf, wenn sie da sind.
Reporting: Unterschiedliche blinde Flecken
Canvas Reporting zeigt Conversion auf Canvas-Ebene und auf Variant-Ebene. Experiment Paths liefern statistische Signifikanz zwischen Varianten. Das ist stark für A/B-Testing innerhalb eines Canvas. Aber sobald mehrere verschachtelte Audience Paths existieren, wird die Frage “Welcher Pfad performt?” schwer beantwortbar. Die Aggregation bildet Pfad-Kombinationen nicht ab. Wer verstehen will, wie der Pfad “Erstkäufer, iOS, Engagement-Score hoch” im Vergleich zu “Wiederkäufer, Android, Engagement-Score mittel” performt, muss die Daten exportieren und extern auswerten. Das führt dazu, dass Canvas-Teams oft weniger Insights aus ihren Experimenten ziehen, als die Architektur eigentlich erlaubt. Ein Problem, das wir auch beim A/B-Testing generell beschrieben haben.
Klaviyo Flow Reporting zeigt Performance pro Step und pro Flow. Das ist granularer als Canvas Reporting auf Step-Ebene. Aber die fehlende Cross-Flow-Ansicht macht es schwer zu verstehen, wie sich mehrere Flows auf denselben Nutzer auswirken. Wenn die Conversion im Post-Purchase-Flow sinkt, liegt das am Flow selbst oder daran, dass derselbe Nutzer gerade eine Mail aus dem Browse-Abandonment-Flow erhalten hat und dort konvertiert ist? Diese Frage beantwortet Klaviyo nicht nativ.
Beide Reporting-Modelle erzeugen strategische blinde Flecken. Canvas-Teams wissen zu wenig über Pfad-Kombinationen. Flow-Teams wissen zu wenig über Cross-Flow-Effekte.
Was ihr daraus mitnehmt
Dieser Vergleich hat keine Empfehlung, welches Tool besser ist. Die gibt es nicht, weil die Antwort vom Kontext abhängt. Aber es gibt eine Empfehlung, die für beide Plattformen gilt: Macht euch bewusst, welche Strategie euer Tool nahelegt, und prüft, ob ihr dieser Logik bewusst folgt oder ihr unbewusst ausgeliefert seid.
Ein Check für Canvas-Teams: Öffnet eure Canvases und zählt die Verschachtelungsebenen. Wenn ein Canvas mehr als drei Ebenen von Audience Paths hat, fragt euch: Wäre das als zwei separate Canvases klarer? Könnte ein neues Teammitglied diesen Canvas in einer Stunde verstehen?
Ein Check für Flow-Teams: Listet alle aktiven Flows auf und markiert, welche auf ähnliche Trigger reagieren oder ähnliche Zielgruppen ansprechen. Wenn mehr als drei Flows potenziell denselben Nutzer erreichen, fragt euch: Gibt es eine bewusste Priorisierung? Oder entscheidet Smart Sending, welche Mail durchkommt?
Die Architektur eures Tools ist kein Schicksal. Sie ist ein Rahmen, den ihr aktiv gestalten könnt, wenn ihr seine Logik versteht. Wer die Welcome-Serie in Klaviyo oder die Push-Strategie in Braze optimieren will, profitiert davon, die Architektur dahinter zu kennen, nicht nur die Features.
Wenn ihr wissen wollt, ob eure Canvas- oder Flow-Architektur strategisch sauber aufgestellt ist: Dafür gibt es unseren Instanz-Check.
