Så A/B-testar du skärmdumpar för App Store för bättre konvertering

Varför just A/B-testa skärmdumpar?

Skärmdumpar är den tillgång på en butikssida som ger störst hävstång. Apples egen data om Product Page Optimization visar att de tre första skärmdumparna står för det mesta av konverteringslyftet på en sida – mer än ikonen, underrubriken eller ens app-förhandsvisningen. Googles dokumentation om Store Listing Experiments rapporterar samma sak: vinster i grafiktester slår vanligtvis vinster i copytester med god marginal.

Anledningen till att team hoppar över skärmdumpstester är friktionen. Att producera fyra utmanaruppsättningar (kontroll + 3 varianter) × tre iPhone-storlekar × två iPad-storlekar × de språk du levererar betyder dussintals filer per test. Med ett render-API försvinner friktionen – en duplicerad mall, en parameteränring, ett API-anrop.

Vad bör du faktiskt testa?

Testa en variabel per omgång. Variablerna med högst hävstång, ungefär i fallande ordning efter påverkan, är:

• Rubriken på den första skärmdumpen – syns utan att rulla i sökresultaten
• Hjältefunktion – vilken förmåga du leder med
• Bakgrundsstil – platt färg kontra gradient kontra fotografisk
• Enhetsram – med eller utan ram, mockup-vinkel
• Bildtextens placering – ovanför, nedanför eller som överlägg
• Färg på CTA-elementet – primär varumärkesfärg kontra kontrasterande accentfärg

Motstå frestelsen att testa fem saker på en gång. Multivariata tester kräver trafik som de flesta appar inte har, och du står där med en vinnare du inte kan förklara.

Hur genererar du varianter programmatiskt?

Duplicera kontrollmallen i editorn, ändra ett element, spara. Rendera sedan varje variant via samma API-anropsform – endast templateId skiljer sig:

# 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

För de flesta tester räcker det att rendera de språk som testet faktiskt riktar sig mot. App Store Connect Product Page Optimization körs per språk, så ett test som bara gäller USA behöver bara en-US-tillgångar.

Hur sätter du upp testet i App Store Connect (PPO)?

Apples Product Page Optimization låter dig testa upp till tre utmanarsidor mot din standardsida i ett enskilt språk. Apple slumpar trafiken, rapporterar visningar och konverteringsgrad per variant och visar konfidensintervall när testet når signifikans.

1. I App Store Connect, öppna din app → Product Page Optimization → Skapa nytt test.
2. Lägg till upp till tre varianter av produktsidan. Varje variant får sin egen uppsättning skärmdumpar, app-förhandsvisning och ikon.
3. Fördela trafiken. Standardvärdet 25 % per variant (kontroll + tre) fungerar för de flesta appar.
4. Välj en lokalisering. PPO körs per språk – samma test kan inte tillämpas på flera språk samtidigt.
5. Skicka in för granskning. Varje variant granskas av App Review precis som en vanlig binäruppladdning.
6. Starta testet när alla varianter har godkänts.

Se den officiella sidan om Apple Product Page Optimization för aktuella gränser och granskningstider.

Hur sätter du upp Google Play Store Listing Experiments?

Googles flöde är liknande men mer flexibelt. I Play Console, navigera till Store Presence → Store Listing Experiments → Create Experiment. Välj:

• Typ: Default Listing (globalt) eller Localized Listing (per språk)
• Tillgång: Skärmdumpar för telefon, 7-tums surfplatta, 10-tums surfplatta, feature graphic, ikon
• Varianter: upp till tre utmanare mot kontrollen
• Trafikfördelning: 25 %/25 %/25 %/25 % som standard, eller anpassad

Play Console hanterar konfidensintervall automatiskt och flaggar vinnaren när lyftet är statistiskt signifikant. Läs den senaste Google-dokumentationen på Run experiments on your store listing.

Hur stort urval behöver du?

Använd en standard z-test-kalkylator för två proportioner med dessa indata:

• Baslinjekonvertering: din nuvarande CTR för produktsidan (vanligtvis 25–35 % på App Store, 5–10 % på Play Store)
• Minsta detekterbara lyft: 5 % relativt lyft är en rimlig ribba; under 3 % är det sällan värt tiden
• Signifikansnivå: 95 % (α = 0,05)
• Styrka: 80 % (β = 0,20)

Med en baslinje på 30 % och 5 % relativt lyft behöver du ungefär 100 000–150 000 visningar per variant. De flesta appar med under 50 000 veckovisningar bör köra sekventiella tester (en variant i två veckor, sedan nästa, jämfört med en stabil historisk baslinje) i stället för samtidiga.

Hur länge bör du köra ett test?

Minst en hel vecka. Konverteringsmönster varierar betydligt beroende på veckodag och trafikkälla (Search Ads kontra organiskt). Sju dagar fångar en hel veckocykel. Två veckor är bättre när trafiken är låg. Avbryt tidigt endast om (a) skillnaden är överväldigande (>30 % lyft) och (b) testet har körts i minst sju hela dagar. Att stoppa tidigt på brus är det vanligaste sättet att lansera en sämre butikssida än den du började med.

Hur läser du resultat utan att lura dig själv?

Använd plattformens egna konfidensintervall. Både Apple PPO och Google Play Experiments rapporterar 90 % / 95 % konfidensintervall för variantens lyft över kontrollen. Om intervallet korsar noll är testet inte avgörande – lansera inte utmanaren bara för att punktestimatet är positivt.

Försök inte härleda resultat från MMP-data från tredje part. Vilken variant en användare ser avgörs på serversidan av Apple eller Google – din MMP kan inte se vilken variant användaren kom från. Butikens egen instrumentpanel är den enda sanningen.

Vad gör du med vinnaren?

Lansera den vinnande varianten som standard. De förlorande mallarna bör inte raderas – behåll dem som referenser och skriv en enradig anteckning om vad som ändrades och vad du lärde dig. Nästa test bygger vidare på det förra: om en kort rubrik slog en lång kan ditt nästa test utforska ikonstilar inom ramen för den korta rubriken.

Kombinera den här guiden med guiden för CI/CD-automation så att varianter genereras automatiskt vid varje release, och lokaliseringsguiden så att din vinnare översätts till 30+ språk utan att du behöver testa om varje ett.