Online-Experimente & Conversion-Optimierung (A/B-Tests, Bandits, kausale Wirkung)

Teams liefern Änderungen an Website und Produkt nach Bauchgefühl aus und können dann nicht sagen, ob sich Conversion, Bindung oder Umsatz wirklich bewegt haben. Experimentierplattformen verteilen Nutzer zufällig auf Varianten, messen den Unterschied statistisch und nutzen zunehmend KI, um Hypothesen vorzuschlagen, Tests zu verkürzen (Varianzreduktion, Bandits), zu erklären, wer profitiert (heterogene Effekte), und Ergebnisse zu verschriftlichen. Bei Änderungen, die sich nicht randomisieren lassen (Preise in einem Land, ein Ausfall, eine TV-Kampagne), schätzen Methoden zur kausalen Wirkung das Kontrafaktische aus Zeitreihen.

Problem & Nutzen

• Heute: Marketing- und Produktteams führen wenige Tests durch, brechen sie früh ab, wenn ein Dashboard gut aussieht („Peeking“), testen viele Kennzahlen ohne Korrektur und schreiben Ergebnisse von Hand auf. Die meisten Ideen sind neutral oder negativ, ein geringer Testdurchsatz bedeutet also überwiegend Raten. Tests auf Websites von KMU mit wenig Verkehr erreichen oft nie Signifikanz.
• KI-Nutzen: (1) mehr und bessere Hypothesen und Variantentexte aus Analyse- und Sitzungsdaten; (2) kürzere Tests durch Varianzreduktion wie CUPED, das das Verhalten vor dem Experiment als Kovariate nutzt [3]; (3) sequenzielle Tests, damit Ergebnisse laufend beobachtet werden können, ohne Fehlalarme aufzublähen [2]; (4) Bandits, die den Verkehr bei kurzlebigen Kampagnen zu besseren Varianten verschieben; (5) automatische Ergebniszusammenfassungen und ein durchsuchbares Archiv bisheriger Erkenntnisse.
• Belege: Große Plattformen berichten, dass nur eine Minderheit der getesteten Ideen die Zielkennzahl verbessert; das ist das Kernargument für ein systematisches Programm, siehe das Praxiswerk von Kohavi, Tang und Xu [1]. Erwarten Sie keine festen Steigerungsprozente: Sie hängen von Verkehr, Ausgangswert und Qualität der Ideen ab.

Varianten

• Marketing / CRO auf Websites und in Shops: Landingpages, Checkout, Preisdarstellung, Texte und Bilder, clientseitig über einen visuellen Editor ausgespielt.
• Produkt- und Funktionsexperimente: serverseitige Feature-Flags mit randomisiertem Rollout, Leitplankenkennzahlen (Latenz, Fehler, Abwanderung) und Kennzahlenberechnung direkt im Warehouse.
• Mobile Apps und Onboarding-Abläufe: Bindung und Aktivierung als Hauptkennzahlen.
• Bandit-Optimierung: Tests von Schlagzeilen/Aktionen für kurze Kampagnen, Ranking von Empfehlungen (vgl. REC-003).
• Quasi-Experimente: Differenz-von-Differenzen, synthetische Kontrolle und Bayessche strukturelle Zeitreihen für Geo-Tests, Preisänderungen und Regeländerungen.
• Öffentlicher Sektor / gemeinnützig: Testen von Briefformulierungen, Formulargestaltung oder Serviceseiten (Nudge-Einheiten), mit ethischer Prüfung.
• Privater Gebrauch: nicht zutreffend.

So funktioniert es

1. hypothesis (analytics, session insights, past tests, LLM suggestions)
2. design (primary + guardrail metrics, MDE, sample size, randomisation unit)
3. variant creation (visual editor / feature flag / LLM-drafted copy)
4. assignment + exposure logging (consent-aware, sticky bucketing)
5. monitoring (sample-ratio-mismatch check, guardrails, sequential tests)
6. analysis (CUPED, multiple-testing control, segment/HTE estimates)
7. decision + write-up (human sign-off)
8. learning archive non-randomisable change
9. causal-impact model on control series
10. effect with interval

• Statistik-Engine: frequentistische sequenzielle Tests (jederzeit gültige p-Werte) oder Bayessche Posterior-Verteilungen; CUPED/CUPAC-Regressionsanpassung; Erkennung von Sample-Ratio-Mismatch (SRM) als Alarm für die Datenqualität [1][2].
• Bandits: Thompson Sampling oder kontextuelle Bandits verteilen den Verkehr adaptiv; sie maximieren den Ertrag während des Tests, liefern aber schwächere Schlussfolgerungen, nutzen Sie sie daher für kurzlebige Entscheidungen und A/B-Tests zum Lernen.
• Heterogene Effekte: Causal Forests, Meta-Learner (T/X/R-Learner) und Uplift-Modelle (EconML, CausalML) schätzen, wer reagiert. Behandeln Sie Befunde zu Untergruppen als Hypothesen, sofern sie nicht vorab festgelegt wurden, und korrigieren Sie für Mehrfachvergleiche.
• Kausale Wirkung: Synthetische Kontrolle und Bayessche strukturelle Zeitreihen (CausalImpact) vergleichen die behandelte Reihe mit vorhergesagten kontrafaktischen Verläufen [5].
• Rolle des LLM: Ideenfindung, Entwurf von Varianten, Experiment-Briefings und Ergebniserzählungen, Abfragen früherer Tests in natürlicher Sprache. Das LLM darf nie über Signifikanz entscheiden: Die Zahlen kommen aus der Statistik-Engine.
• Mensch-in-der-Schleife (Human-in-the-Loop): Die Experimentverantwortlichen genehmigen Design und Entscheidung zur Einführung; Analysten prüfen SRM, Neuheitseffekte und Aussagen zu Segmenten.

Datenaufbereitung

Experimente brauchen drei Datenströme: Expositionsprotokolle (wer welche Variante sah), Ergebnisereignisse (Bestellungen, Anmeldungen) und Kennzahlendefinitionen. Sie liegen typischerweise im Backend des Webshops oder der App, im Web-Analyse-Werkzeug, im ERP- oder Shopsystem (Umsatz, Retouren) und in der Consent-Plattform. Typische Lücken: keine stabile Nutzer-ID, Exposition nicht protokolliert, uneinheitliche Conversion-Definitionen zwischen Marketing und Finanzen, Bots und Testbestellungen in den Daten, Retouren und Stornos nicht mit Bestellungen verknüpft und fehlende Einwilligungskennzeichen.

Schritte der Aufbereitung: 1. Einen gemeinsamen Kennzahlenkatalog mit Haupt- und Leitplankenkennzahlen vereinbaren (PREP-012). 2. Bestellungen und Umsatz aus Shop oder ERP mit den Ereignisdaten verbinden (PREP-005). 3. Exposition mit einer stabilen Randomisierungseinheit protokollieren; die Pipeline mit einem A/A-Test prüfen und das Sample-Ratio-Mismatch kontrollieren. 4. Bot- und interner Verkehr entfernen; Zahlen mit den Finanzen abgleichen. 5. Ein Archiv früherer Tests und Ergebnisse als Grundlage für Hypothesen führen (PREP-016).

Werkzeuge: SQL/dbt, das SDK und die Kennzahlenschicht der Experimentierplattform, ein Warehouse, falls vorhanden. Der Aufwand beträgt etwa 30–40 % des Projekts, überwiegend für Kennzahlendefinitionen und Expositionsprotokollierung. Siehe auch GUIDE-003 und DATA-026.

Umsetzungswege

Welcher Weg für wen

• KMU (A): Kameleoon, AB Tasty, Convert oder die GrowthBook-Cloud sind ausgereifte, in der EU hostbare Produkte mit eingebauter Statistik, und der Ablauf ist Standard.
• Großunternehmen (B): Experimente brauchen eigene Kennzahlen aus dem Warehouse, die Anbindung an Feature-Flags und Produktdaten, und hoher Verkehr macht Lizenz- und Ereignisgebühren groß.
• Entwickler (C): GrowthBook oder PostHog selbst betrieben plus EconML und statsmodels laufen auf HW1 und halten Expositionsdaten im Haus.

Weg A — Kaufen (Standardsoftware) (für die meisten KMU empfohlen)

• Web-/CRO-Suiten: Kameleoon (FR, EU), AB Tasty (FR, EU), Optimizely Web/Feature Experimentation (mit KI-Assistent Opal und Stats Engine), VWO, Convert (Sitz in der EU), Adobe Target.
• Produkt-/Funktionsexperimente: Statsig, Eppo (Datadog), LaunchDarkly Experimentation, GrowthBook (Open Core, EU-Cloud möglich), Amplitude Experiment, PostHog (EU-Cloud), Split (Harness).
• Prüfen: Datenspeicherung in der EU, cookielose oder einwilligungsgesteuerte Funktionsweise, serverseitige SDKs, Kennzahlen direkt im Warehouse (Snowflake, BigQuery, Databricks), CUPED und sequenzielle Tests, SRM-Warnungen.
• A wählen, wenn der Verkehr unter einigen Millionen Besuchern im Monat liegt und dem Team Data-Science-Kapazität fehlt.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Feature-Flags aus einem verwalteten Dienst oder über OpenFeature-SDKs; Kennzahlen in Ihrem Warehouse mit SQL/dbt berechnet; Analysedienst in Python (statsmodels, scipy, pymc) auf einer Cloud-Funktion.
• LLM-APIs (Claude, Gemini, GPT, Mistral, EU-Regionen) für den Hypothesen-Backlog, Variantentexte und Ergebniserzählungen, gespeist nur mit aggregierten Ergebnissen statt mit rohen Nutzerzeilen.
• B wählen, wenn Sie bereits ein Warehouse haben und eigene Kennzahlen oder eine Anbindung brauchen.

Weg C — Selbst betreiben (Open Source)

• Plattformen: GrowthBook (MIT-Kern, selbst betreibbar, direkt im Warehouse) [4], PostHog (selbst betrieben), Unleash/Flagsmith für Flags mit OpenFeature.
• Bibliotheken: EconML, CausalML, DoWhy, pymc/pymc-marketing, CausalImpact (R) und tfcausalimpact/pycausalimpact [5], statsmodels, Ax/BoTorch für adaptive und Bayessche Optimierung.
• LLM: ein lokales Open-Weight-Modell mit 7–30 Mrd. Parametern (Klasse Qwen, Mistral, Llama) über vLLM oder Ollama zum Entwerfen; die Statistik braucht nur CPU. Hardware: HW1 für den Statistik-Stack, HW2, wenn ein LLM hinzukommt.

Weg D — Eigenes Training

Lohnt sich nur bei hohem Verkehr: hauseigene kontextuelle Bandits, Uplift-Modelle oder rankingbewusste Experimentdesigns (Interleaving, Switchback-Tests, Korrekturen für Netzwerkeffekte) auf Millionen von Expositionen. Setzt zuerst eine verlässliche Expositionsprotokollierung und eine stabile Kennzahlenschicht voraus.

Stand der Technik (2026)

• Sequenzielle und jederzeit gültige Inferenz ist in den großen Engines Standard und ermöglicht laufende Beobachtung [2]; Bayessche und frequentistische Optionen sind beide verbreitet.
• Varianzreduktion (CUPED und ML-basierte Erweiterungen) ist in den meisten Plattformen für Produktexperimente eingebaut und verkürzt die Laufzeit oft spürbar, wenn Daten aus der Vorperiode mit der Kennzahl korrelieren [3].
• Experimente direkt im Warehouse (Eppo, Statsig, GrowthBook) halten Kennzahlen im Data Warehouse und verringern Datenkopien.
• KI-Assistenten (z. B. Optimizely Opal, Copiloten der Plattformen) erzeugen Ideen, Varianten, Testpläne und Zusammenfassungen; die Qualität hängt von den zugrunde liegenden Daten ab, und sie ersetzen keine statistische Prüfung.
• Grenzen und Fehlerarten: Peeking ohne sequenzielle Methoden, SRM durch Bot-Verkehr oder Weiterleitungen, Neuheits- und Primacy-Effekte, Interferenz zwischen Nutzern (Marktplätze, soziale Funktionen), Websites mit wenig Verkehr, viele Kennzahlen ohne Korrektur, Überinterpretation von Segmenteffekten, Bandit-Verzerrung in späteren Analysen, von LLMs erzeugte Varianten, die mit Marke oder Recht kollidieren, und Langzeiteffekte, die kurze Tests übersehen. Auch die Ablehnung von Cookies verzerrt Stichproben zugunsten der Einwilligenden.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack: Bibliotheken für kausale Inferenz, Tabellen-ML und Zeitreihen sowie eine Kennzahlenschicht im Warehouse teilen sich DATA-024 (Szenariomodellierung) und REC-005 (Marketing-Mix-Modellierung und Attribution, die Inkrementalitätstests ergänzt).
• Vorgelagert: DATA-026 (Erkenntnisse aus Session-Replay und UX-Reibung liefern Hypothesen), DATA-001 (dialogbasierte BI zur Erkundung von Kennzahlen).
• Nachgelagert/angrenzend: REC-003 und REC-006 (durch Experimente validierte Personalisierungsregeln), REC-007 (Tests von Werbemitteln), DATA-008 (Überwachung der Datenqualität von Ereignisströmen).
• Ein Open-Source-LLM-Server kann mit anderen Textanwendungsfällen auf HW2 geteilt werden.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen bis zum ersten Test; die Preise richten sich typischerweise nach monatlich erfassten Nutzern oder Ereignissen, bei mehreren Werkzeugen mit kostenlosen Stufen.
• Weg B: 1–3 Monate einschließlich Ereignis-Pipeline, Kennzahlendefinitionen und Dashboards.
• Weg C: 2–4 Monate und Teilzeitaufwand in der Dateningenieurarbeit; geringe Rechenkosten.
• Weg D: Quartale; durch hohen Verkehr gerechtfertigt.
• Kennzahlen: Experimente je Quartal, Anteil der Tests mit Entscheidung, Gewinnquote und kumulierte validierte Steigerung bei den Hauptkennzahlen, Zeit bis zur Entscheidung, SRM-Häufigkeit, abgefangene Verletzungen von Leitplanken, Anteil der eingeführten Änderungen, die getestet wurden, Übereinstimmung wiederholter Holdouts.
• Kostentreiber: verkehrsabhängige Preise, Entwicklungsaufwand für serverseitige Flags, Analystenzeit, Verlust durch Einwilligungsquote.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsführung und die Marketing- oder Produktleitung ein, um Ziele, Risikobereitschaft bei Tests und die Freigabeberechtigung zu klären. IT oder Entwickler binden SDK und Feature-Flags ein; Datenverantwortliche (Shop, ERP, Finanzen) müssen die Kennzahlendefinitionen bestätigen. Die oder der Datenschutzbeauftragte prüft Einwilligung, cookielosen Betrieb und den AVV mit dem Plattformanbieter (GUIDE-005). Betriebsrat: in der Regel nein, weil die Tests kundenseitige Änderungen randomisieren und keine Beschäftigten bewerten; er wird relevant (§ 87 Abs. 1 Nr. 6 BetrVG), wenn Experimente auf internen Werkzeugen laufen oder Ergebnisse genutzt werden, um die Leistung einzelner Beschäftigter zu messen, und § 90 Abs. 1 Nr. 3 verlangt Unterrichtung, wenn sich Arbeitsabläufe ändern. Halten Sie diese Grenze in einer kurzen Richtlinie ausdrücklich fest (GUIDE-004).

KI-Kompetenz: Unterstützen Sie das Team mit Schulungen zu statistischen Grundlagen (Peeking, Mehrfachtests, Neuheitseffekte) und zu der Tatsache, dass LLMs Hypothesen und Texte entwerfen, aber nie über Signifikanz entscheiden (GUIDE-006). Kommunizieren Sie, dass Tests Routine sind und kein Urteil über die Ideen von Menschen. Starten Sie ein Pilotprojekt mit einer Seite oder einem Trichter und einem kleinen Team von zwei bis vier Personen, einer vorab festgelegten Hypothese und einer Go/No-go-Regel (GUIDE-009). Typische Sorge: „Tests setzen sich über unsere Erfahrung hinweg.“ Begegnen Sie ihr, indem Sie Expertenideen als Hypothesen behandeln und eine benannte Experimentverantwortliche oder einen benannten Experimentverantwortlichen über die Einführung entscheiden lassen.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; die KI-Kompetenz (Art. 4) gilt. Keine Verwendung nach Anhang III, es sei denn, Experimente entscheiden über den Zugang zu wesentlichen Diensten, Beschäftigung oder Kredit oder setzen manipulative Techniken ein. Art. 5 Abs. 1 Buchst. a verbietet KI, die unterschwellige oder gezielt manipulative Techniken mit erheblichem Schaden einsetzt, und Buchst. b das Ausnutzen von Schwächen; vermeiden Sie Dark Patterns und Optimierung, die auf schutzbedürftige Nutzer zielt [6].
• DSGVO / ePrivacy: Zuweisungs-IDs, Cookies und Verhaltensereignisse sind personenbezogene Daten. Clientseitiges Testen braucht nach den ePrivacy-Regeln in der Regel eine Einwilligung (Art. 5 Abs. 3 ePrivacy-Richtlinie); dokumentieren Sie die Rechtsgrundlage, minimieren Sie Kennungen, bevorzugen Sie Hosting in eigener Hand, Datenspeicherung in der EU und Auftragsverarbeitungsverträge (Art. 28), legen Sie die Aufbewahrung fest und verzichten Sie auf seitenübergreifendes Tracking [7].
• Verbraucherrecht: Preisexperimente und personalisierte Preise müssen die Transparenzpflichten beachten (Pflicht zur Offenlegung der Preispersonalisierung nach der Verbraucherrechte-Richtlinie) und das DSA-Verbot von Dark Patterns auf Plattformen; beim Testen von Preisen an Gruppen sind diskriminierende Ergebnisse zu vermeiden.
• Forschungsethik: Experimente an sensiblen Diensten oder Gesundheits-Apps brauchen eine ethische Prüfung; informieren Sie Nutzende in den Nutzungsbedingungen.
• Gegenmaßnahmen: vorab festgelegte Hauptkennzahl, Leitplankenkennzahlen, Kontrolle für Mehrfachtests, Holdout-Gruppen, Protokoll der Entscheidungen, menschliche Freigabe.

Erste Schritte

1. Bringen Sie zuerst das Ereignis-Tracking in Ordnung: Prüfen Sie die Expositionsprotokollierung und führen Sie einen A/A-Test durch, um SRM und Kennzahlenrauschen zu kontrollieren.
2. Wählen Sie je Test eine Hauptkennzahl und zwei Leitplanken; berechnen Sie vor dem Start den minimal nachweisbaren Effekt und die Laufzeit.
3. Wählen Sie ein Werkzeug (Weg A oder GrowthBook) mit EU-Hosting und einer mit Ihrem Datenschutzbeauftragten abgestimmten Einwilligungsstrategie.
4. Führen Sie einen Hypothesen-Backlog; lassen Sie ein LLM Ideen und Varianten entwerfen, priorisieren Sie aber nach Beleglage und erwarteter Wirkung.
5. Prüfen Sie jeden Test anhand einer Vorlage (Ergebnis, Intervalle, Segmente, Erkenntnisse) und legen Sie ihn in einem durchsuchbaren Archiv ab.

Quellen

1. Kohavi, Tang, Xu — Trustworthy Online Controlled Experiments (Cambridge University Press) — https://experimentguide.com/
2. Johari, Koomen, Pekelis, Walsh — Always valid inference: continuous monitoring of A/B tests — https://arxiv.org/abs/1512.04922
3. Deng, Xu, Kohavi, Walker — Improving the sensitivity of online controlled experiments using pre-experiment data (CUPED, WSDM 2013) — https://dl.acm.org/doi/10.1145/2433396.2433413
4. GrowthBook — open-source experimentation platform — https://github.com/growthbook/growthbook
5. Brodersen et al. — Inferring causal impact using Bayesian structural time-series models (Annals of Applied Statistics 2015) — https://research.google/pubs/inferring-causal-impact-using-bayesian-structural-time-series-models/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. EDPB — Guidelines 2/2023 on technical scope of Art. 5(3) of the ePrivacy Directive — https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2023/guidelines-22023-technical-scope-art-53-eprivacy_en
8. Microsoft — EconML — https://github.com/py-why/EconML