Come effettuare A/B test degli screenshot dell'App Store per la conversione

Perché testare proprio gli screenshot?

Gli screenshot sono l'asset con il maggior impatto in una scheda dello store. Gli stessi dati di Apple su Product Page Optimization mostrano che i primi tre screenshot determinano la maggior parte dell'incremento di conversione di una scheda — più dell'icona, del sottotitolo o persino del video di anteprima dell'app. La documentazione Store Listing Experiments di Google riporta lo stesso fenomeno: le vittorie nei test sulla grafica superano in genere quelle nei test sui testi con un margine ampio.

Il motivo per cui i team saltano i test sugli screenshot è l'attrito operativo. Produrre quattro set di sfidanti (controllo + 3 varianti) × tre formati iPhone × due formati iPad × le lingue in cui pubblicate significa decine di file per test. Con un'API di rendering l'attrito si annulla: un template duplicato, un parametro modificato, una chiamata API.

Cosa testare davvero?

Testi una sola variabile per round. Le variabili a maggior leva, in ordine grossomodo decrescente di impatto, sono:

• Il titolo del primo screenshot — visibile senza scorrere nei risultati di ricerca
• Funzione di punta — quale capacità si presenta per prima
• Stile dello sfondo — colore piatto, gradiente o fotografico
• Cornice del dispositivo — con o senza cornice, angolazione del mockup
• Posizione della didascalia — sopra, sotto o in sovrapposizione
• Colore dell'elemento CTA — colore primario del brand vs accento contrastante

Resista alla tentazione di testare cinque elementi contemporaneamente. I test multivariati richiedono volumi di traffico che la maggior parte delle app non ha, e si finisce con un vincitore che non si è in grado di spiegare.

Come generare le varianti in modo programmatico?

Duplichi il template di controllo nell'editor, modifichi un solo elemento, salvi. Quindi renderizzi ogni variante con la stessa forma di chiamata API — cambia solo il templateId:

# 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

Per la maggior parte dei test, renderizzi solo le lingue effettivamente coinvolte. App Store Connect Product Page Optimization opera per singola lingua, quindi un test solo per gli Stati Uniti necessita unicamente degli asset en-US.

Come configurare il test su App Store Connect (PPO)?

Apple Product Page Optimization permette di testare fino a tre pagine sfidanti rispetto alla pagina predefinita in una singola lingua. Apple distribuisce il traffico in modo casuale, riporta impression e tasso di conversione per variante e mostra gli intervalli di confidenza quando il test raggiunge la significatività.

1. In App Store Connect, apra la sua app → Product Page Optimization → Create New Test.
2. Aggiunga fino a tre varianti della pagina prodotto. Ogni variante riceve il proprio set di screenshot, anteprima dell'app e icona.
3. Allochi il traffico. Il valore predefinito del 25% per variante (controllo + tre) funziona per la maggior parte delle app.
4. Selezioni una localizzazione. PPO opera per singola lingua — lo stesso test non può essere applicato a più lingue contemporaneamente.
5. Invii in revisione. Ogni variante viene esaminata da App Review come una normale submission binaria.
6. Avvii il test una volta approvate tutte le varianti.

Consulti la pagina ufficiale Apple Product Page Optimization per limiti e tempistiche di revisione aggiornati.

Come configurare i Google Play Store Listing Experiments?

Il flusso di Google è simile ma più flessibile. Da Play Console, vada in Store Presence → Store Listing Experiments → Create Experiment. Scelga:

• Tipo: Default Listing (globale) o Localized Listing (per singola lingua)
• Asset: screenshot del telefono, tablet da 7 pollici, tablet da 10 pollici, feature graphic, icona
• Varianti: fino a tre sfidanti contro il controllo
• Suddivisione del pubblico: 25%/25%/25%/25% per impostazione predefinita, oppure personalizzata

Play Console gestisce automaticamente gli intervalli di confidenza e segnala il vincitore quando l'incremento è statisticamente significativo. Legga la documentazione Google più recente su Run experiments on your store listing.

Quanto deve essere grande il campione?

Utilizzi un calcolatore standard per z-test su due proporzioni con questi input:

• Tasso di conversione di base: il CTR attuale della sua pagina prodotto (tipicamente 25–35% sull'App Store, 5–10% sul Play Store)
• Incremento minimo rilevabile: un incremento relativo del 5% è una soglia ragionevole; sotto il 3% raramente vale lo sforzo
• Livello di significatività: 95% (α = 0,05)
• Potenza: 80% (β = 0,20)

Per una baseline del 30% e un incremento relativo del 5%, servono all'incirca 100k–150k impression per variante. La maggior parte delle app con meno di 50k impression settimanali dovrebbe eseguire test sequenziali (una variante per due settimane, poi la successiva, confrontandola con una baseline storica stabile) anziché concorrenti.

Per quanto tempo lasciare attivo un test?

Almeno una settimana intera. I pattern di conversione oscillano in modo significativo per giorno della settimana e per fonte di traffico (Search Ads vs organico). Sette giorni catturano un ciclo settimanale completo. Due settimane sono meglio quando il traffico è basso. Interrompa in anticipo solo se (a) la differenza è schiacciante (>30% di incremento) e (b) il test è stato attivo per almeno sette giorni interi. Fermarsi presto sul rumore è il modo più comune per pubblicare una scheda peggiore di quella di partenza.

Come leggere i risultati senza ingannare sé stessi?

Utilizzi l'intervallo di confidenza fornito dalla piattaforma stessa. Sia Apple PPO sia Google Play Experiments riportano intervalli di confidenza al 90% / 95% sull'incremento della variante rispetto al controllo. Se l'intervallo attraversa lo zero, il test è inconcludente — non pubblichi lo sfidante solo perché la stima puntuale è positiva.

Non cerchi di derivare i risultati dai dati di MMP di terze parti. La variante che un utente vede viene decisa lato server da Apple o Google — il suo MMP non può sapere da quale variante è arrivato l'utente. La dashboard dello store stesso è l'unica fonte attendibile.

Cosa fare con il vincitore?

Promuova la variante vincente come predefinita. I template perdenti non vanno eliminati — li tenga come riferimenti e scriva una nota di una riga su cosa è cambiato e cosa ha imparato. Il test successivo si costruisce sul precedente: se un titolo breve ha battuto uno lungo, il prossimo test potrebbe esplorare gli stili dell'icona all'interno di quella cornice di titolo breve.

Affianchi a questa guida la guida all'automazione CI/CD in modo che le varianti vengano generate automaticamente a ogni release, e la guida alla localizzazione così che il vincitore venga tradotto in oltre 30 lingue senza dover ripetere il test in ciascuna di esse.