Conversion-Optimierung: Das Framework, das wirklich funktioniert
Wir haben in über 200 Projekten Conversion-Rate-Optimierung betrieben. Nicht als isolierte Disziplin, sondern als integrierten Prozess: Analyse → Hypothese → Test → Implementierung → Monitoring. Dieser Artikel zeigt das Framework, das wir nutzen — und die Ergebnisse, die es in echten Shops geliefert hat.
Phase 1: Analyse — Daten statt Annahmen
Die größte Fehlerquelle in der CRO ist die Annahme. „Wir glauben, dass die Kunden X wollen.“ „Wir denken, dass der Button zu klein ist.“ Glauben, denken — das sind keine Daten. Das sind Vermutungen.
Unsere Analysephase hat drei Schritte:
Quantitative Analyse. Wir schauen auf die Zahlen. Wo brechen Nutzer ab? Welche Seiten haben die höchste Absprungrate? Welcher Traffic-Kanal konvertiert am besten?
Ein Fashion-Shop hatte eine Gesamt-Conversion von 1,4 Prozent. Die quantitative Analyse zeigte: Desktop 2,9 Prozent, Mobile 0,8 Prozent. Die Mobile-Lücke war der größte Hebel. Nicht die Startseite. Nicht die Kategorie. Die Mobile-Experience.
Qualitative Analyse. Wir schauen, was die Nutzer tun. Heatmaps zeigen, wo geklickt wird. Session Recordings zeigen, wo gezögert wird.
Derselbe Fashion-Shop zeigte in Recordings: Mobile-Nutzer tippten auf das Produktbild — aber es gab keinen Zoom. Sie scrollten zu den Bewertungen — aber die Bewertungen standen ganz unten. Sie öffneten den Filter — aber der Overlay nahm den ganzen Screen ein.
Wettbewerbs-Analyse. Wir schauen, was die Konkurrenz macht. Nicht, um zu kopieren. Sondern um zu verstehen, welche Standards der Markt erwartet.
Phase 2: Hypothese — Testbar und spezifisch
Aus der Analyse leiten wir Hypothesen ab. Eine gute Hypothese hat drei Teile: Wenn wir [Änderung] machen, dann wird [Metrik] um [Erwartung] verbessern, weil [Begründung].
Schlechte Hypothese: „Wir ändern den Button und hoffen, dass mehr kaufen.“ Gute Hypothese: „Wenn wir den ‚In den Warenkorb‘-Button auf Mobile sticky machen, dann wird die Add-to-Cart-Rate um 20 Prozent steigen, weil die Nutzer den Button nicht mehr suchen müssen.“
Der Fashion-Shop formulierte drei Hypothesen: Bild-Zoom auf Mobile (+15 Prozent Conversion erwartet), Bewertungen als ausklappbarer Bereich über dem Fold (+10 Prozent), Filter als Bottom-Sheet statt Vollbild-Overlay (+12 Prozent).
Phase 3: Test — Kontrolliert und messbar
Jede Hypothese wird in einem A/B-Test validiert. Control gegen Variante. 50/50 Traffic-Split. Mindestens 95 Prozent statistische Signifikanz. Mindestens zwei Wochen Laufzeit.
Der Fashion-Shop testete alle drei Hypothesen. Test 1 (Bild-Zoom): Mobile-Conversion stieg um 18 Prozent. Test 2 (Bewertungen): Mobile-Conversion stieg um 9 Prozent. Test 3 (Filter): Kategorie-Conversion stieg um 21 Prozent.
Phase 4: Implementierung — Schnell und sauber
Ein gewonnener Test nützt nichts, wenn er nicht implementiert wird. Wir implementieren Gewinner-Varianten innerhalb von 48 Stunden.
Der Fashion-Shop implementierte alle drei Varianten. Die Gesamt-Mobile-Conversion stieg von 0,8 auf 1,3 Prozent. Der Gesamtumsatz stieg um 34 Prozent — weil 71 Prozent des Traffics Mobile war. Die Investition: Ein Frontend-Entwickler, 5 Tage. Der Return: ca. 48.000 Euro weiterer Umsatz pro Monat.
Fazit: CRO ist ein System, kein Projekt
CRO ist kein Einzelprojekt. Es ist ein System. Wer das System etabliert, sammelt mit jedem Test mehr Erkenntnisse. Die Hypothesen werden besser. Die Trefferquote steigt. Der Umsatz wächst kontinuierlich.
Der Fashion-Shop lief mittlerweile über 40 Tests. Die Trefferquote lag in den ersten 10 Tests bei 30 Prozent. In den letzten 10 Tests bei 65 Prozent. Das Team verstand den Kunden besser. Die Hypothesen waren präziser. Das ist der wahre Wert von CRO: nicht der einzelne Test, sondern das System, das mit jedem Test schlauer wird.
Phase 5: Monitoring — Der Test endet nicht
Die meisten CRO-Programme hören nach der Implementierung auf. Das ist ein Fehler. Ein gewonnener Test kann nach der Implementierung schwächer werden — oder stärker. Wir monitoren jede implementierte Änderung für mindestens 30 Tage.
Ein Supplement-Shop implementierte einen One-Page-Checkout, der in einem Test um 22 Prozent gewonnen hatte. Nach der Implementierung lag der Effekt bei nur 14 Prozent. Die Analyse zeigte: Der Test war auf Desktop-Nutzer fokussiert. Auf Mobile hatte der One-Page-Checkout zu viele Felder auf einem Screen. Wir bauten eine Mobile-Variante mit gestaffeltem Formular. Der Effekt stieg auf 19 Prozent — nahe am ursprünglichen Test-Ergebnis.
Ohne Monitoring hätten wir den Performance-Verlust nicht bemerkt. Der Test hatte gewonnen — aber die Implementierung war unvollständig.
Zuletzt aktualisiert: Mai 2026
