Pourquoi tester A/B spécifiquement les captures d'écran ?

Les captures d'écran sont l'actif à plus fort effet de levier sur une fiche store. Les propres données d'Apple sur Product Page Optimization montrent que les trois premières captures d'écran génèrent la majeure partie du gain de conversion sur une fiche — plus que l'icône, le sous-titre ou même la vidéo de prévisualisation. La documentation Store Listing Experiments de Google rapporte la même chose : les gains des tests graphiques battent généralement les gains des tests de copy par une large marge.

La raison pour laquelle les équipes sautent les tests de captures d'écran est la friction. Produire quatre ensembles de challengers (contrôle + 3 variantes) × trois tailles iPhone × deux tailles iPad × les langues que vous livrez signifie des dizaines de fichiers par test. Avec une API de rendu, la friction s'effondre — un duplicata de modèle, un changement de paramètre, un appel API.

Que devriez-vous réellement tester ?

Testez une variable par tour. Les variables à fort effet de levier, dans un ordre approximativement décroissant d'impact, sont :

Le titre de la première capture d'écran — visible sans défilement dans les résultats de recherche
Fonctionnalité héros — quelle capacité vous mettez en avant
Style d'arrière-plan — couleur plate vs dégradé vs photographique
Cadre d'appareil — encadré vs sans cadre, angle du mockup
Position de la légende — au-dessus, en dessous ou en superposition
Couleur de l'élément CTA — couleur de marque principale vs accent contrastant

Résistez à l'envie de tester cinq choses à la fois. Les tests multivariés ont besoin d'un trafic que la plupart des applications n'ont pas, et vous vous retrouvez avec un gagnant que vous ne pouvez pas expliquer.

Comment générer les variantes par programme ?

Dupliquez le modèle de contrôle dans l'éditeur, changez un élément, sauvegardez. Puis rendez chaque variante via la même forme d'appel API — seul le templateId diffère :

generate-variants.sh

bash

# 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

Pour la plupart des tests, ne rendez que les langues que le test cible réellement. Apple Product Page Optimization s'exécute par langue, donc un test US-only n'a besoin que d'actifs en-US.

Comment configurer le test sur App Store Connect (PPO) ?

Apple Product Page Optimization vous laisse tester jusqu'à trois pages challenger contre votre page par défaut dans une seule langue. Apple randomise le trafic, rapporte les impressions et le taux de conversion par variante, et fait apparaître les intervalles de confiance lorsque le test atteint la signification.

Dans App Store Connect, ouvrez votre application → Product Page Optimization → Créer un nouveau test.
Ajoutez jusqu'à trois variantes de page produit. Chaque variante reçoit son propre ensemble de captures d'écran, sa prévisualisation d'application et son icône.
Allouez le trafic. Le 25 % par défaut par variante (contrôle + trois) fonctionne pour la plupart des applications.
Choisissez une localisation. PPO s'exécute par langue — le même test ne peut pas être appliqué à plusieurs langues simultanément.
Soumettez pour examen. Chaque variante est examinée par App Review comme une soumission de binaire normale.
Démarrez le test une fois toutes les variantes approuvées.

Voir la page Apple Product Page Optimization officielle pour les limites et la chronologie de revue actuelles.

Comment configurer Google Play Store Listing Experiments ?

Le flux de Google est similaire mais plus flexible. Depuis la Play Console, naviguez vers Présence sur le store → Store Listing Experiments → Créer une expérience. Choisissez :

Type : Fiche par défaut (globale) ou Fiche localisée (par langue)
Actif : Captures d'écran de téléphone, tablette 7 pouces, tablette 10 pouces, feature graphic, icône
Variantes : jusqu'à trois challengers vs contrôle
Répartition d'audience : 25 %/25 %/25 %/25 % par défaut, ou personnalisée

La Play Console gère les intervalles de confiance automatiquement et signale le gagnant quand le gain est statistiquement significatif. Lisez la dernière documentation Google sur Mener des expériences sur votre fiche store.

Quelle taille d'échantillon vous faut-il ?

Utilisez un calculateur de test z à deux proportions standard avec ces entrées :

Taux de conversion de référence : votre CTR actuel de la page produit (généralement 25-35 % sur l'App Store, 5-10 % sur le Play Store)
Gain minimum détectable : un gain relatif de 5 % est une barre raisonnable ; en dessous de 3 % vaut rarement le temps
Niveau de signification : 95 % (α = 0,05)
Puissance : 80 % (β = 0,20)

Pour une référence de 30 % et un gain relatif de 5 %, vous avez besoin d'environ 100 000 à 150 000 impressions par variante. La plupart des applications avec moins de 50 000 impressions hebdomadaires devraient mener des tests séquentiels (une variante pendant deux semaines, puis la suivante, en comparant à une référence historique stable) plutôt que simultanés.

Combien de temps devriez-vous faire tourner un test ?

Au moins une semaine complète. Les patterns de conversion oscillent significativement selon le jour de la semaine et la source de trafic (Search Ads vs organique). Sept jours capture un cycle hebdomadaire complet. Deux semaines, c'est mieux quand le trafic est faible. N'arrêtez tôt que si (a) la différence est écrasante (>30 % de gain) et (b) le test a tourné au moins sept jours complets. Arrêter tôt sur du bruit est la manière la plus courante de livrer une fiche pire que celle avec laquelle vous avez commencé.

Comment lire les résultats sans vous tromper vous-même ?

Utilisez l'intervalle de confiance propre à la plateforme. Apple PPO et Google Play Experiments rapportent tous deux des intervalles de confiance à 90 % / 95 % sur le gain de la variante par rapport au contrôle. Si l'intervalle traverse zéro, le test est non concluant — ne livrez pas le challenger juste parce que l'estimation ponctuelle est positive.

N'essayez pas de dériver les résultats de données MMP tierces. La variante qu'un utilisateur voit est décidée côté serveur par Apple ou Google — votre MMP ne peut pas voir de quelle variante l'utilisateur est venu. Le tableau de bord propre du store est la seule vérité de terrain.

Que faites-vous avec le gagnant ?

Promouvez la variante gagnante en par défaut. Les modèles perdants ne devraient pas être supprimés — gardez-les comme points de référence et écrivez une note d'une ligne sur ce qui a changé et ce que vous avez appris. Le prochain test se compose sur le précédent : si un titre court a battu un long, votre prochain test pourrait explorer les styles d'icône dans ce cadre de titre court.

Associez ce guide avec le guide d'automatisation CI/CD afin que les variantes soient générées automatiquement à chaque mise en production, et le guide de localisation afin que votre gagnant soit traduit dans plus de 30 langues sans retester chacune.

Comment faire des tests A/B sur les captures d'écran App Store pour la conversion

TL;DR