Conversion-Optimierung mit belastbaren Daten

Drei Faktoren machen klassische Client-Side-Tests untauglich. Erstens: ITP 2.3 in Safari kappt clientseitige Cookies auf 7 Tage Lebensdauer, ein Bucketing-State, der nach einer Woche zerfällt, ruiniert jeden Test. Zweitens: ML-basierte Adblocker filtern 25 bis 40 Prozent aller Exposure-Events, die Power-Analyse arbeitet dann gegen unsichtbares Sampling. Drittens: Client-Side-Varianten erzwingen einen FOUC, bevor das Snippet die Variante setzt, und zerstören CLS und LCP messbar in den Core Web Vitals. Server-Side Assignment am Edge umgeht alle drei: das Bucketing passiert auf dem Server, die Exposure wird im Backend geloggt, der Browser sieht die finale Variante ohne Flicker.

Wir nutzen beide Verfahren, Bayesian wie Frequentist, je nach Fragestellung. Frequentist (Welch-t-Test, Mann-Whitney-U) liefert klassische p-Werte und MDE-Power-Analysen, gut für regulatorisch dokumentierte Tests und harte Go-/No-Go-Entscheidungen vor Launch. Bayesian (über GrowthBook oder Statsig nativ) gibt eine direkte Wahrscheinlichkeitsaussage ("Variant B ist mit 94 % Wahrscheinlichkeit besser") und erlaubt Sequential Testing ohne Alpha-Inflation, sinnvoll, wenn der Business-Case asymmetrisch ist und ein Peek erlaubt sein muss. Wir entscheiden den Ansatz im Hypothesen-Kickoff, nicht später.

Die Assignment-Logik läuft in Next.js Middleware oder einem Cloudflare Worker. Konkret: der Request trifft den Edge-Layer, wir hashen die User-ID (anonym oder Consent-bedingt PII) gegen die Test-Definition, schreiben das Bucket-Cookie und routen zur entsprechenden Variante. Das Exposure-Event geht parallel an PostHog oder GrowthBook und in BigQuery für die Auswertung. Die Variant-Code-Implementierung verbleibt bei Ihrem Dev-Team, wir liefern Edge-Handler, Flag-Service und Exposure-SDK-Wiring. Funktioniert mit Vercel, Cloudflare Pages, Netlify Edge und SST.

Client-Side-Flickering verhindern wir durch Architektur, nicht durch Trickserei. Client-Side-Test-Frameworks wie Google Optimize (eingestellt 2023), VWO Visual Editor oder Optimizely Web injizieren CSS und DOM-Mutationen erst nach dem ersten Paint, das erzeugt Flash of Unstyled Content und einen messbaren CLS-Sprung. Bei Server-Side Assignment am Edge erhält der Browser direkt das HTML der zugewiesenen Variante. Kein Paint-Cycle, kein Mutation Observer, kein Layout-Shift. Vor dem Rollout dokumentieren wir das CLS-Delta zwischen Control und Variante und stoppen den Test, wenn die Variante Performance-Regression zeigt.

Faustregel: mindestens 1.000 Conversions pro Testvariante in 4 Wochen. Darunter dauert der Test länger, als die Hypothese überlebt, oder liefert keine valide Signifikanz. Bei niedrigerem Traffic nutzen wir qualitative Methoden, sogenannte Obvious Wins aus dem Conversion-Audit und Switchback-Designs auf Marketing-Channel-Ebene. Wir empfehlen keine Tests, die strukturell nicht messbar sind, das verbrennt nur Budget.

Eine dokumentierte Sammlung jedes Tests, ob gewonnen oder verloren. Jeder Eintrag enthält: Hypothese, Testdesign, MDE, Laufzeit, Ergebnis mit Konfidenzintervall, abgeleitete Lerneffekte. Verhindert, dass dieselben Tests doppelt laufen, und verkürzt den Weg zur nächsten Hypothese um Wochen. Wir hosten die Library in Notion oder Linear, Sie behalten das Eigentum.

Mindestens 2 Wochen, um Wochentags- und Wochenend-Effekte abzudecken. Typisch 3 bis 6 Wochen bis zur Signifikanz, abhängig von Baseline-Conversion-Rate, MDE und Traffic-Volumen. Wir stoppen keinen Test früh, weil ein Zwischenergebnis gut aussieht. Peeking ohne Alpha-Spending zerstört die statistische Aussage, das ist einer der häufigsten Fehler in CRO-Projekten.

Audit Sprint ab 2.900 € netto, 2 Wochen Lieferung. Enthält Conversion-Daten-Audit, Funnel-Lecks priorisiert, Test-Roadmap. Build Sprint für die Edge-Architektur (Middleware-Handler, Flag-Service, Exposure-Pipeline) zum Festpreis, der nach dem Audit steht. Managed Evolution als monatlicher Retainer, deckt Hypothesen-Backlog, Test-Betrieb und Quartals-Rollup ab.