Hoe je App Store-screenshots A/B-test voor conversie

Waarom specifiek screenshots A/B-testen?

Screenshots zijn het asset met de grootste hefboomwerking op een storepagina. Apple's eigen data over Product Page Optimization toont aan dat de eerste drie screenshots het grootste deel van de conversiestijging op een listing aandrijven — meer dan het icoon, de subtitel of zelfs de app preview-video. Google's documentatie over Store Listing Experiments meldt hetzelfde: winst uit grafische tests overtreft doorgaans winst uit tekstuele tests met een ruime marge.

De reden dat teams screenshot-tests overslaan, is wrijving. Vier challenger-sets produceren (control + 3 varianten) × drie iPhone-formaten × twee iPad-formaten × de locales die je verscheept, betekent tientallen bestanden per test. Met een render-API stort die wrijving in — één template-duplicaat, één parameterwijziging, één API-call.

Wat moet je eigenlijk testen?

Test één variabele per ronde. De variabelen met de grootste hefboomwerking, in ongeveer aflopende volgorde van impact, zijn:

• De kop van de eerste screenshot — zichtbaar zonder te scrollen in de zoekresultaten
• Hero-functie — met welke mogelijkheid je opent
• Achtergrondstijl — egale kleur versus gradient versus fotografisch
• Apparaatframe — met of zonder frame, mockup-hoek
• Positie van het bijschrift — boven, onder of als overlay
• Kleur van het CTA-element — primaire merkkleur versus contrasterend accent

Weersta de drang om vijf dingen tegelijk te testen. Multivariate tests vereisen verkeer dat de meeste apps niet hebben, en je eindigt met een winnaar die je niet kunt verklaren.

Hoe genereer je varianten programmatisch?

Dupliceer de control-template in de editor, wijzig één element en sla op. Render daarna elke variant via dezelfde vorm van API-call — alleen de templateId verschilt:

# 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

Render voor de meeste tests alleen de locales die de test daadwerkelijk target. App Store Connect Product Page Optimization draait per locale, dus een test voor alleen de VS heeft alleen en-US-assets nodig.

Hoe stel je de test in op App Store Connect (PPO)?

Met Apple's Product Page Optimization kun je in één locale tot drie challenger-pagina's tegen je standaardpagina testen. Apple verdeelt het verkeer willekeurig, rapporteert vertoningen en conversieratio per variant en toont betrouwbaarheidsintervallen wanneer de test significantie bereikt.

1. Open in App Store Connect je app → Product Page Optimization → Create New Test.
2. Voeg tot drie productpagina-varianten toe. Elke variant krijgt een eigen screenshot-set, app preview en icoon.
3. Verdeel het verkeer. De standaard 25% per variant (control + drie) werkt voor de meeste apps.
4. Kies een lokalisatie. PPO draait per locale — dezelfde test kan niet gelijktijdig op meerdere locales worden toegepast.
5. Dien in voor review. Elke variant wordt door App Review beoordeeld zoals een gewone binary-submission.
6. Start de test zodra alle varianten zijn goedgekeurd.

Zie de officiële Apple Product Page Optimization-pagina voor actuele limieten en review-tijden.

Hoe stel je Google Play Store Listing Experiments in?

Google's flow lijkt erop maar is flexibeler. Navigeer in de Play Console naar Store Presence → Store Listing Experiments → Create Experiment. Kies:

• Type: Default Listing (globaal) of Localized Listing (per locale)
• Asset: telefoon-screenshots, 7-inch tablet, 10-inch tablet, feature graphic, icoon
• Varianten: tot drie challengers tegenover control
• Verdeling van publiek: standaard 25%/25%/25%/25%, of aangepast

De Play Console verwerkt betrouwbaarheidsintervallen automatisch en markeert de winnaar wanneer de uplift statistisch significant is. Lees de meest recente Google-documentatie op Run experiments on your store listing.

Hoe groot moet je steekproef zijn?

Gebruik een standaard z-test calculator voor twee proporties met deze invoer:

• Basis-conversieratio: je huidige CTR op de productpagina (doorgaans 25–35% in de App Store, 5–10% in de Play Store)
• Minimaal detecteerbare lift: 5% relatieve lift is een redelijke ondergrens; onder de 3% is het zelden de moeite waard
• Significantieniveau: 95% (α = 0,05)
• Power: 80% (β = 0,20)

Voor een baseline van 30% en 5% relatieve lift heb je ruwweg 100k–150k vertoningen per variant nodig. De meeste apps met minder dan 50k wekelijkse vertoningen kunnen beter sequentiële tests draaien (één variant gedurende twee weken, daarna de volgende, vergeleken met een stabiele historische baseline) in plaats van gelijktijdige.

Hoe lang moet je een test laten draaien?

Minstens een volledige week. Conversiepatronen schommelen aanzienlijk per dag-van-de-week en per verkeersbron (Search Ads versus organisch). Zeven dagen vangt één volledige weekcyclus op. Twee weken is beter wanneer het verkeer laag is. Stop alleen vroegtijdig als (a) het verschil overweldigend is (>30% lift) en (b) de test al minstens zeven volle dagen draait. Vroegtijdig stoppen op ruis is de meest voorkomende manier om een slechtere listing live te zetten dan waarmee je begon.

Hoe lees je resultaten uit zonder jezelf voor de gek te houden?

Gebruik het betrouwbaarheidsinterval van het platform zelf. Zowel Apple PPO als Google Play Experiments rapporteren 90% / 95% betrouwbaarheidsintervallen op de lift van de variant ten opzichte van control. Als het interval nul kruist, is de test niet doorslaggevend — zet de challenger niet live alleen omdat de puntschatting positief is.

Probeer geen resultaten af te leiden uit data van een derde partij MMP. Welke variant een gebruiker te zien krijgt, wordt server-side bepaald door Apple of Google — je MMP kan niet zien uit welke variant de gebruiker afkomstig is. Het dashboard van de store zelf is de enige bron van waarheid.

Wat doe je met de winnaar?

Promoveer de winnende variant tot standaard. De verliezende templates moeten niet worden verwijderd — bewaar ze als referentiepunten en schrijf in één regel op wat er is veranderd en wat je hebt geleerd. De volgende test bouwt voort op de vorige: als een korte kop een lange versloeg, kan je volgende test bijvoorbeeld iconenstijlen verkennen binnen het kader van die korte kop.

Combineer deze gids met de CI/CD-automatiseringsgids zodat varianten bij elke release automatisch worden gegenereerd, en de lokalisatiegids zodat je winnaar wordt vertaald naar 30+ talen zonder dat je elke taal opnieuw hoeft te testen.