A/B-Testing auf Shopify: Tests, die eine Entscheidung tragen

Ein A/B-Test beantwortet genau eine Frage: Führt Variante B im Vergleich zu Variante A bei vergleichbarem Publikum zu einem anderen Wert in einer vorher festgelegten Kennzahl. Er vergleicht zwei Zustände unter denselben Bedingungen. Alles, was darüber hinausgeht, ist Interpretation und keine Messung.

Was ein Test nicht liefert, ist eine Begründung. Du erfährst, dass eine Variante besser abschneidet, aber nicht, warum. Die Ursache steckt in Nutzerinterviews, Session-Aufzeichnungen und Support-Tickets. Wer die Begründung aus dem Testergebnis herausliest, baut die nächste Hypothese auf einer Vermutung auf.

Ebenso wenig sagt ein Test etwas über Zeiträume aus, die er nicht abgedeckt hat. Ein Ergebnis aus einer Aktionswoche gilt für Aktionswochen. Ein Ergebnis aus dem Sommer gilt nicht automatisch im Weihnachtsgeschäft. Wer das ignoriert, überträgt Ergebnisse auf Situationen, in denen sie nie geprüft wurden.

Die Stichprobengröße ist der Punkt, an dem Du zu schauen aufhörst. Legst Du sie erst während des Tests fest, wählst Du unbewusst den Zeitpunkt, an dem die Zahlen gerade gut aussehen. Genau dann ist das Ergebnis kein Messwert mehr, sondern eine Auswahl aus vielen möglichen Zwischenständen.

Vier Größen bestimmen die nötige Menge. Die Ausgangs-Conversion-Rate der Kontrollvariante, der kleinste Effekt, der Deine Entscheidung tatsächlich ändern würde, das Signifikanzniveau als Toleranz für falschen Alarm und die Power als Wahrscheinlichkeit, einen echten Effekt auch zu finden. Alle vier sind Entscheidungen, keine Naturkonstanten.

Am wichtigsten und am häufigsten übergangen ist der zweite Punkt. Nicht jeder messbare Unterschied ist ein relevanter Unterschied. Frag Dich vor dem Start: Ab welcher Verbesserung würdest Du die Variante tatsächlich ausrollen und den Aufwand dafür bezahlen. Diese Zahl ist der kleinste sinnvoll erkennbare Effekt.

Die Logik lässt sich an einem reinen Rechenbeispiel zeigen. Die folgenden Werte sind frei gewählte Annahmen und ausdrücklich keine Aussage über Deinen Shop oder Deine Branche. Sie dienen allein dazu, die Größenordnung sichtbar zu machen, in der solche Rechnungen typischerweise landen, und wie schnell sie unbequem wird.

Angenommen, die Ausgangs-Conversion-Rate liegt bei zwei Prozent, Du willst eine relative Verbesserung von zehn Prozent erkennen, arbeitest mit einem Signifikanzniveau von fünf Prozent und einer Power von achtzig Prozent. Dann brauchst Du je Variante eine Besucherzahl in der Größenordnung von mehreren zehntausend, bei diesen Annahmen etwa achtzigtausend.

Die praktische Konsequenz ist unbequem. Je kleiner der Effekt, den Du erkennen willst, desto schneller wächst der Bedarf, und zwar nicht linear. Halbierst Du den gesuchten Effekt, vervierfacht sich die nötige Stichprobe grob. Deshalb scheitern viele Testvorhaben nicht an der Umsetzung, sondern an der Rechnung davor.

Die Laufzeit ergibt sich aus zwei Bedingungen, die beide erfüllt sein müssen. Die geplante Stichprobengröße muss erreicht sein, und der Test muss volle Wochenzyklen abdecken. Ist die Stichprobe schon nach vier Tagen erreicht, läufst Du trotzdem bis zum Ende der Woche weiter.

Der Grund für die vollen Wochen liegt im Kaufverhalten. Wochentage und Wochenenden bringen unterschiedliche Menschen mit unterschiedlicher Kaufabsicht. Ein Test, der Mittwoch startet und Montag endet, gewichtet bestimmte Tage doppelt. Das verzerrt beide Varianten nicht gleichmäßig, wenn sich Traffic-Quellen über die Woche verschieben.

Nach oben gibt es ebenfalls eine Grenze. Läuft ein Test über viele Wochen, sammeln sich Störungen an: Kampagnen starten, Preise ändern sich, Cookies laufen ab und Besucher landen in der anderen Variante. Was als saubere Randomisierung begann, ist dann eine Mischung. Zwei bis vier volle Wochen sind meist der brauchbare Korridor.

Der Effekt heißt Peeking und ist der häufigste Grund für Testergebnisse, die sich später nicht bestätigen. Wer täglich in den Bericht schaut und abbricht, sobald ein Signifikanzwert kurz die Schwelle reißt, prüft nicht einmal, sondern jeden Tag erneut. Die Fehlerwahrscheinlichkeit summiert sich mit jedem Blick.

Anschaulich wird das an der Zwischenstands-Kurve. In den ersten Tagen schwankt der gemessene Unterschied stark, weil wenige Bestellungen viel Gewicht haben. Diese Ausschläge sind Rauschen und keine Signale. Wer sie als Ergebnis liest, rollt Varianten aus, deren Vorsprung sich bei mehr Daten in Luft auflöst.

Es gibt zwei saubere Auswege. Entweder Du legst die Auswertung auf einen einzigen, vorher festgelegten Zeitpunkt und schaust vorher nur auf technische Fehlerindikatoren. Oder Du nutzt ein Verfahren, das mehrfaches Hinsehen einkalkuliert, etwa sequenzielle Tests, deren Schwellen genau dafür konstruiert sind. Mischformen aus beidem sind keine Lösung.

Nicht jede Frage verdient einen Test. Manche Änderungen sind zu klein für den vorhandenen Traffic, andere sind rechtlich oder kaufmännisch keine Option, wieder andere gefährden genau die Messung, mit der Du das Ergebnis feststellen willst. In all diesen Fällen ist die Entscheidung ohne Test die bessere.

Besonders heikel ist alles, was in den Checkout oder in die Preisdarstellung eingreift. Preisdifferenzierung zwischen zufällig zugewiesenen Besuchern ist ein Vertrauensbruch und schafft zusätzlich handfeste Probleme, sobald zwei Personen im selben Haushalt unterschiedliche Preise sehen. Rabatthöhen testest Du über zeitlich getrennte Aktionen, nicht über parallele Gruppen.

Clientseitige Tests verändern die Seite erst, nachdem sie geladen wurde. Sichtbar wird das als kurzes Umspringen von Variante A zu Variante B, oft Flicker genannt. Das verzerrt die Wahrnehmung und die Kennzahlen, weil ein Teil der Besucher die Kontrollvariante sieht und dann etwas anderes.

Die zweite Falle ist die Zuordnung über den Consent hinweg. Besucher, die nicht einwilligen, tauchen im Analytics-Tool nicht oder anders auf als im Testing-Tool. Wenn Zuweisung und Messung unterschiedliche Grundgesamtheiten haben, stimmen die Nenner der beiden Varianten nicht mehr überein, und die Rate ist wertlos.

Dazu kommen Shopify-spezifische Randbedingungen. Der Checkout ist in weiten Teilen kein frei editierbarer Bereich mehr, sondern läuft über definierte Erweiterungspunkte. Caching und mehrere aktive Theme-Varianten können Besuchern zwischen Aufrufen unterschiedliche Fassungen ausliefern. Und ein spürbarer Teil des Traffics ist Bot-Verkehr, der sich in beiden Gruppen ungleich verteilen kann.

Ein Testergebnis besteht nicht aus einer Zahl, sondern aus einem Bereich. Der gemessene Unterschied ist der wahrscheinlichste Wert, das Konfidenzintervall zeigt die Spanne, mit der Du rechnen musst. Reicht dieses Intervall von leicht negativ bis deutlich positiv, hast Du keine Entscheidungsgrundlage, egal wie gut die Punktschätzung aussieht.

Die größte Falle nach dem Test ist die nachträgliche Segmentierung. Wer ein unentschiedenes Gesamtergebnis so lange nach Gerät, Kanal, Land und Neukundenstatus aufteilt, bis irgendwo ein signifikanter Ausschnitt auftaucht, findet immer etwas. Bei genügend Schnitten ist ein Zufallstreffer die Regel und nicht die Ausnahme.

Segmente sind nicht verboten, sie müssen nur vorher benannt sein. Wenn Du vor dem Start festhältst, dass Du Mobile und Desktop getrennt auswertest, ist das eine Hypothese. Fällt Dir die Aufteilung erst beim Betrachten der Ergebnisse ein, ist es eine Suche nach Bestätigung und gehört als solche protokolliert.

Für viele Shops im DACH-Raum ist das der Normalfall, nicht die Ausnahme. Wenn die Rechnung ergibt, dass ein Test Monate laufen müsste, ist das kein Grund für einen schlechteren Test, sondern ein Grund für ein anderes Vorgehen. Ein Test mit zu wenig Daten liefert keine schwächere Antwort, sondern eine unzuverlässige.

Der erste Ausweg ist, größere Änderungen zu testen statt kleiner. Ein neu gedachter Produktseitenaufbau kann einen Effekt haben, der auch mit wenig Traffic sichtbar wird. Eine andere Button-Farbe hat ihn nicht. Wer wenig Daten hat, muss mutiger ändern, sonst misst er dauerhaft Rauschen.

Der zweite Ausweg führt weg vom Test. Viele Verbesserungen brauchen keinen Nachweis per Randomisierung, weil sie offensichtliche Fehler beheben: kaputte Formulare, fehlende Versandinformationen, unbrauchbare Filter, lange Ladezeiten auf Mobilgeräten. Diese Dinge repariert man und misst danach den Verlauf, statt sie gegeneinander antreten zu lassen.