Slik A/B-tester du App Store-skjermbilder for konvertering

Hvorfor A/B-teste nettopp skjermbilder?

Skjermbilder er det mest innflytelsesrike elementet på en butikkside. Apples egne data om Product Page Optimization viser at de tre første skjermbildene står for det meste av konverteringsløftet på en oppføring – mer enn ikonet, undertittelen eller til og med forhåndsvisningsvideoen for appen. Googles dokumentasjon for Store Listing Experiments rapporterer det samme: gevinster fra grafikktester slår vanligvis gevinster fra teksttester med god margin.

Grunnen til at team hopper over skjermbildetester er friksjon. Å produsere fire utfordrersett (kontroll + 3 varianter) × tre iPhone-størrelser × to iPad-størrelser × språkene du leverer til betyr titalls filer per test. Med et render-API kollapser friksjonen – ett maldublikat, én parameterendring, ett API-kall.

Hva bør du faktisk teste?

Test én variabel per runde. De mest innflytelsesrike variablene, i omtrent synkende rekkefølge etter effekt, er:

• Overskriften på det første skjermbildet – synlig uten rulling i søkeresultater
• Hovedfunksjon – hvilken egenskap du leder med
• Bakgrunnsstil – flat farge vs. gradient vs. fotografisk
• Enhetsramme – med eller uten ramme, mockup-vinkel
• Plassering av bildetekst – over, under eller som overlegg
• Farge på CTA-elementet – primær merkefarge vs. kontrasterende aksent

Stå imot fristelsen til å teste fem ting samtidig. Multivariate tester krever trafikk som de fleste apper ikke har, og du ender opp med en vinner du ikke kan forklare.

Hvordan genererer du varianter programmatisk?

Dupliser kontrollmalen i editoren, endre ett element, lagre. Render deretter hver variant via samme API-kallform – kun templateId er forskjellig:

# 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

For de fleste tester bør du bare rendre språkene testen faktisk retter seg mot. App Store Connect Product Page Optimization kjører per språk, så en test som kun gjelder USA trenger bare en-US-ressurser.

Hvordan setter du opp testen på App Store Connect (PPO)?

Apples Product Page Optimization lar deg teste opptil tre utfordrersider mot standardsiden din i ett språk. Apple randomiserer trafikken, rapporterer visninger og konverteringsrate per variant, og viser konfidensintervaller når testen når signifikans.

1. I App Store Connect, åpne appen din → Product Page Optimization → Create New Test.
2. Legg til opptil tre produktsidevarianter. Hver variant får sitt eget skjermbildesett, sin egen forhåndsvisning og sitt eget ikon.
3. Fordel trafikken. Standard 25 % per variant (kontroll + tre) fungerer for de fleste apper.
4. Velg en lokalisering. PPO kjører per språk – samme test kan ikke brukes på flere språk samtidig.
5. Send inn for vurdering. Hver variant gjennomgås av App Review som en vanlig binærinnsending.
6. Start testen når alle varianter er godkjent.

Se den offisielle Apple Product Page Optimization-siden for gjeldende grenser og vurderingstid.

Hvordan setter du opp Google Play Store Listing Experiments?

Googles flyt er lik, men mer fleksibel. Fra Play Console, naviger til Store Presence → Store Listing Experiments → Create Experiment. Velg:

• Type: Default Listing (global) eller Localized Listing (per språk)
• Ressurs: Telefonskjermbilder, 7-tommers nettbrett, 10-tommers nettbrett, feature graphic, ikon
• Varianter: opptil tre utfordrere mot kontroll
• Publikumsfordeling: 25 %/25 %/25 %/25 % som standard, eller tilpasset

Play Console håndterer konfidensintervaller automatisk og flagger vinneren når løftet er statistisk signifikant. Les den nyeste Google-dokumentasjonen på Run experiments on your store listing.

Hvor stort utvalg trenger du?

Bruk en standard z-test-kalkulator for to proporsjoner med disse inndataene:

• Grunnleggende konverteringsrate: produktsidens nåværende CTR (typisk 25–35 % på App Store, 5–10 % på Play Store)
• Minste detekterbare løft: 5 % relativt løft er en rimelig terskel; under 3 % er sjelden verdt tiden
• Signifikansnivå: 95 % (α = 0,05)
• Styrke: 80 % (β = 0,20)

For en grunnverdi på 30 % og 5 % relativt løft trenger du omtrent 100k–150k visninger per variant. De fleste apper med under 50k ukentlige visninger bør kjøre sekvensielle tester (én variant i to uker, deretter den neste, sammenlignet mot en stabil historisk grunnverdi) i stedet for samtidige.

Hvor lenge bør du kjøre en test?

Minst én hel uke. Konverteringsmønstre svinger betydelig etter ukedag og trafikkilde (Search Ads vs. organisk). Sju dager fanger én hel ukentlig syklus. To uker er bedre når trafikken er lav. Stopp tidlig kun hvis (a) forskjellen er overveldende (>30 % løft) og (b) testen har kjørt i minst sju hele dager. Å stoppe tidlig på støy er den vanligste måten å sende ut en dårligere oppføring enn den du startet med.

Hvordan leser du resultater uten å lure deg selv?

Bruk plattformens eget konfidensintervall. Både Apple PPO og Google Play Experiments rapporterer 90 % / 95 %-konfidensintervaller på variantens løft over kontroll. Hvis intervallet krysser null, er testen ikke konklusiv – ikke send ut utfordreren bare fordi punktestimatet er positivt.

Ikke prøv å utlede resultater fra tredjeparts MMP-data. Hvilken variant en bruker ser bestemmes server-side av Apple eller Google – MMP-en din kan ikke se hvilken variant brukeren kom fra. Butikkens eget dashbord er den eneste sannheten.

Hva gjør du med vinneren?

Forfremm den vinnende varianten til standard. De tapende malene bør ikke slettes – behold dem som referansepunkter og skriv en kort notis om hva som endret seg og hva du lærte. Den neste testen bygger videre på den forrige: hvis en kort overskrift slo en lang, kan neste test utforske ikonstiler innenfor det rammeverket med korte overskrifter.

Kombiner denne guiden med CI/CD-automatiseringsguiden slik at varianter genereres automatisk ved hver utgivelse, og lokaliseringsguiden slik at vinneren din blir oversatt til 30+ språk uten å testes på nytt for hvert enkelt.