Ein D2C-Team will ein Segment bauen. Die Anforderung klingt überschaubar: Kunden, die in den letzten 90 Tagen mindestens zwei Käufe mit einem durchschnittlichen Warenkorbwert über 80 Euro getätigt haben und dabei mindestens ein Produkt aus der Kategorie “Premium” gekauft haben.
Standard-Segmentierung, sollte man meinen.
Das Team auf Klaviyo öffnet den Segment Builder, wählt “Placed Order” als Metric, setzt die Häufigkeit auf mindestens zwei in 90 Tagen, fügt einen Filter auf die Event-Property “ProductCategory equals Premium” hinzu. Soweit funktioniert das. Aber der durchschnittliche Warenkorbwert über mehrere Bestellungen hinweg ist keine native Property am Event. Das Team müsste entweder eine berechnete Custom Property anlegen, die per API regelmäßig aktualisiert wird, oder die Bedingung über einen Umweg abbilden.
Das Team auf Braze geht einen anderen Weg. Kaufhäufigkeit lässt sich über Custom Events mit einem Filter auf die letzten 90 Tage abfragen. Die Produktkategorie lebt als Custom Event Property. Aber der durchschnittliche Warenkorbwert ist auch hier kein nativer Segmentierungsfilter auf Event-Ebene. Das Team muss den Wert als Custom Attribute am Profil speichern und separat berechnen lassen.
Beide Teams kommen ans Ziel. Aber beide brauchen Workarounds. Und die Art der Workarounds unterscheidet sich fundamental, weil die Profilarchitekturen unterschiedlich gebaut sind.
Klaviyo: Profile als flache Key-Value-Struktur
Klaviyo speichert Profildaten als Key-Value-Paare direkt am Profil. Vorname, E-Mail, Custom Properties wie “Lieblingsfarbe” oder “Mitgliedschaftsstatus”. Das können Strings, Zahlen, Booleans, Daten oder Listen sein. Die Struktur ist flach: Ein Profil hat Properties, und diese Properties sind direkt im Segment Builder verfügbar.
Events, in Klaviyo Metrics genannt, leben neben dem Profil. Jedes Event hat einen Zeitstempel und eigene Properties. “Placed Order” hat Properties wie “Value”, “ItemCount”, “Categories”. Der Segment Builder kann auf diese Events zugreifen: “Hat Placed Order mindestens 2 mal in den letzten 90 Tagen, wobei Categories contains Premium.”
Das funktioniert, solange die Bedingungen innerhalb eines Event-Typs bleiben. Sobald ihr Bedingungen über mehrere Event-Typen hinweg kombinieren wollt, wird es enger. “Hat Placed Order mit Category Premium UND hat Viewed Product mit Category Sale in den letzten 30 Tagen” ist möglich. Aber “Hat Placed Order, wobei der Durchschnittswert aller Orders über 80 Euro liegt” erfordert eine Berechnung, die Klaviyos Segmentierung nicht nativ leistet.
Die Konsequenz: Teams legen berechnete Custom Properties an. “Average Order Value”, “Total Spend 90d”, “Premium Purchase Count”. Diese Properties müssen extern berechnet und per API oder Integration zurückgeschrieben werden. Manche Teams nutzen dafür Klaviyos eigene berechnete Properties, wo verfügbar. Andere setzen auf Drittanbieter wie Zapier, Make oder eigene Skripte. In beiden Fällen entsteht eine Abhängigkeit: Das Segment ist nur so aktuell wie die letzte Berechnung.
In unseren Audits sehen wir regelmäßig Profile mit 20, 30 oder mehr Custom Properties, von denen die Hälfte berechnete Werte sind, die nicht mehr zuverlässig aktualisiert werden. Das Segment “High-Value Premium Buyers” existiert, aber die Daten dahinter sind zwei Wochen alt. Das Team merkt es nicht, weil die Segmentgröße plausibel aussieht.
Braze: Drei Datenebenen mit eigener Logik
Braze trennt Profildaten in drei Schichten. Custom Attributes sind profilgebunden und persistent: Mitgliedschaftsstatus, Lieblingsmarke, berechneter CLV. Custom Events sind verhaltensgebunden und zeitgestempelt: “Purchase” mit Properties wie Produktkategorie, Warenkorbwert, Zahlungsmethode. Connected Content holt Daten zur Renderzeit von externen APIs.
Für die Segmentierung sind die ersten beiden Schichten relevant. Custom Attributes stehen direkt im Segment Builder zur Verfügung. Custom Events können über Filter abgefragt werden: “Hat Event X mindestens Y mal in den letzten Z Tagen ausgeführt.” Event-Properties können dabei als Filter dienen.
Die Stärke dieses Modells: Attribute und Events sind sauber getrennt. Ihr wisst immer, ob ein Datenpunkt ein persistentes Profilmerkmal ist oder ein zeitgebundenes Verhalten. Das macht die Datenarchitektur nachvollziehbar.
Die Grenze: Wenn ihr in der Segmentierung Attribute und Event-Properties kombinieren wollt, stöpert die Logik. “Kunden mit Custom Attribute VIP-Status UND Custom Event Purchase mit Property Category Premium in den letzten 90 Tagen” funktioniert. Aber “Kunden, deren durchschnittlicher Warenkorbwert aus Custom Events über 80 Euro liegt” erfordert, dass dieser Wert als Custom Attribute vorberechnet am Profil liegt. Die Segmentierung greift nicht in die Event-Properties hinein und rechnet dort.
Das führt zum gleichen Muster wie bei Klaviyo, nur mit anderer Mechanik: Teams duplizieren Event-Daten als Attributes. “Last Purchase Category”, “AOV 90d”, “Purchase Count Q1”. Jedes duplizierte Attribut muss synchron gehalten werden, per Webhook, per Backend-Job oder per Braze-eigenem Data Transformation. Wer zusätzlich Connected Content einsetzt, holt zwar externe Daten in Echtzeit, aber nur zur Renderzeit in Nachrichten. Für die Segmentierung steht Connected Content nicht zur Verfügung.
Wo beide Architekturen an Grenzen stoßen
Die Segmentierungsgrenzen beider Plattformen werden bei drei Anforderungstypen sichtbar.
Erstens: Aggregierte Bedingungen über Events. “Durchschnittlicher Warenkorbwert”, “Gesamtausgaben in den letzten 90 Tagen”, “Anzahl verschiedener Produktkategorien im Kaufverlauf”. Beide Plattformen können einzelne Events zählen und filtern. Aber Aggregationen über Event-Properties, Durchschnitte, Summen, Distinct Counts, erfordern vorberechnete Werte.
Zweitens: Cross-Event-Bedingungen. “Hat Produkt angesehen UND dasselbe Produkt nicht gekauft.” Das setzt voraus, dass die Segmentierung zwei Event-Typen miteinander verknüpfen und auf Property-Ebene abgleichen kann. Klaviyo kann das über geschickte Segment-Bedingungen teilweise abbilden, aber die Property-Verknüpfung zwischen Events ist nicht beliebig tief. Braze kann Events einzeln filtern, aber der Abgleich auf Property-Ebene zwischen zwei verschiedenen Event-Typen ist nativ nicht vorgesehen.
Drittens: Zeitfenster-Kombinationen. “Hat in den letzten 30 Tagen gekauft, aber in den 30 Tagen davor nicht.” Beide Plattformen unterstützen Zeitfenster-Filter. Aber die Kombination von “hat in Zeitfenster A” und “hat nicht in Zeitfenster B” kann in der Segment-Builder-Logik zu unerwarteten Ergebnissen führen, wenn die Bedingungen nicht präzise konfiguriert sind. Wer Lifecycle-Stages mit sauberen Exit-Kriterien bauen will, braucht genau solche Zeitfenster-Kombinationen.
Workarounds und ihre versteckten Kosten
Die Antwort auf Segmentierungsgrenzen sind Workarounds. Und Workarounds haben Kosten, die selten eingeplant werden.
In Klaviyo sehen wir berechnete Properties, die per Webhook oder Cron-Job aktualisiert werden. Die Berechnung läuft täglich, manchmal stündlich. Aber was passiert, wenn der Job ausfällt? Oder wenn sich die Berechnungslogik ändert, aber alte Properties nicht neu berechnet werden? Das Segment liefert weiter Ergebnisse. Es liefert nur die falschen.
In Braze sehen wir duplizierte Attributes, die Event-Daten spiegeln. “Last Purchase Date” als Attribut, obwohl das letzte Purchase-Event dieselbe Information trägt. Der Grund: Die Segmentierung braucht den Wert als Attribut, nicht als Event-Property. Aber jetzt existiert dieselbe Information an zwei Stellen. Wenn der Backend-Job, der die Attribute aktualisiert, hinterherhinkt, weichen Attribut und Event voneinander ab. Das Segment basiert auf dem Attribut, das Event erzählt eine andere Geschichte.
In beiden Plattformen führen Workarounds dazu, dass die Datenintegrität schleichend erodiert. Nicht dramatisch, nicht sofort sichtbar. Aber nach sechs Monaten mit 15 berechneten Properties oder 20 duplizierten Attributes hat das Team eine Datenschicht aufgebaut, deren Zuverlässigkeit niemand mehr vollständig überprüfen kann. Ein Muster, das wir ähnlich bei Custom Events beschrieben haben: Datenstrukturen, die angelegt, aber nicht gepflegt werden.
Was ihr daraus mitnehmt
Dieser Vergleich sagt nicht, welche Profilarchitektur besser ist. Beide funktionieren. Beide haben Grenzen. Die Frage ist, ob ihr die Grenzen eurer Plattform kennt und bewusst damit umgeht.
Ein Check für Klaviyo-Teams: Listet alle Custom Properties auf, die berechnete Werte enthalten. Prüft, ob die Berechnung noch läuft und ob die Ergebnisse aktuell sind. Wenn ihr Properties findet, die seit Wochen nicht aktualisiert wurden, basieren eure Segmente auf veralteten Daten.
Ein Check für Braze-Teams: Listet alle Custom Attributes auf, die Event-Daten spiegeln. Prüft, ob Attribut und Event übereinstimmen. Wenn der “Last Purchase Date”-Attribut vom letzten Purchase-Event abweicht, habt ihr ein Synchronisationsproblem, das eure Segmentierung verzerrt.
Für beide Plattformen: Identifiziert die Segmente, die ihr gerne bauen würdet, aber nicht baut, weil die Architektur es erschwert. Diese nicht gebauten Segmente sind eure strategischen blinden Flecken. Nicht weil das Tool schlecht ist, sondern weil jede Architektur Grenzen hat, die man kennen sollte. Wer den Canvas-vs.-Flows-Vergleich gelesen hat, kennt das Prinzip: Die Struktur des Tools formt die Strategie. Bei Profilen und Segmenten gilt dasselbe.
Wenn ihr wissen wollt, ob eure Profilarchitektur und Segmentierungslogik sauber aufgestellt sind oder auf fragilen Workarounds basieren: Dafür gibt es unseren Instanz-Check.
