Google Play Store Listing Experiments: A/B-Tests für deine Screenshots (2026)

Bei Google Play musst du nicht raten, ob ein neuer erster Screenshot besser konvertiert als der alte — du kannst es mit echtem Play Store-Traffic testen. Store Listing Experiments sind fest in die Play Console integriert, unter Test and release → Store listing experiments (Google hat den Menüpunkt schon mehrfach verschoben — ältere Anleitungen nennen es „Grow → Store listing experiments“). Sie sind kostenlos, laufen auf deinem Live-Listing, und Google übernimmt die Traffic-Aufteilung und die Statistik für dich.

Wenn du in beiden Stores unterwegs bist, ist das das Gegenstück zu Apples Setup. Die iOS-Seite haben wir hier behandelt: App Store Screenshots A/B-testen mit Product Page Experiments — gleiche Idee, andere Mechanik. Dieser Beitrag ist das Play-seitige Gegenstück.

Wie Store Listing Experiments funktionieren

Du erstellst ein Experiment, wählst das zu testende Asset (App-Icon, Screenshots, Feature Graphic, Vorschauvideo, Kurzbeschreibung oder Langbeschreibung) und lädst bis zu 3 Varianten neben deinem aktuellen Live-Listing hoch — das als Kontrollgruppe dient. Google zeigt die Varianten dann einem Teil der Nutzer, die auf deiner Store-Seite landen, und misst, welche mehr Installationen bringt.

Zwei Kennzahlen zählen im Ergebnis:

• Akquise (Store-Listing-Conversion). Der Anteil der Besucher, die nach dem Sehen einer bestimmten Variante installieren. Das ist die Hauptkennzahl für Screenshot-Tests.
• Gehaltene Erstinstallierende (1-Tage-Retention). Bleiben die Nutzer, die eine Variante angezogen hat, auch einen Tag später noch dabei? Eine Variante, die mehr Installationen, aber schlechtere Retention bringt, hat möglicherweise zu viel versprochen.

Google berechnet pro Variante ein Konfidenzintervall und erklärt eine Variante zum Gewinner, sobald sie deinen gewählten Konfidenz-Schwellenwert überschreitet. Du kannst eine E-Mail-Benachrichtigung aktivieren, damit du das Dashboard nicht ständig im Auge behalten musst. Einen Gewinner zu übernehmen ist ein Klick — trotzdem willst du das gewinnende Asset in der Regel noch durch deinen normalen Release-/Review-Prozess schicken, damit der Rest deines Listings konsistent bleibt.

Standard-Grafiken vs. lokalisierte Experimente

Das ist der Teil, worüber Leute häufig stolpern, und er bestimmt, wie viele Tests du parallel laufen lassen kannst.

• Standard-Grafik-Experiment. Testet die Assets deines Standard-Store-Listings — des Listings, das allen angezeigt wird, die keine lokalisierte Version erhalten. Nutzer, die lokalisierte Assets sehen, sind vom Publikum dieses Experiments ausgeschlossen. Du kannst immer nur ein Standard-Grafik-Experiment gleichzeitig ausführen.
• Lokalisiertes Store-Listing-Experiment. Testet Assets (und/oder Text) für eine bestimmte Sprache. Du kannst bis zu 5 lokalisierte Experimente gleichzeitig ausführen — zum Beispiel eins für Deutsch, eins für Japanisch, eins für brasilianisches Portugiesisch und so weiter, alle parallel.

Praktisch heißt das: Konzentriert sich deine Installationsbasis auf wenige Märkte, kannst du diese Märkte mit lokalisierten Experimenten parallel testen, statt hinter einem einzigen globalen Test anzustehen. Und geh nicht davon aus, dass eine Sprache mit einem Land gleichzusetzen ist — „Englisch (USA)“ auszuwählen beschränkt das Publikum nicht auf die USA; es zielt auf alle, denen dieses lokalisierte Listing angezeigt wird, egal wo sie sind.

Einen Screenshot-A/B-Test einrichten

1. Öffne Store listing experiments und erstelle eins. Wähle das Standard-Listing oder ein bestimmtes lokalisiertes Listing und gib ihm einen Namen, den du auch in drei Wochen noch verstehst („Hero-Screenshot — nutzenorientierter Untertitel v2“).
2. Wähle das Asset. Wähle Screenshots. Teste ein Element pro Experiment — ändere nicht Icon und Screenshots im selben Test, sonst weißt du nicht, was den Ausschlag gegeben hat.
3. Lade bis zu 3 Varianten hoch. Dein Live-Listing ist die Kontrollgruppe. Jede Variante ist ein vollständiges Screenshot-Set in den korrekten Play-Abmessungen — die genauen Maße findest du im Google Play Screenshot-Größen-Leitfaden.
4. Lege Publikum, Konfidenz und MDE fest. Verteile den Traffic auf die Varianten (üblicherweise gleichmäßig — 50/50 bei einer Variante gegen Kontrolle, oder etwa ein Drittel bei drei Varianten). Wähle ein Konfidenzniveau (90 %, 95 %, 98 % oder 99 %) und einen minimalen nachweisbaren Effekt (MDE) — die kleinste Verbesserung, die es wert ist, erkannt zu werden, einstellbar von etwa 0,5 % bis 6 %. Die Play Console zeigt die Abschlussbedingungen an, sodass du vor dem Start siehst, worauf du dich einlässt.
5. Starte den Test und lass ihn laufen. Widerstehe dem Drang, zwischendurch nachzuschauen und früh abzubrechen, sobald eine Variante vorne zu liegen scheint. Lass ihn bis zu den festgelegten Bedingungen laufen.

Stichprobengröße, Dauer und Signifikanz erreichen

Die ehrliche Antwort auf „Wie lange sollte ich den Test laufen lassen?“ lautet: bis er die von dir festgelegten Signifikanzbedingungen erreicht — nicht eine feste Anzahl an Tagen. Aber es gibt praxistaugliche Unter- und Obergrenzen.

• Mindestens 7 Tage laufen lassen. Das Installationsverhalten schwankt zwischen Wochentagen und Wochenende. Alles Kürzere als eine volle Woche baut einen Wochentags-Bias in dein Ergebnis ein. Zwei Wochen (14 Tage) sind ein gängiger, sichererer Standard, und Apps mit wenig Traffic brauchen oft 28 Tage.
• Genug Installationen pro Variante. Signifikanz hängt von deinem Installationsvolumen, der Anzahl der Varianten, deinem Konfidenzniveau und deinem MDE ab. Als grober Richtwert: strebe mindestens etwa 1.000+ Installationen pro Variante an, bevor du dem Ergebnis vertraust — mehr, wenn du ein hohes Konfidenzniveau oder einen kleinen MDE wählst.
• Straffere Einstellungen kosten Traffic. Ein Konfidenzniveau von 99 % oder ein MDE von 0,5 % braucht weit mehr Installierende als 90 % / 3 %. Bei einer App mit wenig Volumen erreicht eine anspruchsvolle Konfiguration möglicherweise nie Signifikanz — lockere den MDE oder akzeptiere 90 %.

Ein Test, der „nicht aussagekräftig“ endet, ist ein echtes Ergebnis, kein Fehlschlag. Meist bedeutet es, dass die Varianten bei deinem Traffic-Volumen zu ähnlich waren, um sie zu unterscheiden, oder dass der Test nicht lange genug lief. Beides lässt sich beheben — mach die Varianten deutlicher unterschiedlich, oder gib ihnen mehr Zeit.

Das Varianten-Limit und was es bedeutet

Drei Varianten gegen die Kontrollgruppe sind die harte Obergrenze pro Experiment. Das ist ein Feature, keine Einschränkung, gegen die man ankämpfen sollte: Jede zusätzliche Variante teilt deinen Traffic dünner auf und verschiebt die Signifikanz weiter nach hinten. Mit drei Herausforderern teilst du deinen Store-Traffic bereits auf vier Wege auf (Kontrolle + 3). Für die meisten Apps kommt man mit einem mutigen, klar unterschiedlichen Herausforderer gegen die Kontrolle schneller zu einem Ergebnis als mit vier diffusen Abwandlungen.

Nutze die Plätze für wirklich unterschiedliche Hypothesen — einen anderen Kernnutzen, einen anderen visuellen Stil, Hochformat vs. ein breites Mehrpanel-Layout — nicht für Nuancen derselben Idee.

Häufige Fehler

• Mehr als eine Variable ändern. Neue Screenshots und eine neue Kurzbeschreibung in einem Test = ein nicht interpretierbares Ergebnis. Isoliere die Variable.
• Bei einem „Gewinner“ früh abbrechen. Frühe Vorsprünge bilden sich zurück. Am dritten Tag abzubrechen, weil eine Variante 8 % vorn liegt, ist der sichere Weg, mit voller Überzeugung ein schlechteres Listing zu veröffentlichen.
• Unter 7 Tagen testen. Du erfasst nur einen Teil des Wochenzyklus und verpasst den Rest.
• Zu strenge Statistik-Vorgaben bei einer App mit wenig Traffic. Wer 99 % / 0,5 % MDE bei bescheidenen Installationszahlen verlangt, garantiert sich einen nicht aussagekräftigen, zeitaufwendigen Test.
• Die 1-Tage-Retention ignorieren. Ein Screenshot, der zu viel verspricht, kann die Installationen steigern und die Retention einbrechen lassen. Behalte beide Zahlen im Blick.
• Die Aufteilung zwischen Standard und lokalisiert vergessen. Ein Standard-Grafik-Experiment erreicht keine Nutzer auf lokalisierten Listings — ist dein Publikum überwiegend lokalisiert, teste dort.
• Immer nur den letzten Screenshot testen. Die ersten 2–3 Screenshots leisten die meiste Überzeugungsarbeit im Play Store. Teste die zuerst. (Mehr dazu, wie sich Play von Apple unterscheidet: Play Store vs. App Store – Screenshot-Unterschiede.)

Wo Mokbi passt

Mokbi führt den A/B-Test nicht selbst durch — das übernimmt die Play Console, und das kostenlos. Was die meisten Teams ausbremst, ist die Produktion der Varianten überhaupt: Ein glaubwürdiger Herausforderer bedeutet ein vollständiges Screenshot-Set in den richtigen Play-Abmessungen, mit tatsächlich geändertem Untertitel und Layout. In Mokbi gestaltest du ein Set im Browser, duplizierst es dann und tauschst den Kernuntertitel, das Layout oder den Hintergrund aus, um Variante B zu bauen — und übersetzt die Untertitel mit einem Klick, wenn du lokalisierte Experimente über mehrere Märkte hinweg laufen lässt. Das Gestalten ist mit einer Vorschau mit Wasserzeichen kostenlos; unbegrenzter Export ohne Wasserzeichen und das Veröffentlichen gibt es mit einem Abo — Solo für €29.99/mo (1 App) oder Studio für €49.99/mo (bis zu 5 Apps), kein Einmalkauf. Es baut die Herausforderer schnell; die Play Console entscheidet, wer gewinnt.

Was du als Nächstes liest

• App Store Screenshots A/B-testen mit Product Page Experiments — das Apple-Pendant
• Play Store vs. App Store – Screenshot-Unterschiede
• Google Play Screenshot-Größen-Leitfaden

Editor öffnen →