Hypothese (CRO)

Definition: Eine CRO-Hypothese ist eine präzise, datenbasierte und falsifizierbare Aussage die beschreibt: (1) welche konkrete Änderung an einem Website-Element vorgenommen wird; (2) welcher messbare Effekt auf eine definierte Conversion-Metrik erwartet wird; (3) warum dieser Effekt erwartet wird (Begründung durch Forschungsdaten oder Verhaltensprinzip). Standardformat (Wenn-Dann-Weil): «Wenn wir [konkrete Änderung] auf [spezifischem Element/Seite] vornehmen, dann erwarten wir [messbarer Effekt auf primäre Metrik], weil [Begründung aus Forschungsdaten oder UX-Prinzip].» Qualitätskriterium: eine gute Hypothese ist falsifizierbar (Karl Popper: «The Logic of Scientific Discovery», 1934) – sie muss durch einen Test widerlegbar sein; nicht-falsifizierbare Hypothesen («die Seite könnte besser werden») sind wissenschaftlich wertlos. Hypothesen-Quelle: 100% datenbasiert; keine «Bauchgefühl»-Hypothesen; Forschungsquellen: Heatmap-Befunde, Session-Recording-Insights, Exit-Survey-Antworten, Funnel-Abbruch-Analyse, Nutzerinterviews.

Erläuterung

Das wissenschaftliche Konzept der falsifizierbaren Hypothese geht auf Karl Popper (österreichisch-britischer Wissenschaftsphilosoph; «Logik der Forschung», 1934; englisch: «The Logic of Scientific Discovery», 1959, Routledge) zurück: Popper argumentierte dass eine wissenschaftliche Aussage nur dann bedeutsam ist wenn sie durch Beobachtungen widerlegbar (falsifizierbar) ist – nicht wenn sie verifizierbar ist. Im CRO-Kontext bedeutet das: «Wenn wir den CTA-Button von Grau auf Orange ändern dann steigt die Click-Through-Rate um mindestens 10%» ist eine falsifizierbare Hypothese; «die Seite könnte mit einem orangenen Button besser aussehen» ist keine Hypothese sondern eine Meinung. Bryan Eisenberg und Jeffrey Eisenberg (Gründer Future Now Inc.; Autoren «Waiting For Your Cat to Bark?», 2006) prägten im CRO-Kontext die Anforderung dass jede Optimierungsmaßnahme eine explizite Hypothese benötigt bevor sie implementiert wird – ohne Hypothese kein Lernen aus dem Test. Chris Goward (WiderFunnel; Autor «You Should Test That!», 2013, Sybex) standardisierte die Hypothesen-Entwicklung als integralen Teil des CRO-Prozesses und verband sie mit dem LIFT-Modell: Hypothesen sollten auf einem der sechs LIFT-Dimensionen basieren (Value Proposition, Relevance, Clarity, Urgency, Anxiety, Distraction). Peep Laja (CXL Institute) quantifizierte den Wert gut begründeter Hypothesen: Teams die Hypothesen aus strukturierter Nutzerforschung ableiten (Heatmaps + Session Recordings + Surveys) haben eine Test-Win-Rate von 40–60%; Teams die Hypothesen aus Intuition oder Meinungen ableiten haben Win-Rates von 10–25%.

Hypothesen-Struktur und Qualitätsstufen

Wenn-Dann-Weil-Format (Standard): Vollständige Hypothesen-Struktur: «Wenn wir [Konkrete Änderung] auf [Element/Seite/Funnel-Schritt] vornehmen, dann erwarten wir [messbarer Effekt] auf [primäre Metrik], weil [Begründung aus Forschungsdaten].»; Beispiel stark: «Wenn wir den 'In den Warenkorb'-Button von der Mitte der Produktseite an eine Position direkt neben dem Produktbild above the fold verschieben, dann erwarten wir eine Steigerung der Add-to-Cart-Rate um mindestens 10%, weil unsere Scroll-Map zeigt dass 62% der Desktop-Nutzer die Seite verlassen bevor sie zum Button scrollen.»; Beispiel schwach (unvollständig): «Wir testen eine neue Button-Position weil der Button vielleicht nicht gut sichtbar ist.»; Schwächen der schwachen Hypothese: kein quantitativer Zielwert; Begründung nicht datenbasiert sondern Vermutung («vielleicht»); kein konkreter Forschungs-Insight als Grundlage
Hypothesen-Qualitätsstufen (1–4): Stufe 1 – Intuitions-Hypothese: basiert auf Meinung oder Ästhetik ohne Daten («Der Button sollte größer sein»); kein quantitativer Zielwert; niedrigste Win-Rate (10–20%); nicht empfohlen; Stufe 2 – Analogie-Hypothese: basiert auf Branchenbest-Practices oder Wettbewerber-Analyse («Konkurrent X nutzt großen roten Button; wir testen das auch»); mittel Win-Rate (20–30%); Stufe 3 – Daten-Hypothese: basiert auf eigenen quantitativen Daten (Heatmap, Funnel-Abbruch, Analytics); konkreter Befund als Grundlage; Win-Rate: 35–45%; Stufe 4 – Multi-Source-Hypothese (höchste Qualität): basiert auf mehreren konvertierten Datenquellen (quantitative Daten + qualitative Forschung aus Surveys/Interviews + UX-Prinzip); Win-Rate: 50–65% (Peep Laja, CXL Institute)
Hypothesen-Forschungsquellen: Heatmap-Insights: CTA wird kaum geklickt → Sichtbarkeits-Hypothese; Rage-Clicks auf Formular → Usability-Hypothese; Session-Recording-Befunde: Nutzer scrollen unsicher über Checkout-Formular → Formular-Klarheits-Hypothese; Nutzer verlassen bei bestimmtem Element → Barrieren-Hypothese; Exit-Survey-Antworten: häufigste Abbruchgründe aus offenen Antworten → direkte Hypothesen-Quelle; Funnel-Analyse: welcher Schritt hat >30% Drop-off → Friction-Hypothese für diesen Schritt; Nutzerinterviews (5–8 Interviews): «Warum haben Sie nicht gekauft?» → Echte Barrieren; Wettbewerber-Analyse: was machen Top-Performer in der Branche anders? → Validierungs-Hypothesen; A/B-Test-Ergebnis-Analyse: was hat in ähnlichen Tests gewonnen/verloren? → Pattern-basierte Hypothesen

Hypothesen-Backlog und -Management

Hypothesen-Dokumentationsstruktur: Jede Hypothese im Backlog enthält: Hypothese (vollständige Wenn-Dann-Weil-Formulierung); Forschungsquelle (welcher Befund führte zu dieser Hypothese?); Seite/Element (URL; konkretes Element); primäre Testmetrik (OEC; z. B. «Add-to-Cart-Rate»); Guardrail-Metriken (z. B. «Checkout-Completion-Rate darf nicht sinken»); PIE-Score (Potential, Importance, Ease; je 1–10; Gesamt-Score = Durchschnitt); geschätzte Laufzeit (aus Stichprobengrößen-Rechner); technischer Aufwand (gering/mittel/hoch); Status (Backlog/In Test/Abgeschlossen/Verworfen); Test-Ergebnis (nach Abschluss: Gewinner/Verlierer/Inconclusive + Learning)
Hypothesen-Priorisierung mit PIE-Score: PIE-Score-Dimensionen: Potential (wie stark kann diese Seite verbessert werden? basierend auf CVR vs. Benchmark): 1–10; Importance (Traffic-Volumen × Conversion-Wert dieser Seite im Funnel): 1–10; Ease (Implementierungsaufwand für Entwickler; Text-Änderung = 10; Backend-Umbau = 2): 1–10; Formel: PIE-Score = (P + I + E) / 3; Tests mit höchstem PIE-Score werden zuerst durchgeführt; Team-Scoring: PIE-Score sollte im Team bewertet werden (Analyst + Designer + Developer); Einzel-Bewertungen divergieren oft bei Ease (Developer schätzt Aufwand realistischer) und Importance (Analyst hat Traffic-Daten); regelmäßige Backlog-Überprüfung: monatlich; Hypothesen älter als 3 Monate ohne Fortschritt: erneut bewerten oder verwerfen
Häufige Hypothesen-Fehler im CRO: Zu breite Hypothese: «Wenn wir die gesamte Produktseite redesignen dann steigt die CVR» → mehrere Änderungen gleichzeitig; kein isoliertes Lernen möglich; besser: eine spezifische Änderung pro Hypothese; keine Begründung: «Wir testen einen anderen CTA-Text» ohne Daten-Grundlage; kein Lernwert wenn Test verliert weil unklar warum; HiPPO-Hypothese: Hypothese entspringt CEO-Meinung ohne Forschungsgrundlage; unterminiert Datenkultur; Symptom-statt-Ursachen-Hypothese: «Die CVR ist zu niedrig» ist Beobachtung nicht Hypothese; fehlende Guardrail-Metriken: Hypothese testet nur primäres OEC ohne Absicherung durch sekundäre Metriken; zu vage Erfolgskriterien: «CVR soll steigen» ohne Mindest-Uplift; Minimum Detectable Effect (MDE) vorab definieren

Praxistipp: Verwenden Sie dieses 5-Minuten-Hypothesen-Audit für jede neue Test-Idee bevor sie in den Backlog kommt: (1) Habe ich eine konkrete Datenquelle die dieses Problem bestätigt? (2) Ist die Änderung spezifisch genug um isoliert getestet zu werden? (3) Ist der erwartete Effekt messbar und definiert? (4) Habe ich eine klare Begründung («weil...») die das Nutzerverhalten erklärt? (5) Gibt es Guardrail-Metriken die ich schützen muss? Hypothesen die alle fünf Fragen mit Ja beantworten haben eine 2–3× höhere Win-Rate als Hypothesen die eine oder mehrere Fragen mit Nein beantworten.