So führen Sie A/B-Tests für App-Store-Screenshots zur Conversion-Steigerung durch

Warum gerade Screenshots A/B-testen?

Screenshots sind das wirkungsvollste Element eines Store-Eintrags. Apples eigene Daten zur Product Page Optimization zeigen, dass die ersten drei Screenshots den Großteil des Conversion-Anstiegs eines Eintrags ausmachen – mehr als das Icon, der Untertitel oder sogar das App-Vorschauvideo. Googles Dokumentation zu Store Listing Experiments berichtet dasselbe: Gewinner aus Grafiktests schlagen Gewinner aus Texttests in der Regel deutlich.

Der Grund, warum Teams Screenshot-Tests auslassen, ist der Aufwand. Vier Challenger-Sets (Kontrolle + 3 Varianten) × drei iPhone-Größen × zwei iPad-Größen × Ihre ausgelieferten Sprachen zu produzieren bedeutet Dutzende Dateien pro Test. Mit einer Render-API fällt dieser Aufwand zusammen – eine Vorlagenduplizierung, eine Parameteränderung, ein API-Aufruf.

Was sollten Sie tatsächlich testen?

Testen Sie pro Runde nur eine Variable. Die wirkungsvollsten Variablen, grob nach abnehmender Bedeutung sortiert, sind:

• Die Headline des ersten Screenshots – in Suchergebnissen ohne Scrollen sichtbar
• Hero-Feature – mit welcher Funktion Sie in den Vordergrund gehen
• Hintergrundstil – flache Farbe vs. Verlauf vs. fotografisch
• Geräterahmen – mit Rahmen vs. ohne Rahmen, Mockup-Winkel
• Position der Bildunterschrift – darüber, darunter oder als Overlay
• Farbe des CTA-Elements – primäre Markenfarbe vs. kontrastierender Akzent

Widerstehen Sie dem Drang, fünf Dinge gleichzeitig zu testen. Multivariate Tests benötigen Traffic, über den die meisten Apps nicht verfügen, und Sie enden mit einem Sieger, den Sie nicht erklären können.

Wie erzeugen Sie Varianten programmatisch?

Duplizieren Sie die Kontrollvorlage im Editor, ändern Sie ein Element, speichern Sie. Rendern Sie anschließend jede Variante über denselben API-Aufruf – lediglich die templateId unterscheidet sich:

# Render the control + 3 challengers
for VARIANT in control red_cta photo_bg short_headline; do
  curl -X POST https://api.screenshots.live/v1/renders \
    -H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"templateId\": \"tpl_home_v3_${VARIANT}\",
      \"locales\": [\"en-US\"],
      \"devices\": [\"iphone-6.7\", \"iphone-6.1\"],
      \"outputDir\": \"./variants/${VARIANT}\"
    }"
done

Bei den meisten Tests sollten Sie nur die Sprachen rendern, die der Test tatsächlich anspricht. App Store Connect Product Page Optimization läuft pro Sprache, daher benötigt ein US-only-Test nur en-US-Assets.

Wie richten Sie den Test in App Store Connect (PPO) ein?

Mit Apples Product Page Optimization können Sie bis zu drei Challenger-Seiten gegen Ihre Standardseite in einer Sprache testen. Apple verteilt den Traffic zufällig, weist Impressionen und Conversion Rate pro Variante aus und blendet Konfidenzintervalle ein, sobald der Test Signifikanz erreicht.

1. Öffnen Sie in App Store Connect Ihre App → Product Page Optimization → Neuen Test erstellen.
2. Fügen Sie bis zu drei Produktseiten-Varianten hinzu. Jede Variante erhält ein eigenes Screenshot-Set, App-Vorschau und Icon.
3. Verteilen Sie den Traffic. Die Standardverteilung von 25 % pro Variante (Kontrolle + drei) funktioniert für die meisten Apps.
4. Wählen Sie eine Lokalisierung. PPO läuft pro Sprache – derselbe Test kann nicht gleichzeitig auf mehrere Sprachen angewendet werden.
5. Reichen Sie zur Prüfung ein. Jede Variante wird wie eine normale Binary-Einreichung von App Review geprüft.
6. Starten Sie den Test, sobald alle Varianten genehmigt sind.

Die offizielle Apple-Seite zu Product Page Optimization enthält aktuelle Limits und Prüfzeiten.

Wie richten Sie Google Play Store Listing Experiments ein?

Googles Ablauf ist ähnlich, aber flexibler. Navigieren Sie in der Play Console zu Store-Präsenz → Store Listing Experiments → Experiment erstellen. Wählen Sie:

• Typ: Standardeintrag (global) oder Lokalisierter Eintrag (pro Sprache)
• Asset: Telefon-Screenshots, 7-Zoll-Tablet, 10-Zoll-Tablet, Feature-Grafik, Icon
• Varianten: bis zu drei Challenger gegen die Kontrolle
• Zielgruppen-Aufteilung: standardmäßig 25 %/25 %/25 %/25 % oder benutzerdefiniert

Die Play Console berechnet Konfidenzintervalle automatisch und kennzeichnet den Sieger, sobald der Anstieg statistisch signifikant ist. Die aktuellen Google-Dokumente finden Sie unter Experimente für Ihren Store-Eintrag durchführen.

Wie groß muss Ihre Stichprobe sein?

Verwenden Sie einen standardmäßigen Z-Test-Rechner für zwei Anteile mit folgenden Eingaben:

• Basis-Conversion-Rate: Ihre aktuelle CTR der Produktseite (typischerweise 25–35 % im App Store, 5–10 % im Play Store)
• Minimal nachweisbarer Anstieg: 5 % relativer Anstieg ist eine sinnvolle Untergrenze; unter 3 % ist der Aufwand selten gerechtfertigt
• Signifikanzniveau: 95 % (α = 0,05)
• Trennschärfe: 80 % (β = 0,20)

Bei einer Basis von 30 % und einem relativen Anstieg von 5 % benötigen Sie ungefähr 100k–150k Impressionen pro Variante. Die meisten Apps mit weniger als 50k wöchentlichen Impressionen sollten sequenzielle Tests durchführen (eine Variante zwei Wochen lang, dann die nächste, jeweils gegen eine stabile historische Baseline) statt paralleler Tests.

Wie lange sollten Sie einen Test laufen lassen?

Mindestens eine ganze Woche. Conversion-Muster schwanken erheblich nach Wochentag und Trafficquelle (Search Ads vs. organisch). Sieben Tage erfassen einen vollständigen Wochenzyklus. Zwei Wochen sind besser, wenn der Traffic gering ist. Brechen Sie nur dann früher ab, wenn (a) der Unterschied erdrückend ist (>30 % Anstieg) und (b) der Test bereits sieben volle Tage gelaufen ist. Ein zu früher Abbruch aufgrund von Rauschen ist die häufigste Ursache dafür, dass Teams einen schlechteren Eintrag ausliefern als zuvor.

Wie lesen Sie Ergebnisse, ohne sich selbst zu täuschen?

Verwenden Sie das Konfidenzintervall der jeweiligen Plattform. Sowohl Apple PPO als auch Google Play Experiments melden 90- bzw. 95-prozentige Konfidenzintervalle für den Anstieg der Variante gegenüber der Kontrolle. Falls das Intervall die Null überschreitet, ist der Test nicht aussagekräftig – rollen Sie den Challenger nicht aus, nur weil der Punktwert positiv ist.

Versuchen Sie nicht, Ergebnisse aus MMP-Daten von Drittanbietern abzuleiten. Welche Variante ein Nutzer sieht, entscheidet Apple bzw. Google serverseitig – Ihr MMP kann nicht erkennen, aus welcher Variante der Nutzer kam. Das Dashboard des jeweiligen Stores ist die einzige verlässliche Quelle.

Was tun Sie mit dem Sieger?

Befördern Sie die Siegervariante zur Standardvariante. Löschen Sie die unterlegenen Vorlagen nicht – bewahren Sie sie als Referenzpunkte auf und schreiben Sie eine einzeilige Notiz, was geändert wurde und was Sie gelernt haben. Der nächste Test baut auf dem letzten auf: Falls eine kurze Headline eine lange geschlagen hat, könnte Ihr nächster Test Icon-Stile innerhalb dieses Frameworks der kurzen Headline untersuchen.

Kombinieren Sie diesen Leitfaden mit dem CI/CD-Automatisierungs-Leitfaden, damit Varianten automatisch bei jedem Release erzeugt werden, und mit dem Lokalisierungs-Leitfaden, damit Ihr Sieger in mehr als 30 Sprachen übersetzt wird, ohne dass jede einzelne erneut getestet werden muss.