CRO-Test-System. Iteration in Tagen, nicht in Wochen.
Conversion-Rate hebt man nicht durch „bessere Designs", sondern durch ein System: saubere Hypothese, schnell gebaute Section-Variante, ehrlich gemessen. Hier die komplette Test-Methodik plus wie wir sie bei Hearo aufgesetzt haben — 14 Custom-PDPs aus einer wiederverwendbaren Section-Library.
Warum die meisten CRO-Programme nichts bewegen.
Nicht weil die Ideen schlecht sind — weil der Zyklus zu langsam ist. Eine Test-Idee, die fünf Tage auf den Dev wartet, dann zwei Wochen Traffic sammelt, dann im Tool-Dschungel ausgewertet wird, ist nach sechs Wochen ein Datenpunkt. Sechs Wochen, ein Lernschritt. So gewinnt niemand.
Ein CRO-Test-System dreht die Frequenz um: Wenn eine Variante in Stunden statt Tagen steht, testest du wöchentlich statt quartalsweise. Nicht die einzelne Idee gewinnt — die Lern-Frequenz gewinnt. Genau das meint „die stärksten Brands haben die schnellsten Lernsysteme".
Das setzt zwei Dinge voraus, die Standard-Themes nicht liefern: eine modulare Section-Library (Varianten zusammenstecken statt programmieren) und eine ehrliche Mess-Disziplin (eine Hypothese, eine Primär-Metrik, ein Stop-Kriterium).
Vier Bausteine. Ein Test-System.
Hypothesen-Disziplin
Jeder Test hat eine Form: „Weil Beobachtung, glauben wir, dass Änderung die eine Primär-Metrik bewegt." Kein Test ohne diese Zeile.
Section-Library
80–100 modulare Sections. Eine Test-Variante ist ein Zusammenstecken, kein Custom-Code-Ticket. Das ist die Geschwindigkeits-Quelle.
Eine Primär-Metrik
Pro Test genau eine Entscheidungs-Metrik (i. d. R. DB1 pro Visitor, nicht nackte CR). Sekundär-Metriken beobachten, nicht entscheiden lassen.
Stop-Kriterium vorab
Mindest-Sample und Laufzeit vor dem Start festgelegt. Kein „Peeking", kein Abbruch beim ersten schönen Zwischenstand.
Live: Wie wir das bei Hearo aufgesetzt haben.
Was gebaut wurde
Hearo brauchte nicht eine PDP, sondern viele — schnell, konsistent, testbar. Wir haben eine wiederverwendbare Section-Library aufgesetzt, aus der 14 Custom-PDPs entstanden sind, plus 14+ wiederverwendbare Sections, die jede neue Variante zur Steck-Aufgabe machen statt zum Dev-Ticket.
Was sich operativ geändert hat
- Build-Zeit: neue PDP-Variante aus vorhandenen Sections in Stunden statt Tagen.
- Konsistenz: jede PDP zieht dieselben Brand-Tokens — keine Design-Drift über 14 Seiten.
- Testbarkeit: Varianten sind isoliert austauschbar, ohne den Rest des Themes anzufassen.
Die Substanz ist die Library, nicht eine geschönte CR-Zahl.
Gemessene Conversion-Deltas gehören in den jeweiligen Test, gegen eine eingefrorene Baseline und DB1 — nicht als Marketing-Zahl auf eine Wissens-Seite. Was hier zählt, ist das reproduzierbare System.
Vier Anti-Patterns, die jedes CRO-Programm ausbremsen.
Test ohne Hypothese
„Lass mal den Button grün machen." Ohne Beobachtung, Erwartung und Primär-Metrik ist es kein Test, sondern Geschmack.
CR statt DB1
Mehr Conversions zu kleinerem Korb kann Profit vernichten. Die Entscheidungs-Metrik ist Deckungsbeitrag pro Visitor.
Peeking & Früh-Stopp
Test abbrechen, sobald die Zahl gefällt. Stop-Kriterium vorab festlegen — sonst misst du Rauschen.
Test-Stau am Dev
Wenn jede Variante ein Ticket ist, läuft ein Test pro Quartal. Die Library ist die eigentliche CRO-Investition.
Ein CRO-Test-System selbst aufsetzen — in 5 Schritten.
Reibungs-Audit der PDP
Wo bricht der Funnel? Heatmap, Session-Recordings, Drop-off-Punkte. Beobachtungen sammeln, nicht Meinungen.
Hypothesen schreiben
Pro Reibungspunkt eine Hypothese in fester Form, mit genau einer Primär-Metrik (DB1/Visitor).
Section-Library aufbauen
Erst 3–5 wiederverwendbare Sections, die die häufigsten PDP-Bausteine abdecken. Wächst mit jedem Test.
Test sauber laufen lassen
Stop-Kriterium und Mindest-Sample vorab. Eine Variante, eine Hypothese, kein Peeking.
Lernen festschreiben
Ergebnis (auch Niederlagen) dokumentieren, Gewinner in die Library übernehmen. Die Library ist das Gedächtnis.
Wo das CRO-System den Rest des Stacks trifft.
Customer Lifetime Value
Mehr profitable Erstkunden zum gleichen CAC = mehr Kohorten-Volumen für die ganze CLTV-Mechanik.
→AOV-/Bundle-Architektur
Bundle-Hebel werden über dieselbe Section-Library getestet — CRO ist das Verteilungssystem der AOV-Hebel.
→Lifecycle Loops
Theme-Events aus der Library triggern Flows. Ein gut getestetes Theme befeuert die Lifecycle-Maschine direkt.