Conversion Optimierung mit KI: Bandit vs. A/B-Testing nach 30 Tagen

Für die Conversion Optimierung meiner meistbesuchten Landingpage stellte ich den nächsten A/B-Test zurück und ließ stattdessen einen KI-gestützten Multi-Armed Bandit die Ausspielung übernehmen. Dreißig Tage später gab es mehr Anmeldungen, die schwächste Variante erhielt automatisch kaum noch Traffic – nur eine statistisch signifikante Attributionszahl konnte ich nicht liefern, weil ein Bandit genau das nicht erzeugt. Dieser Zielkonflikt ist die eigentliche Geschichte.

Conversion Optimierung: das Ergebnis – und der Haken

Die Landingpage ist eine ausführliche Angebotsseite, die kalten Paid Traffic und warme organische Besuche in Testanmeldungen umwandelt. In den 30 Tagen vor dem Wechsel zum Bandit lag die Ausgangs-Conversion-Rate für Anmeldungen bei 3.41%. Dieselbe Seite, dasselbe Angebot, derselbe Traffic-Mix: In den 30 Tagen nach Übergabe der Ausspielung an den Bandit waren es 4.62%. Bezogen auf das primäre Conversion-Ereignis entspricht das einem relativen Plus von 35.5%.

Der Haken, bevor diese Zahl als Screenshot die Runde macht: Es handelt sich um einen Zuwachs beim kumulierten Ergebnis, nicht um einen kausal identifizierten Effekt. Ein Multi-Armed Bandit verschiebt Traffic zu der Variante, die in diesem Moment führt. Er hält die Verteilung nicht lange genug sauber bei 50/50, um für eine einzelne Variante ein Konfidenzintervall zu liefern. Es gibt keinen p-Wert. Es gibt kein „Variante B schlug Variante A mit 95% Konfidenz“. Feststellen lässt sich lediglich: „Über die gesamte Besucherpopulation hinweg konvertierten mehr Menschen als im vorangegangenen Kontrollzeitraum.“ Das sind unterschiedliche Aussagen – und ein Board, das den Unterschied kennt, wird wissen wollen, welche davon gemeint ist.

Zur Kostenseite: Über die 30 Tage liefen ~84,000 Seitenaufrufe durch den Bandit. Die Tool-Kosten betrugen $299 für einen Monat Webflow Optimize im Tarif für 100K Aufrufe, dazu kam ein Coframe-Pilotprojekt mit Contact-Sales-Preisen – dazu gleich mehr. Insgesamt blieben die Plattformkosten unter $500, während eine Seite mit relevantem Testanmeldungsvolumen real zulegte. Die Rechnung geht auf. Der Vorbehalt bei der Attribution bleibt dennoch bestehen.

Das Setup – warum der A/B-Plan gestrichen wurde

Die Seite liegt am Ende zweier Traffic-Ströme: bezahlter Meta-Traffic aus der bereits beschriebenen Rotation aus AdCreative.ai, Pencil Pro und einer menschlichen Kontrollvariante sowie organischer Traffic und Verweise aus KI-Suchmaschinen, die aus dem 14-Tage-Playbook für GEO stammen. Insgesamt sind das ungefähr 2,800 Sessions pro Tag, bei einer von Woche zu Woche schwankenden 30/70-Verteilung zwischen Paid und Organic.

Für einen sauberen A/B-Test ist genau dieses Traffic-Profil denkbar ungeeignet. Um bei einer Basis-Conversion-Rate von 3.4% einen relativen Lift von 10% mit 80% Teststärke zu erkennen, brauchte ich ungefähr 50,000 Besucher pro Arm – bei einer festen 50/50-Verteilung also rund 35 Tage für einen Test mit zwei Armen. Fünf Wochen lang sollte eine bekanntermaßen schwächere Variante 50% des bezahlten Traffics erhalten, nur damit statistische Signifikanz erreicht wird. Bei einem CPL von $24 auf der Paid-Seite verbrannte jeder Prozentpunkt ihrer Minderleistung ganz real Geld – und zwar absichtlich.

Das ist das Regret-Problem. Ein A/B-Test besteht aus reiner Exploration: Die Verteilung bleibt gerade deshalb fest, weil statistische Teststärke gebraucht wird. Der Preis dafür ist, dass die Hälfte der Besucher während des gesamten Laufs die schlechtere Erfahrung sieht. Ein Bandit tauscht diese saubere Inferenz gegen ein besseres kumuliertes Ergebnis. Er nutzt die führende Variante stärker, testet die anderen aber weiter; empirische Vergleiche zeigen bei stationären Problemen 30–60% weniger kumulativen Regret als bei A/B-Tests mit Gleichverteilung.

Meine Entscheidungsregel vor dem Start:

• Ein Bandit, wenn der Traffic im Verhältnis zum gesuchten Effekt knapp ist, die Ausspielung der schwächeren Variante teuer wird, die Seite ohne festes Kampagnenfenster dauerhaft läuft und die kumulierten Conversions dieses Quartals wichtiger sind als eine belastbare Kausalzahl.
• A/B-Testing, wenn der Lift gegenüber den Verantwortlichen für die P&L verteidigt werden muss, wenn die Änderung groß und selten ist – etwa bei Preis, Hero-Bereich oder Positionierung – oder wenn sich die Varianten zu stark unterscheiden, um gemeinsam aus ihnen zu lernen.

Diese Seite erfüllte sämtliche Bandit-Kriterien. Also strich ich den geplanten A/B-Test und startete den Bandit.

Der Stack – jedes Tool und alle Kosten

Ich prüfte vier Tools für eine kontinuierliche, KI-gestützte Optimierung statt klassischer A/B-Abläufe. Zwei setzte ich produktiv ein, zwei bewertete ich ernsthaft und verwarf sie für diesen Durchlauf. Das ist die ungeschönte Bilanz.

Coframe. Ein modifizierter Multi-Armed-Bandit-Optimierer, der Varianten für Texte, Visuals und sogar Komponentencode erzeugt und den Traffic anschließend über seinen Bandit verteilt. Die Installation erfolgt per Script-Tag. Das Unternehmen hat rund $9M eingesammelt. Preise gibt es nur auf Anfrage; eine öffentliche Preisseite fehlt. Schon das ist ein Planungssignal: unberechenbares Budget, ein Vertriebsprozess vor dem ersten Test und ein Enterprise-Ansatz, der für Einzelanwender wenig attraktiv ist. Ich führte ein Pilotprojekt durch. Die Qualität der generierten Varianten war die beste unter den vier Tools. Der Beschaffungsaufwand war der höchste.

Webflow Optimize. Basiert auf der Intellimize-Engine, die Webflow übernommen hat. Der Standardtarif kostet $299/month für 100K Seitenaufrufe; weitere Stufen liegen bei 25K, 50K, 100K, 250K und 500K. Bis zu 5 Tests können gleichzeitig laufen. Das Tool funktioniert ausschließlich auf von Webflow gehosteten Seiten. Für meinen Fall war das kein Problem, für jede andere Plattform ist es ein Ausschlusskriterium. Darauf lief der 30-tägige Produktionseinsatz, denn die Seite war bereits in Webflow und die Kalkulation des Webflow-Tarifs ohnehin bezahlt.

Optimizely Opal. Agentenbasierte Experimente auf der bestehenden Optimizely-Plattform. Laut den von Optimizely selbst veröffentlichten Zahlen führen Nutzer von Opal 78.7% mehr Experimente und 24.1% mehr Personalisierungskampagnen durch; außerdem steigt ihre Erfolgsquote um 9.3%. Das sind Anbieterzahlen auf Basis einer Anbietermethodik und sollten entsprechend eingeordnet werden. Die Preise liegen auf Enterprise-Niveau. Für ein Team mit bestehendem Optimizely-Vertrag kann das sinnvoll sein, für eine einzelne Landingpage war es das nicht.

VWO Copilot. Ein Stack aus Testing, Insights und Personalize mit einer zusätzlichen KI-Ebene. Es ist die etablierteste Plattform im Vergleich und behält unter den KI-Features am stärksten das klassische A/B-Denkmuster bei. Meine Wahl wäre VWO, wenn ein sauberer A/B-Prozess mit KI-Unterstützung gefragt wäre – nicht ein Bandit-zentrierter Ablauf, der A/B optional anbietet.

Für diesen Durchlauf lief Webflow Optimize die vollen 30 Tage in Produktion. Coframe kam parallel als Pilotprojekt auf einer sekundären Seite zum Einsatz, um die Variantenqualität zu vergleichen.

Das 30-Tage-Playbook, Tag für Tag

Tage 0–3: Instrumentieren und einfrieren. Es gab genau ein Conversion-Ereignis: die serverseitig bestätigte Testanmeldung, keinen Button-Klick. Was clientseitig gezählt wird, bläht alle Varianten gleichermaßen auf und lässt Rauschen wie einen Erfolg aussehen. Die Kontrolle wurde eingefroren: Die bestehende Seite blieb unverändert als Variante A und erhielt über den gesamten Lauf garantiert mindestens 20% Gewicht. So blieb eine Kontrollkohorte für den späteren Vergleich erhalten. Ohne diesen Mindestanteil hätte der Bandit die Kontrolle kaum noch ausgespielt, sobald sich ein Spitzenreiter abzeichnete – und es wäre nichts zum Vergleichen übrig geblieben.

Tage 4–10: Varianten erzeugen und lernen lassen. Ich startete mit vier Varianten, die unterschiedliche Hero-Überschriften und Texte für den primären CTA sowie eine andere Reihenfolge des Social-Proof-Blocks kombinierten. Die erste Woche ist die Explorationsphase des Bandit. Die Verteilung wirkte fast gleichmäßig: 22%, 19%, 21%, 18% und 20% für Kontrolle plus vier Varianten an Tag 7. Genau an diesem Punkt greifen viele Verantwortliche nervös ein. Das ist ein Fehler. Wer Varianten mitten im Lernprozess verändert, setzt die Priors zurück und verliert die Woche.

Tage 11–21: Die Kurve der Neuverteilung. Um Tag 12 begann der Bandit, den Traffic sichtbar zu verschieben. An Tag 18 erhielt die führende Variante 41%, die Kontrolle blieb bei ihrem Mindestanteil von 20%, zwei mittlere Varianten lagen bei jeweils ~15% und die schlechteste Variante wurde auf unter 10% gedrosselt. Genau das soll der Bandit tun: Jeder Besucher auf der schwächsten Variante erzeugt Regret, und der Algorithmus minimiert ihn in Echtzeit.

Tage 22–30: Festschreiben und entscheiden. Ich schrieb die erfolgreiche Richtung fest – nicht die konkrete Variante, sondern das Muster: kürzerer Hero-Bereich, nutzenorientierter CTA, Social Proof oberhalb des sichtbaren Bereichs. Danach exportierte ich die Varianten. Die Frage an Tag 30 lautet: Wird die führende Variante gegen die Kontrolle in einen sauberen A/B-Test überführt, um eine Kausalzahl für das Board zu gewinnen? Oder läuft der Bandit mit der nächsten Variantenrunde weiter?

Während des gesamten Laufs galten Leitplanken: mindestens 20% Traffic für die Kontrolle, ein Kill-Switch, sobald die Untergrenze des Konfidenzintervalls einer Variante mehr als 48 Stunden lang einen relativen Einbruch von 50% gegenüber der Kontrolle zeigte, sowie eine wöchentliche Prüfung des Traffic-Mix. Verschob sich der Paid/Organic-Anteil innerhalb einer Woche um mehr als 10 Punkte, sollte der Bandit bis zur Stabilisierung pausieren. Nicht stationärer Traffic ist der stille Killer.

Das Attributionsproblem – der ehrliche Kern

Dieser Abschnitt fehlt in den üblichen Vergleichslisten – und er ist der einzige Grund für diesen Beitrag.

Ein Multi-Armed Bandit kann konstruktionsbedingt keine statistische Signifikanz für eine einzelne Variante liefern. Die statistischen Instrumente des A/B-Testing – p-Werte, Konfidenzintervalle und Teststärkeberechnungen – setzen eine feste Zuteilungsregel voraus. Der zentrale Nutzen eines Bandit besteht gerade darin, dass diese Regel nicht fest ist: Sie passt sich an die frühen Daten an. Sobald die Zuteilung von den Ergebnissen abhängt, bricht die klassische Inferenz zusammen. In jedem Arm entstehen verzerrte Stichproben. Die kumulierten Conversions über die gesamte Population lassen sich weiterhin messen. Eine saubere kausale Aussage zu Variante B gegenüber Variante A ist nicht möglich.

Das ist kein Fehler, sondern Absicht. Der Bandit optimiert ein anderes Ziel: kumulativen Regret minimieren und kumulierte Conversions maximieren. Empirische Vergleiche zeigen bei stationären Problemen durchgehend 30–60% weniger Regret als bei A/B-Tests mit Gleichverteilung. „Weniger Regret“ ist die Kennzahl. „Kausal nachgewiesener Lift durch Variante B“ ist es nicht.

Daraus folgt eine strenge sprachliche Trennung:

• Vertretbar: „Nach Einführung des Bandit erzielte die Seite über 84,000 Besucher und 30 Tage hinweg eine Conversion-Rate von 4.62%, gegenüber 3.41% auf derselben Seite in den vorangegangenen 30 Tagen.“
• Nicht vertretbar: „Variante B verursachte einen Anstieg der Conversion-Rate um 35%.“

Die erste Formulierung beschreibt ein kumuliertes Ergebnis. Die zweite behauptet Kausalität – und die kann ein Bandit nicht belegen.

Meine halbe Lösung war der Kontroll-Mindestanteil von 20%. Da die ursprüngliche Seite über die vollen 30 Tage garantiert 20% des Traffics erhielt, blieb eine kleine, aber saubere Vergleichskohorte. Die Kontrollkohorte konvertierte während des Laufs mit 3.38% und blieb damit praktisch unverändert gegenüber dem Ausgangswert aus den vorangegangenen 30 Tagen. Die Nicht-Kontrollkohorte erreichte 4.93%. Das liefert eine klare Richtung: Der Zuwachs ist real und kein Saisoneffekt. Ein sauberes A/B-Ergebnis ist es trotzdem nicht, denn auch der Bucket ohne Kontrolle besteht aus einem wechselnden Variantenmix. Für das Board reicht es jedoch, um zu sagen: „Der Lauf schlug seine eigene interne Kontrollgruppe. Hier ist die Differenz, und hier ist klar abgegrenzt, was wir daraus ableiten – und was nicht.“

Ist eine belastbare Kausalzahl erforderlich, dient der Bandit zunächst dazu, die aussichtsreichste Richtung zu finden. Danach tritt die führende Variante in einem A/B-Test mit 50/50-Verteilung gegen die Kontrolle an. Dieser Ablauf berücksichtigt sowohl das Regret-Budget des operativen Teams als auch den Beweisstandard der Analyse.

Wo der Bandit nicht überzeugte

Dasselbe Playbook testete ich auf zwei Seiten, auf denen der Bandit schlechter abschnitt als ein einfacher A/B-Test. Die erste war eine Pricing-Seite mit wenig Traffic – unter 400 Sessions pro Tag. Der Bandit brauchte zu lange, um die Explorationsphase zu verlassen, und die Richtungssignale blieben verrauscht. Ein einfacher A/B-Test mit 50/50-Verteilung über sechs Wochen lieferte eine klarere Antwort bei weniger operativem Aufwand. Beim zweiten Fall handelte es sich um einen Checkout-Prozess, bei dem das Conversion-Ereignis erst 3–5 Tage nach Ausspielung der Variante eintrat. Bandits setzen einigermaßen zeitnahes Feedback voraus. Ein langer Abstand zwischen Ausspielung und Ergebnis führt dazu, dass der Algorithmus anhand veralteter Daten umverteilt und Phantomsignalen folgt.

Von den generierten Varianten verwarf ich etwa 40% der Coframe-Ergebnisse und einen kleineren Anteil der Ergebnisse von Webflow Optimize. Die Warnzeichen waren die üblichen: Gedankenstriche an unpassenden Stellen, generische Kraftverben und parallele Aufzählungsrhythmen, die wie der Versuch eines Modells klangen, einen Marketer nachzuahmen. Alles, was im Uncanny Valley der Markenstimme landete, wurde aussortiert, bevor es Traffic erhielt. Diese Ablehnungsquote ist der Kostenfaktor, der auf keiner Preisseite steht.

In Woche drei wäre ich beinahe in die Falle des nicht stationären Traffics geraten. Der Anteil des Paid Traffic sprang innerhalb von vier Tagen von 30% auf 47%, weil eine Meta-Kampagne skaliert wurde. Die führende Variante des Bandit hatte bei einem anderen Traffic-Mix gewonnen als dem, der nun eintraf, und ihre Conversion begann nachzulassen. Ich pausierte den Bandit für 48 Stunden, ließ den Mix stabil werden und startete mit einer frischen Explorationsphase neu. Wäre er weitergelaufen, hätte er aus einem vorübergehend anderen Publikum die falsche Lektion gelernt.

Das wiederholbare Prinzip

Die Entscheidungsregel, verallgemeinert und von den Besonderheiten meiner Seite befreit:

Ein Bandit passt, wenn der Traffic im Verhältnis zum nachzuweisenden Lift knapp ist, die Ausspielung einer schwächeren Variante an die Hälfte der Besucher spürbare Kosten verursacht, die Seite ohne Kampagnenfenster dauerhaft läuft und die kumulierten Conversions dieses Quartals wichtiger sind als eine belastbare Kausalzahl für eine einzelne Variante. Ein A/B-Test passt, wenn der Lift gegenüber den Verantwortlichen für die P&L verteidigt werden muss, wenn die Änderung groß und selten genug ist, um vor der dauerhaften Einführung eine saubere Antwort zu verlangen, oder wenn die erfolgreiche Variante auf andere Flächen skaliert werden soll und feststehen muss, dass sie tatsächlich funktioniert hat.

Die meisten operativen Teams werden beide Methoden einsetzen. Den Bandit auf dauerhaft aktiven Conversion-Flächen – Startseite, primäre Angebotsseite, Anmeldeprozess. Den A/B-Test für Richtungsentscheidungen – Preise, Positionierung, Neufassung des Hero-Bereichs. Der Fehler liegt darin, sie als konkurrierende Methoden zu behandeln. Sie optimieren unterschiedliche Ziele. Vergleichsartikel wiederum stellen den Bandit oft als kostenloses Upgrade ohne statistischen Tausch dar. Das ist er nicht. Der Preis ist der p-Wert – und dieser Preis sollte bewusst gezahlt werden oder gar nicht.

Die Kosten für den Dauerbetrieb in der beschriebenen Größenordnung: $299/month für Webflow Optimize im Tarif mit 100K Seitenaufrufen; bei wachsendem Traffic steigen auch die Tarifstufen. Zusätzlich ist jede Woche etwa ein halber Arbeitstag einzuplanen, um Zuteilungen zu prüfen, schlechte Varianten zu stoppen und nicht stationäre Verschiebungen zu beobachten. Das ist die reale Kalkulation. Wer diesen Ablauf in einer Agentur oder einer internen Growth-Funktion etablieren und die Conversion-Attribution sauber mit CRM und Data Warehouse verbinden möchte, führt eine andere Diskussion – der Bandit-Einsatz selbst braucht jedoch nur einen Verantwortlichen, einen Nachmittag und ein Script-Tag.

Ein CTA, weil dieser Beitrag lang ist und mit einem eindeutigen nächsten Schritt enden sollte: Die Checkliste für das Audit von KI-Geschäftsprozessen nutze ich, um festzulegen, welche Flächen für einen Bandit infrage kommen und welche einen sauberen A/B-Test benötigen. Sie sollte auf den Funnel angewendet werden, bevor die Tool-Auswahl beginnt. Wer zuerst das Tool auswählt, bezahlt als Growth-Team am Ende für Funktionen, für deren Einsatz der nötige Traffic fehlt.