Fachanalyse · Klaviyo & Shopdaten

Warum ein Warenkorbabbruch-Flow nicht mit der ersten E-Mail beginnt.

Ein Flow kann in Klaviyo perfekt aussehen und trotzdem die falschen Personen erreichen – oder gar nicht starten. Bevor wir über Betreff, Rabatt oder Versandzeit sprechen, muss die Kette davor stimmen: Shop-Aktion, Event, Profil, Consent-Signal und Flow-Logik.

René KlotzStand: 3. August 2026ca. 5 Minuten

Inhalt des Artikels

Die wichtigste Aussage

Bevor Inhalt oder Timing optimiert werden, sollten drei Dinge klar sein: Welches Signal startet den Flow? Zu welchem Profil gehört es? Und unter welchen Bedingungen darf eine Person hinein – oder muss wieder heraus?

Eine Shop-Aktion ist noch keine verlässliche Automation.

Ein Besucher legt ein Produkt in den Warenkorb. Aus Nutzersicht ist damit alles eindeutig. Technisch entstehen jedoch mehrere getrennte Fragen: Wurde die Aktion als Event erfasst? Welche Eigenschaften wurden mitgegeben? Ist das Event einem bekannten Profil zugeordnet? Liegt ein vorhandenes, technisch nutzbares Einwilligungssignal vor? Wurde der Kauf vielleicht bereits abgeschlossen? Und greifen Trigger, Filter und Ausschlüsse so, wie sie gedacht sind?

Fehlt nur eine dieser Verbindungen, kann ein Flow zu spät, doppelt oder gar nicht starten. Deshalb sollte eine Prüfung nicht beim E-Mail-Design beginnen, sondern bei der Kette, die vor dem Versand liegt.

Vier Ebenen gehören zusammen.

Event: Welches konkrete Verhalten wurde erfasst, wann ist es entstanden und welche Eigenschaften wurden mitgegeben?
Profil: Kann das Signal einer Person zugeordnet werden, oder bleibt es anonym beziehungsweise unvollständig?
Consent: Welches bereits vorhandene Einwilligungssignal wird technisch übergeben und wie beeinflusst es Profil-, Listen- oder Versandstatus?
Flow-Logik: Welche Trigger, Filter, Ausschlüsse, Zeitfenster und Abbruchbedingungen bestimmen den tatsächlichen Einstieg?

So lässt sich die Signalkette einfacher lesen.

Je nach Shopsystem sieht die Umsetzung anders aus. Für die Prüfung hilft trotzdem ein einfaches Modell mit sechs Stationen:

01
Shop-Aktion
Eine Person legt ein Produkt in den Warenkorb oder beginnt einen vergleichbaren Prozess.
02
Event
Die Aktion wird mit Zeitpunkt und den für die spätere Logik benötigten Eigenschaften erfasst.
03
Profilzuordnung
Das Signal wird einem bekannten Profil zugeordnet, soweit die technische Identifikation dies zulässt.
04
Vorhandenes Consent-Signal
Der technisch übergebene Status wird für Profil, Liste und mögliche Kommunikation nachvollzogen.
05
Flow-Einstieg
Trigger, Filter und Wartezeit entscheiden, ob und wann eine Person eintritt.
06
Ausschluss oder Abbruch
Ein späterer Kauf oder eine andere definierte Bedingung verhindert eine unpassende Nachricht.

Vereinfachtes Dokumentationsmodell – keine Darstellung einer konkreten Kundenumgebung.

Typische Bruchstellen zeigen sich selten in nur einer Oberfläche.

Ein unvollständiger Datenfluss ist häufig nicht daran erkennbar, dass eine deutliche Fehlermeldung erscheint. Stattdessen wirkt das System oberflächlich funktionstüchtig: Profile sind vorhanden, einzelne Events kommen an und der Flow ist aktiv. Erst beim Vergleich mehrerer Testfälle wird sichtbar, dass bestimmte Identifikationswege, Einwilligungswege oder Bestellzustände anders behandelt werden.

Ein Event kommt an, enthält aber nicht alle Eigenschaften, die spätere Filter benötigen.
Ein Profil wird erstellt, kann aber nicht eindeutig mit der Shop-Aktion verbunden werden.
Der Flow startet korrekt, endet jedoch nicht nach einem zwischenzeitlichen Kauf.
Ein vorhandenes Consent-Signal wird technisch anders interpretiert als erwartet.
Ein wiederholtes Event führt zu einem weiteren Einstieg, obwohl die gewünschte Logik dies ausschließen soll.

Ein erfolgreicher Test beweist noch nicht, dass der Flow zuverlässig läuft.

Ein Positivtest beantwortet nur die Frage, ob ein vorgesehener Einstieg unter passenden Bedingungen funktioniert. Mindestens ebenso wichtig sind Negativtests und Grenzfälle: Was passiert nach einem zwischenzeitlichen Kauf? Wie verhält sich die Logik ohne passendes Signal? Was geschieht bei einem wiederholten Event?

TestfallErwartetes VerhaltenDokumentation

Passendes Event und Profil, kein KaufFlow-Einstieg nach definierter WartezeitZeitpunkt, Eventdaten und tatsächlicher Einstieg

Kauf nach Warenkorb-EventAusschluss oder Abbruch vor unpassender NachrichtKaufzeitpunkt und angewendete Abbruchbedingung

Fehlende benötigte EigenschaftKein unbeabsichtigter Einstieg über unvollständige LogikFehlendes Feld und sichtbare Auswirkung

Wiederholtes EventVerhalten entsprechend der festgelegten WiederholungslogikAnzahl der Events und tatsächliche Einstiege

Für jeden Test sollte feststehen, was erwartet wurde, was tatsächlich passiert ist und welche Abweichung offen bleibt. Erst dann weiß die nächste Person mehr als nur „bei mir hat es funktioniert“.

Eine gute Übergabe ist mehr als ein Screenshot.

Nach einer Prüfung muss ein Kunde nicht jede technische Einzelheit selbst konfigurieren können. Er sollte aber verstehen, welche Verbindung betrachtet wurde, welche Testfälle durchgeführt wurden, wo Grenzen bestehen und welcher nächste Schritt empfohlen wird.

Eine gute Übergabe beantwortet nicht nur „Was wurde gemacht?“, sondern auch „Was wurde geprüft, was bleibt offen und worauf muss bei späteren Änderungen geachtet werden?“

Dafür helfen eine Datenflussübersicht, ein Prüfprotokoll und eine kurze Übergabe. Sie machen aus einzelnen Beobachtungen einen Arbeitsstand, mit dem später weitergearbeitet werden kann.