Klaviyo ist bereits eingerichtet: Diese Bereiche sollten zuerst geprüft werden.

01

Am Anfang steht eine einfache Frage: Was wollen wir eigentlich herausfinden?

„Klaviyo prüfen“ ist als Auftrag zu ungenau. Ein Shop kann wissen wollen, warum bestimmte Flows nicht starten, weshalb Kennzahlen unplausibel wirken, ob die Shop-Anbindung vollständig ist oder ob eine gewachsene Konfiguration vor einem Relaunch dokumentiert werden muss.

Deshalb halten wir zuerst fest, welches Problem beobachtet wird, welche Systeme beteiligt sind und was am Ende klar sein soll. Manchmal reicht dann eine kleine Fehleranalyse. In anderen Fällen lohnt sich der Blick auf das gesamte Setup.

02

Bevor wir in Flows einsteigen, muss klar sein, wem die Konten gehören.

Bevor jemand Einstellungen ändert, sollte geklärt sein, wem Shop-, Klaviyo-, Domain- und Integrationskonten gehören, welche Rollen vergeben sind und wer Änderungen freigeben darf. Veraltete Administratoren, private Eigentümerkonten oder fehlende Wiederherstellungswege können ein größeres Betriebsrisiko sein als ein einzelner fehlerhafter Flow.

• Welche Gesellschaft besitzt die produktiven Konten?
• Wer hat Administratorrechte, und werden diese noch benötigt?
• Sind MFA, Wiederherstellung und Abrechnung dem Unternehmen zugeordnet?
• Welche Apps, API-Schlüssel und externen Dienstleister greifen auf Daten zu?
• Wer entscheidet fachlich, technisch und rechtlich über Änderungen?

03

Danach wird die tatsächliche Shop-Verbindung geprüft – nicht nur ihr Statuslabel.

Klaviyo bietet für verschiedene Commerce-Plattformen vorgefertigte Integrationen. Welche historischen Daten, Kataloginformationen, Profile und Ereignisse synchronisiert werden, unterscheidet sich jedoch je nach Plattform und gewählter Konfiguration. Deshalb genügt es nicht, dass eine Integration in der Oberfläche als aktiv erscheint.

Zu prüfen sind die verbundene Shopinstanz, Integrationsoptionen, historische Synchronisierung, Onsite-Tracking, Katalogdaten und mögliche zusätzliche Apps oder benutzerdefinierte Datenwege. Bei einem Plattformwechsel oder Theme-Update ist außerdem wichtig, ob alte und neue Quellen gleichzeitig Signale erzeugen.

04

Events und Profile müssen in Inhalt, Zeitpunkt und Zuordnung zusammenpassen.

Unter Analytics beziehungsweise Metrics lässt sich prüfen, welche Ereignisse tatsächlich eingehen. Relevant sind nicht nur die Namen der Events, sondern auch Zeitstempel, Quelle, Profilzuordnung und Eigenschaften, die spätere Trigger, Filter oder Personalisierungen benötigen.

Ein Profil in Klaviyo ist dabei nicht automatisch mit einer gültigen Marketing-Einwilligung gleichzusetzen. Auch Kundenprofile für Bestell- und Servicezwecke können im Account vorhanden sein. Subscription- und Suppression-Informationen müssen deshalb getrennt betrachtet werden.

05

Profile, Listen, Segmente und Versandstatus erfüllen unterschiedliche Aufgaben.

Listen sind grundsätzlich Sammlungen von Kontakten, während Segmente dynamisch anhand definierter Bedingungen aktualisiert werden. Zusätzlich beeinflussen Subscription- und Suppression-Status, ob ein Profil über einen Kanal angesprochen werden kann. Werden diese Ebenen vermischt, entstehen unklare Zielgruppen und schwer erklärbare Flow-Einstiege.

• Welche Liste dient einem tatsächlichen Anmelde- oder Prozesszweck?
• Welche Segmente bilden veränderliche Verhaltens- oder Profillogik ab?
• Gibt es doppelte, veraltete oder widersprüchliche Strukturen?
• Welche Profile sind aktiv, abgemeldet oder unterdrückt?
• Welche Systeme dürfen Subscription-Informationen verändern?

06

Bei Flows zählt nicht nur „Live“, sondern die gesamte Eintritts- und Ausschlusslogik.

Für jeden relevanten Flow sollten Trigger, Trigger-Filter, Profilfilter, Re-Entry-Regeln, Zeitverzögerungen, Verzweigungen und zusätzliche Nachrichtenfilter geprüft werden. Klaviyo bewertet Filter nicht nur beim Eintritt; Profilfilter können auch später erneut darüber entscheiden, ob eine geplante Nachricht tatsächlich gesendet oder übersprungen wird.

• Passt der Trigger zum gewünschten Verhalten?
• Welche Datenfelder verwenden Trigger- und Nachrichtenfilter?
• Wie wird ein Kauf, eine Abmeldung oder ein anderer Ausschluss berücksichtigt?
• Darf ein Profil erneut eintreten, und unter welchen Bedingungen?
• Sind Nachrichten auf Draft, Manual oder Live gestellt?
• Zeigt der Changelog Änderungen, die das Verhalten erklären?

07

Formulare, Onsite-Tracking und vorhandene Consent-Signale bilden einen eigenen Prüfblock.

Sign-up-Formulare, Theme-Einbindungen, Cookie- beziehungsweise Consent-Lösungen und Onsite-Tracking können beeinflussen, ob Profile identifiziert, Listen befüllt und Ereignisse erfasst werden. Die Prüfung sollte deshalb dokumentieren, welche Komponente welches Signal erzeugt und ob Shop, Klaviyo und weitere Tools denselben Zustand konsistent abbilden.

Besonders nach Theme-, Checkout-, App- oder Consent-Änderungen sollte kontrolliert werden, ob eingebundene Skripte noch geladen werden, Formulare der richtigen Liste zugeordnet sind und Tracking nicht doppelt oder gar nicht ausgeführt wird.

08

Ein Audit braucht echte Testfälle – nicht nur einen grünen Status in der Oberfläche.

Oberflächenkontrolle und Trigger-Vorschau sind hilfreiche Werkzeuge, ersetzen aber nicht jeden End-to-End-Test. Sinnvoll sind mindestens ein erwarteter Erfolgsfall, ein Ausschlussfall und relevante Grenzfälle. Dabei werden erwartetes Verhalten, tatsächliches Ergebnis, Zeitpunkt und sichtbare Abweichung getrennt festgehalten.

09

Am Ende werden Befunde priorisiert – nicht einfach gesammelt.

Eine lange Fehlerliste hilft noch niemandem bei der Entscheidung, was als Nächstes passieren soll. Befunde sollten nach Auswirkung, Dringlichkeit, Abhängigkeit und Aufwand geordnet werden. Kritische Daten- oder Versandprobleme stehen vor Komfortverbesserungen; strukturelle Altlasten werden von kurzfristig lösbaren Konfigurationsfehlern getrennt.

1. A
   Betriebs- oder Versandrisiko

   Fehlende Daten, ungewollte Nachrichten, falsche Eigentümerschaft oder sicherheitsrelevante Zugänge.

2. B
   Zuverlässigkeit und Wartbarkeit

   Unklare Filter, doppelte Strukturen, fehlende Dokumentation oder instabile Tracking-Abhängigkeiten.

3. C
   Optimierung

   Neue Segmente, zusätzliche Flows, Personalisierung und weiterführende Auswertung.

Ein belastbares Audit beantwortet drei Fragen: Was funktioniert heute? Was ist nachweislich fehlerhaft oder unklar? Und welche Änderung sollte aus welchem Grund zuerst erfolgen?

Die Übergabe sollte deshalb geprüfte Systeme, Testfälle, Ergebnisse, bekannte Grenzen, offene Abhängigkeiten und empfohlene nächste Schritte enthalten. Erst danach wird entschieden, ob DTC eine Korrektur, Erweiterung, Neueinrichtung oder laufende Betreuung übernimmt.