Deine Seite bekommt Besucher, aber zu wenige davon fragen an. Die übliche Reaktion darauf ist ein Vorschlag: anderer Button, kürzeres Formular, neue Überschrift.
Conversion Optimierung fängt eine Stufe früher an. Sie ist die Arbeitsweise, mit der aus “die Seite konvertiert schlecht” eine geordnete Liste von Vermutungen wird. Diese Lektion zeigt den Ablauf und sagt bei jedem Baustein dazu, worauf er beruht, weil hier vieles als Methode auftritt, was eigentlich Gewohnheit ist.
Die vorige Lektion hat die technische Seite behandelt: messen, Ladezeit, Sauberkeit. Hier geht es um die andere Hälfte – um Texte, Angebote und Abläufe. Und vor allem um die Frage, welche Änderung davon zuerst dran ist.
Du arbeitest dabei durchgehend an deiner eigenen Seite mit. Am Ende der Lektion hast du nicht nur den Ablauf verstanden, sondern ein angefangenes Backlog aus begründeten Vermutungen vor dir liegen.
Kurzantwort
Was ist Conversion Optimierung?
Conversion Optimierung ist ein wiederkehrender Ablauf: forschen, Hypothese bilden, priorisieren, umsetzen, lernen. Nicht eine Liste von Kniffen, sondern ein Verfahren, mit dem du begründet entscheidest, woran du als Nächstes arbeitest, statt zu raten.
📌 Für wen ist das relevant: Für alle, die eine Website verbessern wollen und bisher nach Bauchgefühl entscheiden, was zuerst drankommt.
- Der Grund für das Verfahren ist gut belegt: Menschen schätzen den Wert eigener Ideen schlecht ein. Deshalb sammelst du Belege, bevor du änderst
- ICE, PIE und PXL strukturieren deine Entscheidung. Eine Messung sind sie nicht
- Forschen, Hypothese und Priorisierung funktionieren auch mit 300 Besuchern im Monat. Nur der Beweis am Ende fällt weg
Das lernst du in dieser Lektion
Du ziehst aus deinem Postfach, deinen Analytics und deiner eigenen Anfrage-Strecke Belege und weißt, welche Frage jede Quelle beantwortet.
Du formulierst eine Hypothese, die man widerlegen kann, statt einer Meinung.
Du priorisierst dreißig Ideen mit einem der gängigen Rahmenwerke – und weißt, was seine Punktzahl wert ist.
Du kannst eine spektakuläre Erfolgszahl einordnen, bevor du sie übernimmst.
Du sicherst Entscheidungen auch ohne Testverkehr ab: mit Belegqualität vor der Änderung und notierten Vorher-Zahlen danach.
Inhalt
01 ·
Was Conversion Optimierung hier meint
Eine Conversion ist die Handlung, auf die du hinarbeitest: eine Anfrage, ein Kauf, ein Anruf, eine Anmeldung. Diese Lektion behandelt nicht die Kennzahl dahinter, sondern den Weg zu den Änderungen.
Sie beantwortet eine einzige Frage: Wie kommst du systematisch von “die Seite konvertiert schlecht” zu einer begründeten, sortierten Liste von Vermutungen?
Leg vor dem Weiterlesen die Grundlage. Schreib die eine Handlung auf, auf die deine Seite hinarbeitet. Fallen dir mehrere ein, entscheide dich für die wichtigste, denn jeder Schritt dieser Lektion bezieht sich auf genau diese eine Handlung.
ℹ️ Was wo steht
Kennzahlen, Benchmarks und Werkzeuge findest du in unserem Beitrag zur Conversion-Rate-Optimierung, einem Überblick ohne Kursrahmen.
Testschwellen, Stichprobengrößen und das Prüfraster für eine einzelne Seite stehen in der nächsten Lektion zu Landing Pages, das Handwerk des Nutzertests in der Lektion zu User Experience, die Usability-Heuristiken in der Lektion zu Usability.
02 ·
Warum es überhaupt ein Verfahren braucht
Das stärkste Argument für einen geordneten Ablauf ist nicht, dass ein bestimmter Ablauf besser abschneiden würde als ein anderer. Es ist ein anderes, und das ist gut belegt.
Ronny Kohavi und Kollegen von Microsoft veröffentlichten 2013 auf der Fachkonferenz KDD die Arbeit “Online Controlled Experiments at Large Scale”. Einer ihrer Abschnitte trägt die Überschrift “We are poor at assessing the value of ideas”. Der Kernsatz daraus:
“Only one third of the ideas tested at Microsoft improved the metric(s) they were designed to improve.”
Im selben Abschnitt tragen die Autoren ähnliche Aussagen aus anderen Häusern zusammen, unter anderem von Google, Netflix und Etsy.
Was diese Zahl nicht sagt
Kohavi schränkt sie selbst ein: “Not every domain has such poor statistics.” Gemessen wurde an Produkten großer Plattformen, die seit Jahren optimiert werden.
Auf einer Handwerker-Website, deren Kontaktseite seit Jahren unverändert ist, liegt die Trefferquote plausibel höher, weil das Ausgangsniveau niedriger ist. Die Zahl ist also kein Prozentwert für dein Projekt. Was trägt, ist die allgemeinere Aussage: Selbst dort, wo mit den besten Daten und Methoden gearbeitet wird, wirken die meisten Ideen nicht.
💡 Merke
Der Grund für ein Verfahren ist nicht, dass Verfahren bewiesen wären, sondern dass Raten nachweislich schlecht funktioniert. Wer das akzeptiert, sucht nicht mehr nach der einen richtigen Idee, sondern erzeugt Ideen billig und sortiert sie geordnet aus.
Zieh daraus gleich die erste praktische Konsequenz. Sammle alle Änderungsideen, die zu deiner Seite bei dir herumliegen, in einer Liste: aus alten Notizen, aus Gesprächen, aus deinem Kopf. Bewerte nichts und streich nichts, denn diese ungefilterte Liste ist das Rohmaterial für die nächsten Schritte.
03 ·
Die Schleife, und wer sie beschreibt
Prozessmodelle für diese Arbeit gibt es viele, von Agenturen und Softwareanbietern, mit fünf, sieben oder zwölf Schritten. Sie laufen alle auf dieselbe Schleife hinaus.
Die Schleife der Conversion Optimierung
Fünf Schritte, die nach dem letzten wieder beim ersten anfangen
1 · Forschen
Belege sammeln, wo es klemmt und warum. Sektion 4.
2 · Vermuten
Aus jedem Beleg eine prüfbare Hypothese bauen. Sektion 5.
3 · Sortieren
Entscheiden, was zuerst drankommt, und es aufschreiben. Sektion 6.
4 · Umsetzen
Ändern – und zwar eine Sache nach der anderen. Sektion 9.
5 · Lernen
Ergebnis notieren, auch das enttäuschende. Sektion 9, Experten-Tipp.
↻ und mit dem Ergebnis zurück zu Schritt 1
Grundlage: übereinstimmende Struktur mehrerer Praktiker-Prozessmodelle, unter anderem ResearchXL von CXL/Speero und der Methodik von Conversion Rate Experts – Praktiker-Konvention, kein geprüftes Verfahren, Stand 08/2026. Eigene Darstellung, Ostend Digital.
Schaubild: Die fünf Schritte als Schleife – eigene Darstellung, Ostend Digital, Stand 08/2026.
Zwei Abschnitte dieser Lektion liegen quer zur Schleife, weil sie an jeder Stelle greifen: der Filter gegen spektakuläre Zahlen aus fremden Artikeln und die drei Denkfehler, die auch einen sauberen Ablauf teuer machen.
Achte darauf, wer den Prozess beschreibt
Praktisch das gesamte Material zu diesem Thema stammt von Parteien, die Beratung oder Software verkaufen. Das macht es nicht wertlos, aber es erklärt, warum die Modelle so ähnlich enden. Wer ein Testwerkzeug anbietet, beschreibt den Test verlässlich als Pflichtschritt – für eine Seite mit ein paar hundert Besuchern im Monat ist er das nicht, siehe Sektion 9.
💡 Praxis-Tipp
Leg jetzt dein Backlog an: eine Tabelle mit vier Spalten. Beleg, Vermutung, Bewertung, Ergebnis. Eine Tabellenkalkulation oder ein simples Dokument reicht völlig, entscheidend ist nur, dass es eine einzige Datei ist.
Übertrag deine Ideenliste aus Sektion 2 in die Spalte Vermutung. Die Spalte Beleg füllst du in Sektion 4 und 5, die Bewertung in Sektion 6, das Ergebnis nach jeder Umsetzung.
04 ·
Schritt 1: Woher Hypothesen kommen
Der erste Schritt entscheidet über alles danach, denn eine Priorisierung sortiert nur, was vorher da war.
Dahinter steht eine Unterscheidung: Quantitative Quellen beantworten, was passiert und wo, qualitative beantworten, warum. Wer nur mit Zahlen arbeitet, weiß, wo es klemmt, und rät bei der Ursache. Wer nur mit Gesprächen arbeitet, hat Erklärungen ohne Größenordnung.
| Quelle | Beantwortet | Beantwortet nicht | Typischer Fehlgebrauch |
|---|---|---|---|
| Web-Analytics | Wo Besucher abspringen und wie groß ein Problem ist | Warum sie abspringen | Aus einer Absprungrate eine Ursache ableiten |
| Nutzertests | Warum jemand hängenbleibt und was nicht verstanden wird | Wie häufig das Problem ist | Aus fünf Personen eine Prozentzahl machen |
| Umfragen auf der Seite | Welcher Einwand blockiert, in den Worten der Kunden | Was Menschen tatsächlich tun werden | Absichtsfragen als Verhaltensprognose lesen |
| Support- und Vertriebsanfragen | Welche Frage so oft kommt, dass sie auf der Seite fehlt | Repräsentativität, es melden sich nur die, die sich melden | Einen lauten Einzelfall zum Massenproblem erklären |
| Suchanfragen interne Suche, Search Console |
Wonach Besucher suchen und mit welchen Begriffen | Warum sie das brauchen | Nur auf Volumen schauen statt auf die Wortwahl |
| Heatmaps und Aufzeichnungen | Auffällige Stellen, die man sich ansehen sollte | Häufigkeiten und Ursachen | Aus zwölf Aufzeichnungen eine Regel ableiten |
Eigene Darstellung, Ostend Digital, Stand 08/2026. Was Heatmaps grundsätzlich leisten, steht in der Lektion zu User Experience, ihr Einsatz auf einer Conversion-Seite in der Lektion zu Landing Pages.
Eine siebte Quelle kostet gar nichts: der Durchgang gegen die zehn Usability-Heuristiken aus der Lektion zu Usability. Er zeigt Verstöße gegen bekannte Faustregeln, nicht, ob das hier Anfragen kostet.
Warum du Menschen nicht alles fragen solltest
Jakob Nielsen veröffentlichte 2001 unter dem zugespitzten Titel “First Rule of Usability? Don’t Listen to Users” einen Text, der bis heute gilt. Seine Kernaussage: Selbstauskünfte sind typischerweise drei Schritte von der Wahrheit entfernt.
Er nennt drei Gründe. Menschen antworten in Richtung dessen, was sie für erwünscht halten, sie berichten aus einer unzuverlässigen Erinnerung, und sie erklären ihr Verhalten im Nachhinein plausibel, statt es zu beschreiben. Besonders deutlich wird er bei Prognosen über das eigene künftige Verhalten.
Trotz des Titels ist das kein Argument gegen Befragung, sondern eines gegen bestimmte Fragen.
💡 Merke
Frag nach Erlebtem, nicht nach Absichten. “Was hat Sie heute davon abgehalten, anzufragen?” ist brauchbar. “Würden Sie hier bestellen?” und “Welche Farbe gefällt Ihnen besser?” sind es nicht.
Nielsen verkauft mit der Nielsen Norman Group UX-Forschung und argumentiert damit auch für die eigene Leistung. Die Aussage ist trotzdem seit über zwanzig Jahren unwidersprochen.
Die billigste Quelle liegt in deinem Postfach
Fang mit den Anfragen an, die ohnehin bei dir eingehen. Nimm dir die letzten zwanzig vor, aus Postfach, Telefonnotizen und Kontaktformular, und schreib jede Frage heraus, die mehr als einmal vorkommt.
Prüfe dann für die drei häufigsten, ob deine Seite sie beantwortet, bevor jemand anfragen muss. Jede Frage, die sie nicht beantwortet, ist ein Beleg: Sie wandert in die Beleg-Spalte deines Backlogs, in den Worten deiner Kunden statt deiner eigenen. Das kostet weder Werkzeug noch Budget.
Klick deine eigene Anfrage-Strecke durch
Eine zweite Übung für heute, ebenfalls kostenlos: Geh den Weg deiner Besucher einmal selbst, vom Einstieg bis zur abgeschickten Anfrage, am besten am Handy. Du prüfst dabei keine Heuristiken, sondern stellst an fünf Punkten dieselbe Frage: Was steht hier zwischen dem Besucher und dem nächsten Schritt?
- 📌 Einstieg: Ist in fünf Sekunden klar, was du anbietest und für wen?
- 📌 Angebot: Beantwortet die Seite die drei Fragen aus deinem Postfach-Durchgang?
- 📌 Weg zur Anfrage: Wie viele Klicks liegen zwischen Interesse und Formular, und ist der nächste Schritt an jeder Stelle sichtbar?
- 📌 Formular: Fragst du etwas ab, das du für den Erstkontakt gar nicht brauchst?
- 📌 Danach: Sagt die Bestätigung, was jetzt passiert und wie schnell?
Alles, was dich dabei stocken lässt, notierst du als Beobachtung im Backlog. Du bist als Betreiber der schlechteste Testnutzer deiner eigenen Seite, deshalb ersetzt der Durchgang keinen Nutzertest – aber er findet die groben Steine, bevor du andere fragst.
05 ·
Schritt 2: Hypothese statt Einfall
Für Hypothesen kursiert in deutschen Ratgebern eine Formel: “Wenn wir X ändern, dann passiert Y, weil Z”. Sie ist brauchbar, aber sie lässt das Wichtigste weg.
Es gibt eine ältere, strengere Linie. Der Berater Craig Sullivan veröffentlicht seit den 2010er-Jahren einen “Hypothesis Kit”, den er über Jahre gemeinsam mit anderen Praktikern überarbeitet hat.
Was diese Vorlagen anders machen
Der entscheidende Unterschied liegt am Anfang des Satzes: Der Hypothesis Kit beginnt nicht mit der Idee, sondern mit dem Beleg. In der Fassung von Rik Higham und Colin McFarland aus dem Jahr 2016 liest sich der Entwurfsteil so: “Based on [quantitative/qualitative insight]. We predict that [product change] will cause [impact].”
Wer diesen ersten Teil nicht füllen kann, hat keine Hypothese, sondern einen Einfall. Dieselbe Vorlage hat außerdem einen zweiten Teil, der in der deutschen Kurzform fehlt: die vorab festgelegte Entscheidungsregel aus Laufzeit, Kennzahl und dem Unterschied, der als Wirkung gilt.
In Sullivans vierter Fassung von 2021 kommt ein dritter Block dazu: welcher Geschäftsnutzen daran hängt und welche Gegenkennzahl man mitbeobachtet, damit ein Gewinn an einer Stelle nicht unbemerkt einen Verlust an anderer erzeugt.
Das Hypothesen-Muster in fünf Zeilen
Angelehnt an den Hypothesis Kit, ausformuliert für kleine Teams
Weil wir beobachtet haben, dass … (Beleg und Quelle aus Sektion 4)
vermuten wir, dass … (eine konkrete Änderung)
dazu führt, dass … (eine Kennzahl, eine Richtung)
Wir erkennen es daran, dass … (Messgröße, Zeitraum, Entscheidungsregel)
Falls wir uns irren, sehen wir das an … (Gegenkennzahl)
Eigene Darstellung, Ostend Digital, Stand 08/2026, angelehnt an den Hypothesis Kit von Craig Sullivan und die Fassung von Rik Higham und Colin McFarland. Kein Zitat.
Zwei Prüfsätze, die dir Arbeit sparen
🚩 Steht im “Weil”-Teil “ich glaube” oder “das macht die Konkurrenz auch”, ist es keine Hypothese. Dort gehört eine Beobachtung aus einer der Quellen aus Sektion 4 hin.
🚩 Und wenn dir kein Ergebnis einfällt, das deine Vermutung widerlegen würde, ist es eine Überzeugung. Die darf man haben, nur sortiert man sie nicht in ein Backlog ein.
Schreib deine ersten drei Hypothesen
Wende das Muster jetzt an. Nimm die drei Einträge aus deinem Backlog, die dir am wichtigsten erscheinen, und schreib jeden in die fünf Zeilen um, mit dem, was dein Postfach-Durchgang und deine Anfrage-Strecke hergegeben haben.
Bei jedem Eintrag, dessen Weil-Zeile leer bleibt, hast du deine nächste Forschungsaufgabe gefunden. Er geht zurück in Sektion 4, nicht weiter in die Priorisierung.
06 ·
Schritt 3: Priorisieren mit ICE, PIE und PXL
Nach einer ordentlichen Forschungsrunde hast du dreißig Vermutungen und Zeit für drei. Dafür gibt es Priorisierungs-Frameworks, und die drei bekannten beantworten dieselbe Frage: Womit fange ich an?
| Framework | Urheber | Wie bewertet wird |
|---|---|---|
| ICE Impact, Confidence, Ease |
Geht auf Sean Ellis zurück, der auch den Begriff Growth Hacking geprägt hat | Drei Kriterien, je von 1 bis 10 geschätzt: Wirkung, Zuversicht, Aufwand |
| PIE Potential, Importance, Ease |
Chris Goward von der Agentur WiderFunnel | Drei Fragen: Wie viel ist auf dieser Seite zu holen, wie viel Verkehr steckt dahinter, wie aufwendig ist die Umsetzung |
| PXL | CXL, veröffentlicht am 27.09.2016 | Zehn bis zwölf Ja-Nein-Fragen plus eine Aufwandsstufe. Deutlich aufwendiger, dafür weniger Spielraum fürs Bauchgefühl |
Der wichtigste Eintrag dieser Tabelle steht in der Beschriftung. Keines der drei Verfahren ist in einer kontrollierten Untersuchung gegen die anderen geprüft worden. Sie haben sich verbreitet, weil sie wie ein Gesprächsleitfaden funktionieren, nicht weil ihre Wirksamkeit gemessen wurde.
Die Kritik, die alle drei trifft
Am schärfsten formuliert es CXL, ausgerechnet in der Vorstellung des eigenen Konkurrenzmodells: Wenn ich die Wirkung schätzen könnte, warum sollte ich dann noch testen? Der Einwand ist stark, kommt aber vom Wettbewerber.
Deshalb lohnt eine zweite Stimme. Der unabhängige Berater Oliver Palmer griff PIE 2020 mit der Frage an, ob ein PIE-Wert nicht bloß eine Ansammlung von Schätzungen sei, die als Zahl daherkommt. Im selben Beitrag nimmt er die Zuspitzung zurück und akzeptiert Gowards Gegenargument: Solche Rahmenwerke mischen naturgemäß Subjektives und Objektives, und die Einfachheit zwingt ein Team zum Argumentieren, statt Objektivität vorzutäuschen.
Was PXL anders macht
PXL ersetzt die Schätzskalen durch Fragen, die man überprüfbar mit Ja oder Nein beantwortet: Liegt die Änderung im sofort sichtbaren Bereich? Fällt sie in weniger als fünf Sekunden auf?
Vier der Fragen sind hier die interessantesten, denn sie belohnen ausschließlich, woher eine Idee stammt: aus einem Nutzertest, aus qualitativem Feedback, aus einer Verhaltensauswertung oder aus den Analytics. Die Idee aus der Montagsrunde bekommt keine Punkte.
Damit verbindet PXL die Priorisierung mit der Forschungsphase. Auch PXL ist ein Erfahrungswert aus Kundenarbeit, kein gemessenes Verfahren – es gilt also dieselbe Einordnung wie für ICE und PIE.
💡 Merke
Nimm das einfachste Verfahren, das du wirklich durchhältst, und schreib die Bewertung auf. Der Nutzen entsteht durch die nachvollziehbare Entscheidung, nicht durch die Zahl.
Eine ICE- oder PIE-Punktzahl sieht aus wie eine Messung und ist eine notierte Schätzung. Wer sie gegenüber Kunden oder Vorgesetzten als Zahl verkauft, täuscht Genauigkeit vor.
So sieht das konkret aus: Nimm dein Backlog und bewerte jede Vermutung mit ICE, also Wirkung, Zuversicht und Aufwand, je von 1 bis 10. Schreib zu jeder Zahl einen Halbsatz Begründung in die Bewertungs-Spalte, denn die Begründung ist das, was die Punktzahl später verteidigbar macht.
Plane dafür eine Viertelstunde ein, keinen Nachmittag. Die drei Einträge mit den höchsten Werten sind dein Arbeitsvorrat für die nächsten Wochen, der Rest bleibt sortiert liegen.
07 ·
Der Filter gegen spektakuläre Zahlen
Ein Teil deiner dreißig Ideen wird aus Artikeln stammen, in denen jemand eine große Zahl berichtet. Dieser Abschnitt ist der Filter dafür.
Der Lehrfall
2023 erschien im Journal of Consumer Research eine Arbeit von Dipayan Biswas, Annika Abell und Roger Chacko. Sie berichtete, dass allein das Abrunden der Ecken eines Buttons die Klickrate in einem A/B-Test um 55 Prozent erhöht habe, bei einem p-Wert von 0,037.
Ende 2025 legte eine Forschergruppe um Ronny Kohavi, darunter die Statistiker Andrew Gelman und Guido Imbens, drei eigene A/B-Tests dagegen vor, jeder mit über zweitausendmal so vielen Nutzern wie die Ausgangsstudie. Alle drei kamen auf Effekte, die rund zwei Größenordnungen kleiner waren, mit Konfidenzintervallen, die die Null einschließen. Zwei weitere unabhängige Replikationen fanden ebenfalls nur winzige Effekte.
Aus 55 Prozent wurde damit ungefähr ein Hundertstel davon, und selbst das ist statistisch nicht von null zu unterscheiden.
Warum das kein Zufall war
Der Grund steckt in der Größe des ersten Tests, und man braucht dafür keine Statistik. Ein kleiner Test kann kleine Unterschiede gar nicht erkennen. Damit ein Ergebnis überhaupt die Schwelle überspringt, ab der es als Fund gilt, muss der gemessene Effekt groß ausfallen.
Kleine Tests melden deshalb entweder nichts oder etwas Großes, und das Große ist im Schnitt zu groß. Die Fachwelt nennt das den Fluch des Gewinners: Ein gerade eben signifikanter Fund aus einem schwach besetzten Test überzeichnet den wahren Effekt nicht trotz, sondern wegen der kleinen Stichprobe.
💡 Merke
Je spektakulärer die Zahl und je kleiner der Test, desto sicherer ist sie zu groß.
Dazu passt ein alter Merksatz aus der Datenanalyse, Twyman’s Law: Jede Zahl, die interessant oder auffällig aussieht, ist meistens falsch. Er ersetzt kein Nachrechnen, aber er ist ein guter erster Reflex.
Was ein ehrlicher Datensatz zeigt
Die Sammlung GoodUI veröffentlicht A/B-Tests einschließlich der Verlierer und der ergebnislosen. Beim Abruf am 16.08.2026 standen dort 639 Tests aus rund 148,8 Millionen Besuchern: 166 Gewinner, 43 Verlierer und 430 Tests ohne statistisch belastbares Ergebnis.
Rund zwei Drittel dieser Sammlung endeten also unentschieden. Das ist keine allgemeine Erfolgsquote für A/B-Tests, sondern eine Eigenschaft dieser Sammlung. Betreiber ist ein Anbieter mit kostenpflichtigem Abo, die Zahlen stützen hier allerdings die unbequeme Aussage.
Hinter den berichteten Gewinnern steckt also eine große, meist unsichtbare Menge an Tests ohne Ergebnis.
Mach daraus eine feste Eingangskontrolle
Bevor eine fremde Erfolgszahl in dein Backlog darf, beantworte drei Fragen: Wie groß war der Test, wie ähnlich ist die getestete Seite deiner, und berichtet die Quelle auch ihre Verlierer und Unentschieden?
Kannst du keine der drei beantworten, übernimm die Idee trotzdem, aber als Vermutung mit leerer Weil-Zeile. Sie muss sich die Priorisierung dann genauso verdienen wie jede eigene Idee, und die berichtete Zahl spielt dabei keine Rolle mehr.
08 ·
Drei Denkfehler, die teuer werden
Der Fluch des Gewinners ist der bekannteste Fallstrick, aber nicht der häufigste. Drei weitere kosten in der Praxis mehr Zeit.
Fehler 1: Best Practices ohne Kontext kopieren
Eine Empfehlung, die irgendwo gewirkt hat, ist das Ergebnis eines Tests, auf einer Seite, mit einer Zielgruppe, in einem Marktumfeld. Übertragbar ist die Fragestellung, nicht die Lösung.
Colin McFarland bringt den Blick auf den Wettbewerb in seinem Buch “Experiment!” sinngemäß so auf den Punkt: Egal für wie selbstverständlich du eine Idee hältst, wie viel du recherchiert hast oder wie viele Wettbewerber es so machen, Experimentideen scheitern häufiger als gedacht.
Der handwerkliche Umgang damit: Wenn du eine Best Practice übernehmen willst, schick sie durch dieselbe Schleife wie jede eigene Idee. Formuliere sie als Hypothese und such den Weil-Beleg auf deiner eigenen Seite – findest du keinen, war es eine Mode, kein Kandidat.
Fehler 2: Die falsche Kennzahl verbessern
Fast jede Kennzahl lässt sich verbessern, ohne dass das Geschäft besser wird. Kohavi und Kollegen führen dafür ein bewusst plumpes Beispiel an: Gewinn taugt als Bewertungsmaßstab nicht, weil eine Preiserhöhung ihn kurzfristig steigert und langfristig schadet.
Im Web sieht das harmloser aus und passiert öfter. Mehr abgeschickte Formulare bei schlechterer Anfragequalität sind kein Fortschritt, sondern nur eine höhere Zahl. Leg deshalb vor der ersten Änderung fest, welche Größe zählt, und richte die Conversion-Messung darauf aus.
Fehler 3: An der falschen Stelle im Trichter arbeiten
Ein Rechenbeispiel, die Zahlen sind frei gewählt: Eine Seite bekommt 400 Besucher im Monat, 3 Prozent fragen an, macht 12 Anfragen. Eine sehr gute Seitenoptimierung auf 4 Prozent bringt 16. Kämen stattdessen 600 passende Besucher, wären es bei unveränderten 3 Prozent 18.
Daraus folgt nicht, dass Verkehr wichtiger wäre als die Seite, sondern dass du vorher ausrechnest, wo bei dir etwas zu holen ist. Mach die Rechnung mit deinen eigenen Zahlen auf: Besucher pro Monat mal Anfragequote, einmal mit einer besseren Quote, einmal mit mehr passenden Besuchern. Das dauert zwei Minuten und sagt dir, an welchem Ende du zuerst arbeitest.
Ein weiterer Fehler bekommt hier nur seinen Namen, weil die nächste Lektion ihn vollständig behandelt: testen ohne ausreichenden Verkehr. Was das rechnerisch bedeutet, steht in der Lektion zu Landing Pages.
09 ·
Wenn Testen nicht geht: Conversion Optimierung ohne Testverkehr
Für die meisten Websites kleiner Unternehmen ist der A/B-Test keine verfügbare Option.
Die nötige Stichprobe pro Variante liegt um Größenordnungen über dem, was diese Seiten im Monat an Besuchern sehen. Wie man diese Schwelle ausrechnet, behandelt die nächste Lektion. An dieser hier ändert das nichts.
Denn der Test ist der letzte Schritt der Methode, nicht die Methode. Forschen, Hypothese bilden und priorisieren funktionieren bei 300 Besuchern im Monat genauso wie bei 300.000. Nur der Beweis am Ende fällt weg.
Warum Vorher-Nachher kein Ersatz ist
Der naheliegende Ausweg lautet: Ändern wir es eben und schauen, ob die Anfragen steigen. Das ist methodisch eine Beobachtung und kein Experiment.
Kohavi und Kollegen zitieren dazu eine Untersuchung von Young und Karr, die publizierte Ergebnisse aus medizinischen Beobachtungsstudien mit randomisierten klinischen Studien verglich. Deren Fazit fällt drastisch aus: Jede Behauptung aus einer Beobachtungsstudie sei höchstwahrscheinlich falsch. Kohavis eigene Begründung fürs Web: Äußere Schwankungen überlagern die Effekte, die man messen will.
Zwischen “vorher” und “nachher” ändert sich eben nie nur die Seite. Saison, Werbebudget, ein Wettbewerber, ein Suchmaschinen-Update – all das bewegt die Zahlen stärker als die meisten Seitenänderungen.
Die Beweislast verschieben, nicht abschaffen
Wenn der Test als Nachweis wegfällt, wird die Qualität des Belegs vor der Änderung zum Ersatz. Genau danach fragt PXL: Kommt die Idee aus einem Nutzertest, aus Feedback, aus den Analytics oder aus dem Bauch? Bei wenig Verkehr wird das die wichtigste Frage überhaupt.
Wenn die Datenmenge keine Tests hergibt, arbeitest du nach den folgenden fünf Regeln. Sie sind Handwerksempfehlung: begründet, aber nicht gemessen.
- 📌 Mehrere unabhängige Quellen zur Deckung bringen. Eine Änderung, die zugleich aus dem Heuristik-Durchgang, aus wiederkehrenden Support-Anfragen und aus dem Analytics-Absprung folgt, braucht keinen Test mehr, um vertretbar zu sein.
- 📌 Nur große, begründete Änderungen umsetzen. Wer nicht messen kann, sollte nichts umsetzen, dessen Wirkung ohnehin nur messbar wäre. Bei Nuancen weiß man hinterher nichts.
- 📌 Qualitativ validieren statt statistisch. Ein paar Nutzertests nach der Änderung beantworten “verstehen es die Leute jetzt?”. Der Ablauf steht in der Lektion zu User Experience.
- 📌 Vorher-Nachher benutzen, aber ehrlich benennen. Setz die Messung auf, bevor du irgendetwas änderst: Notiere heute Besucher und Anfragen pro Monat für die letzten Monate, halte später das Datum jeder Änderung fest und lies den Vergleich als Indiz, nicht als Beweis.
- 📌 Sequenziell arbeiten, nicht parallel. Eine Änderung nach der anderen. Wer drei Dinge gleichzeitig ändert, kann nicht einmal mehr ein Indiz zuordnen.
Du gibst damit die Gewissheit über die Größe eines Effekts auf und behältst die Begründung, warum diese Änderung dran war und die anderen 29 nicht.
Experten-Tipp aus der Agentur
Führ eine einzige Datei, in der jede Änderung mit Datum, Hypothese und Ausgangszahl steht. Das klingt nach Bürokratie und ist der Unterschied zwischen einem Jahr Arbeit und einem Jahr Erinnerung.
Und wer dir sagt “testen lohnt sich bei euch nicht, wir arbeiten belegorientiert”, beschreibt eure Lage meist korrekt, statt euch etwas wegzunehmen.
Pascal Cabitza
Geschäftsführer Ostend Digital
10 ·
💡 Recap
Conversion Optimierung in 30 Sekunden:
- Der Ablauf ist eine Schleife: forschen, vermuten, sortieren, umsetzen, lernen. Du arbeitest sie in einer einzigen Datei ab, mit den Spalten Beleg, Vermutung, Bewertung, Ergebnis
- Der Grund für das Verfahren ist belegt. Kohavi und Kollegen berichten 2013, dass nur ein Drittel der bei Microsoft getesteten Ideen die Kennzahl verbesserte, für die sie gebaut wurden. Sie schränken selbst ein, dass nicht jedes Umfeld so schlechte Werte hat
- Quellen beantworten unterschiedliche Fragen. Analytics sagt wo, dein Postfach und Nutzertests sagen warum. Frag nach Erlebtem, nicht nach Absichten
- Eine Hypothese beginnt mit dem Beleg und enthält die Entscheidungsregel: Kennzahl, Zeitraum, Gegenkennzahl. Was die Weil-Zeile nicht füllt, geht zurück in die Forschung, nicht ins Backlog
- ICE, PIE und PXL strukturieren deine Entscheidung. Keines der drei ist gegen die anderen geprüft worden – schreib deshalb die Begründung neben jede Punktzahl. PXL fragt als einziges danach, woher eine Idee stammt
- Große Effekte aus kleinen Tests sind im Schnitt zu groß. Die 2023 berichteten 55 Prozent durch runde Button-Ecken schrumpften in Replikationen mit dem Zweitausendfachen an Nutzern auf rund ein Hundertstel, mit Konfidenzintervallen einschließlich null. Fremde Zahlen kommen deshalb nur durch die Eingangskontrolle ins Backlog
- Ohne Testverkehr bleibt die Methode gültig. An die Stelle des Beweises danach tritt die Belegqualität davor: mehrere Quellen zur Deckung bringen, nur große Änderungen, eine nach der anderen, Vorher-Zahlen notiert. Ein Vorher-Nachher-Vergleich bleibt dabei ein Indiz
11 ·
Selbstcheck: kannst du das beantworten?
Ein Artikel berichtet, eine kleine Designänderung habe die Klickrate um 55 Prozent gesteigert. Was machst du damit?
Zuerst nach der Größe des Tests fragen, nicht nach der Größe des Effekts. Ein kleiner Test kann kleine Unterschiede gar nicht erkennen, also muss ein berichteter Fund dort groß ausfallen, um als Ergebnis zu gelten.
Für genau diesen Fall ist das dokumentiert: In den Replikationen blieb rund ein Hundertstel übrig. Die Idee darf trotzdem ins Backlog, aber als Vermutung, nicht als Regel.
Deine Analytics zeigen, dass die meisten Besucher die Preisseite sofort wieder verlassen. Ist das eine Hypothese?
Nein, das ist ein Befund. Er sagt, wo es klemmt, und nicht warum.
Der nächste Schritt ist eine qualitative Quelle: eine kurze Frage auf der Seite, zwei Nutzertests oder ein Blick in die Fragen, die im Vertrieb ohnehin gestellt werden. Erst deren Ergebnis füllt den Weil-Teil deiner Hypothese.
Angenommen, die Antwort lautet: “Ich habe den Preis nicht gefunden.” Dann klingt deine Hypothese so: Weil Besucher in zwei Nutzertests den Preis nicht gefunden haben, vermuten wir, dass eine Preisangabe oberhalb der Faltung dazu führt, dass mehr Besucher zum Kontaktformular scrollen.
Wir erkennen es daran, dass die Scrolltiefe über vier Wochen steigt. Falls wir uns irren, sehen wir das an einer sinkenden Anfragequalität.
Deine Seite hat 400 Besucher im Monat. Lohnt sich Conversion Optimierung überhaupt?
Ja, nur ohne den A/B-Test am Ende. Forschen, Hypothese und Priorisierung sind von der Besuchermenge unabhängig, der statistische Nachweis nicht.
Statt des Beweises danach zählt die Belegqualität davor: mehrere unabhängige Quellen auf dieselbe Stelle, nur große Änderungen, eine nach der anderen. Die Vorher-Zahl notierst du trotzdem, du liest sie nur als Indiz.
Jemand legt eine ICE-Bewertung vor, dein Vorschlag landet auf Platz sieben. Was fragst du?
Nach der Begründung der einzelnen Werte, vor allem beim geschätzten Effekt. Genau daran setzt die bekannteste Kritik an: Wer die Wirkung zuverlässig schätzen könnte, müsste nicht mehr testen.
Eine ICE-Zahl ist eine notierte Schätzung, keine Messung. Sie ist nützlich, solange sie eine Diskussion strukturiert, und nicht, wenn sie eine beendet.
Alle Lektionen des Webdesign- und CRO-Kurses im Überblick →
Quellen und Stand (14 Einträge)
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y., Pohlmann, N. (2013): “Online Controlled Experiments at Large Scale”, KDD ’13, S. 1168-1176 – Abschnitt “Tenet 3: We are poor at assessing the value of ideas” mit dem Satz “Only one third of the ideas tested at Microsoft improved the metric(s) they were designed to improve” und der Einschränkung “Not every domain has such poor statistics”; ferner der OEC-Abschnitt (Gewinn als ungeeigneter Bewertungsmaßstab, Suchmaschinen-Beispiel) und Abschnitt “Why Controlled Experiments?” mit dem Young-und-Karr-Zitat “Any claim coming from an observational study is most likely to be wrong” und “Our experience is that external variations overwhelm the effects we are trying to detect”. Quellentyp: peer-reviewter Konferenzbeitrag. Interessenlage: Die Autoren betreiben Microsofts Experimentierplattform, die zitierten Zahlen sprechen gegen das Eigeninteresse der Produktteams. Zitate über eine PDF-Textextraktion erfasst (abgerufen 16.08.2026)
- Kohavi, R., Linowski, J., Vermeer, L., Boisseranc, F., Furuseth, J., Gelman, A., Imbens, G., Rajagopal, R.: “Power Analysis is Essential: High-Powered Tests Suggest Minimal to No Effect of Rounded Shapes on Click-Through Rates”, arXiv:2512.24521 (v1 30.12.2025, v3 06.04.2026) – drei hochbesetzte Replikationen mit jeweils über dem Zweitausendfachen an Nutzern, Effektschätzer rund zwei Größenordnungen kleiner, 95-Prozent-Konfidenzintervalle einschließlich null, zwei weitere unabhängige Replikationen durch Evidoo; Beschreibung des Winner’s Curse bei Studien unter 50 Prozent Power. Preprint, der Peer-Review-Status wurde nicht geprüft. Interessenlage: mehrere Autoren verkaufen Experimentation-Beratung beziehungsweise ein Abo-Produkt, die Arbeit argumentiert allerdings gegen den Markt spektakulärer Uplift-Zahlen (abgerufen 16.08.2026)
- Biswas, D., Abell, A., Chacko, R. (2023): Arbeit im Journal of Consumer Research, in der eine Steigerung der Klickrate um 55 Prozent durch abgerundete Button-Ecken bei einem p-Wert von 0,037 berichtet wird. In dieser Lektion ausschließlich als Ausgangspunkt der Replikation aus Eintrag 2 verwendet, nicht als Gestaltungsempfehlung. Angaben zur Studie über Eintrag 2 erfasst, die Originalarbeit wurde nicht selbst abgerufen
- Nielsen, J.: “First Rule of Usability? Don’t Listen to Users”, Nielsen Norman Group, 04.08.2001, laut Seite seither mit neueren Forschungsergebnissen aktualisiert – “self-reported data is typically 3 steps removed from the truth”, die drei Gründe (soziale Erwünschtheit, unzuverlässige Erinnerung, nachträgliche Rationalisierung), “Definitely don’t believe what people predict they may do in the future” und die Empfehlung “Watch what people actually do”. Quellentyp: Praktiker-Institut. Interessenlage: verkauft UX-Forschung, Kurse und Berichte. Der zugespitzte Titel richtet sich gegen Absichts- und Präferenzfragen, nicht gegen Befragung an sich (abgerufen 16.08.2026)
- CXL: “PXL: A Better Way to Prioritize Your A/B Tests”, veröffentlicht 27.09.2016 – Aufbau aus zehn bis zwölf Ja/Nein-Fragen, darunter “Is the change above the fold?”, “Is the change noticeable in under 5 seconds?” und “Does the test run on high traffic pages?”, die vier Herkunftsfragen zu Nutzertest, qualitativem Feedback, Mouse-Tracking und Analytics, die Aufwandsstaffelung sowie die Selbsteinschätzung, man sei nach Versuchen in der eigenen Kundenarbeit zu einem Modell gekommen, das “helped us and our clients prioritize their tests”; dort auch der Einwand gegen Schätzskalen (“if I could guess what the impact would be, why would I even test it?”). Quellentyp: Agentur- und Schulungsanbieter, PXL ist das eigene Framework, die Kritik an ICE und PIE stammt damit vom Wettbewerber. Der direkte Abruf liefert HTTP 403, gelesen über einen Textproxy, ein Autorenname ist auf der abgerufenen Fassung nicht ausgewiesen (abgerufen 16.08.2026)
- CXL: “Conversion Research to Identify Better A/B Tests” – Definition der Conversion-Forschung und die Bausteine des ResearchXL-Modells (technische, heuristische, analytische und qualitative Analyse, Nutzertests, Copy-Testing). Abruf über Textproxy, kein belastbares Publikationsdatum, deshalb ohne Datumsangabe verwendet. Interessenlage wie Eintrag 5 (abgerufen 16.08.2026)
- Palmer, O.: “PIE prioritisation method”, oliverpalmer.com, 24.01.2020 – die Kritik, ein PIE-Wert sei letztlich eine Zusammenfassung mehrerer Schätzungen in einer Zehnerskala, sowie die im selben Beitrag akzeptierte Gegenposition von Chris Goward, dass strategische Rahmenwerke Subjektives und Objektives mischen und die Einfachheit ein Vorteil ist. Quellentyp: unabhängiger Berater, verkauft Experimentation-Beratung, aber kein konkurrierendes Framework (abgerufen 16.08.2026)
- Sullivan, C.: “Hypothesis Kit V4”, optimiseordie.medium.com, 07.05.2021 – Dreiteilung in Theory, Validation und Outcome, Mitbeobachtung negativer Auswirkungen, Verknüpfung mit Geschäftszielen; Selbstaussage einer über acht Jahre fortgeschriebenen Überarbeitung. Quellentyp: Praktiker-Publikation ohne Peer Review, Interessenlage: verkauft Beratung und Trainings. Ein Entstehungsjahr des ersten Kits ist nirgends ausgewiesen, deshalb steht in der Lektion nur “seit den 2010er-Jahren” (abgerufen 16.08.2026)
- Higham, R.: “Hypothesis Kit for A/B testing”, medium.com, 14.04.2016 – die wörtliche Entwurfsvorlage “Based on [quantitative/qualitative insight]. We predict that [product change] will cause [impact].” und die zugehörige Testvorlage mit Nullhypothese, Laufzeit, Effektgröße und Kennzahl. Entwickelt laut derselben Quelle mit Colin McFarland, aufbauend auf dem ursprünglichen Hypothesis Kit von Craig Sullivan. Quellentyp: Praktiker-Publikation (abgerufen 16.08.2026)
- GoodUI (Jakub Linowski), Musterdatenbank goodui.org/patterns – Stand des Abrufs am 16.08.2026: 639 Tests, 141 Muster, 148.828.209 Besucher, davon 166 Gewinner, 43 Verlierer und 430 statistisch nicht signifikante Tests; Selbstaussage “We publish everything”. Quellentyp: kommerzielle Abo-Datenbank, Interessenlage offengelegt. Die Zwei-Drittel-Quote ist eine Eigenschaft dieser Sammlung und keine allgemeine Erfolgsquote von A/B-Tests (abgerufen 16.08.2026)
- ICE-Zuschreibung an Sean Ellis: ausschließlich über Sekundärquellen erfasst, unter anderem das ProductPlan-Glossar zum ICE Scoring Model sowie weitere Produktmanagement- und Growth-Blogs. Eine Primärquelle von Sean Ellis wurde nicht abgerufen, deshalb nennt die Lektion weder ein Entstehungsjahr noch ein Zitat noch einen konkreten Entstehungskontext (abgerufen 16.08.2026)
- PIE-Zuschreibung an Chris Goward und die Agentur WiderFunnel sowie die Jahresangabe 2012 zum Buch “You Should Test That!”: ebenfalls nur über Sekundärdarstellungen erfasst, das Buch wurde nicht geprüft. Die Sekundärquellen widersprechen sich beim Rechenweg (multiplizieren gegen mitteln), deshalb nennt die Lektion die drei Fragen und keine Formel (abgerufen 16.08.2026)
- McFarland, C.: “Experiment!”, S. 20 – “No matter how much you think it’s a no-brainer, how much research you’ve done, or how many competitors are doing it, sometimes, more often than you might think, experiment ideas simply fail.” In dieser Lektion sinngemäß wiedergegeben. Zitat zweiter Hand, erfasst über Eintrag 1, das Buch selbst wurde nicht abgerufen. Ebenso als Konvention gekennzeichnet: Twyman’s Law (“Any figure that looks interesting or different is usually wrong”) ist ein in der Datenanalyse geläufiger Merksatz; die Fundstelle innerhalb von Eintrag 1 ließ sich in der Textextraktion nicht abschließend reproduzieren, deshalb steht in der Lektion keine Fundstellenangabe
- Weitere Prozessmodelle, nur zur Einordnung als konkurrierende Ablaufbeschreibungen genannt: Conversion Rate Experts, “CRE Methodology” (Volltext nicht abgerufen, über Suchlauf und Sekundärdarstellung erfasst) sowie die Prozessdarstellungen von Anbietern von A/B-Testing-Software (nur über Trefferlisten erfasst, keine Volltexte). Zu keinem dieser Modelle werden in der Lektion Details behauptet, und keines wird als Wirksamkeitsbeleg verwendet. Die Beobachtung, dass Prozessmodelle von Werkzeuganbietern strukturell im Testschritt münden, ist eine redaktionelle Einordnung von Ostend Digital, keine Quellenaussage (abgerufen 16.08.2026)
Viele Ideen, wenig Gewissheit, welche zuerst dran ist?
Wir sammeln die Belege, bauen daraus eine sortierte Liste von Hypothesen und sagen ehrlich dazu, was sich bei eurer Datenmenge beweisen lässt und was nicht.
