Expériences de fiche store sur Google Play : l'A/B testing de tes captures d'écran (2026)

Sur Google Play, tu n'as pas besoin de deviner si une nouvelle première capture d'écran convertit mieux que l'ancienne — tu peux le tester sur du vrai trafic Play Store. Les Store listing experiments sont intégrées à Play Console, sous Test and release → Store listing experiments (Google a déplacé l'emplacement du menu plus d'une fois ; les guides plus anciens l'appellent « Grow → Store listing experiments »). C'est gratuit, ça tourne sur ta fiche en direct, et Google gère pour toi la répartition du trafic et les statistiques.

Si tu publies sur les deux stores, c'est le pendant du dispositif d'Apple. On a couvert le côté iOS dans A/B testing des captures d'écran avec Product Page Experiments — même principe, mécanique différente. Cet article est le complément côté Play.

Comment fonctionnent les Store listing experiments

Tu crées une expérience, tu choisis l'asset à tester (icône de l'app, captures d'écran, feature graphic, vidéo promo, description courte ou description longue), puis tu uploades jusqu'à 3 variantes aux côtés de ta fiche en direct — qui sert de contrôle. Google diffuse ensuite les variantes à une tranche d'utilisateurs qui atterrissent sur ta fiche store, et mesure laquelle génère le plus d'installations.

Deux métriques comptent dans les résultats :

• Acquisition (conversion de la fiche store). La part de visiteurs qui installent après avoir vu une variante donnée. C'est le chiffre principal pour les tests de captures d'écran.
• Utilisateurs conservés parmi les premières installations (rétention à 1 jour). Est-ce que les personnes attirées par une variante restent réellement le lendemain ? Une variante qui génère plus d'installations mais une moins bonne rétention a peut-être trop promis.

Google calcule un intervalle de confiance par variante et, quand une variante franchit ton seuil de confiance choisi, la déclare gagnante. Tu peux activer une alerte e-mail pour ne pas avoir à surveiller le tableau de bord en permanence. Appliquer un gagnant prend un clic — mais tu voudras généralement quand même faire passer l'asset gagnant par ton flux normal de publication/révision, pour que le reste de ta fiche reste cohérent.

Graphiques par défaut vs expériences localisées

C'est le point où la plupart des gens trébuchent, et il détermine combien de tests tu peux mener en parallèle.

• Expérience sur les graphiques par défaut. Teste les assets de ta fiche store par défaut — celle montrée à quiconque ne reçoit pas de version localisée. Les utilisateurs qui reçoivent des assets localisés sont exclus de l'audience de cette expérience. Tu ne peux lancer qu'une seule expérience sur les graphiques par défaut à la fois.
• Expérience de fiche store localisée. Teste des assets (et/ou du texte) pour une langue précise. Tu peux lancer jusqu'à 5 expériences localisées simultanément — par exemple une pour l'allemand, une pour le japonais, une pour le portugais brésilien, et ainsi de suite, toutes en même temps.

En pratique : si ta base d'installations est concentrée sur une poignée de marchés, les expériences localisées te permettent de tester ces marchés en parallèle au lieu de les mettre en file d'attente derrière un seul test global. Et ne suppose pas qu'une langue équivaut à un pays — sélectionner « Anglais (États-Unis) » ne restreint pas l'audience aux États-Unis ; ça cible tous ceux qui reçoivent cette fiche localisée, où qu'ils soient.

Mettre en place un A/B test de captures d'écran

1. Ouvre Store listing experiments et crée-en une. Choisis la fiche par défaut ou une fiche localisée précise, et donne-lui un nom que tu comprendras encore dans trois semaines (« Capture héros — légende orientée bénéfice v2 »).
2. Choisis l'asset. Sélectionne captures d'écran. Teste un seul élément par expérience — ne change pas l'icône et les captures d'écran dans le même test, sinon tu ne sauras pas ce qui a fait bouger l'aiguille.
3. Uploade jusqu'à 3 variantes. Ta fiche en direct fait office de contrôle. Chaque variante est un jeu complet de captures d'écran, aux bonnes dimensions Play — voir le guide des tailles de captures d'écran Google Play pour les specs exactes.
4. Définis l'audience, la confiance et l'EMD. Répartis le trafic entre les variantes (souvent à parts égales — 50/50 pour une variante contre le contrôle, ou environ un tiers chacune pour trois). Choisis un niveau de confiance (90 %, 95 %, 98 % ou 99 %) et un effet minimal détectable (EMD) — la plus petite amélioration qui vaille la peine d'être détectée, configurable environ entre 0,5 % et 6 %. Play Console affiche les conditions de fin, pour que tu saches à quoi tu t'engages avant de démarrer.
5. Lance-le et n'y touche plus. Résiste à l'envie de regarder et d'arrêter dès qu'une variante semble prendre l'avantage. Laisse-le tourner jusqu'aux conditions que tu as fixées.

Taille d'échantillon, durée et atteindre la significativité

La réponse honnête à « combien de temps faut-il le faire tourner ? » est : jusqu'à ce qu'il atteigne les conditions de significativité que tu as fixées — pas un nombre de jours fixe. Mais il existe des planchers et des plafonds concrets.

• Fais tourner au moins 7 jours. Le comportement d'installation varie entre semaine et week-end. Tout ce qui est plus court qu'une semaine complète introduit un biais lié au jour de la semaine dans ton résultat. Deux semaines (14 jours) est un défaut courant et plus sûr, et les apps à faible trafic ont souvent besoin de 28 jours.
• Assez d'installations par variante pour compter. La significativité dépend de ton volume d'installations, du nombre de variantes, de ton niveau de confiance et de ton EMD. Comme objectif de travail approximatif, vise de l'ordre de 1 000+ installations par variante avant de faire confiance au résultat — davantage si tu fixes un niveau de confiance élevé ou un EMD faible.
• Des réglages plus stricts coûtent du trafic. Un niveau de confiance de 99 % ou un EMD de 0,5 % nécessite bien plus d'installateurs que 90 % / 3 %. Si ton app a un faible volume, une configuration exigeante risque de ne jamais atteindre la significativité — assouplis l'EMD ou accepte 90 %.

Un test qui se termine « non concluant » est un résultat en soi, pas un échec. Ça signifie généralement que les variantes étaient trop proches pour se distinguer à ton niveau de trafic, ou que tu ne l'as pas fait tourner assez longtemps. Les deux se corrigent — rends les variantes plus distinctes, ou donne-lui plus de temps.

La limite de variantes et ce qu'elle implique

Trois variantes contre le contrôle, c'est le plafond strict par expérience. C'est une fonctionnalité, pas une contrainte à combattre : chaque variante supplémentaire divise ton trafic un peu plus finement et repousse d'autant la significativité. Avec trois challengers, tu divises déjà ton trafic store en quatre (contrôle + 3). Pour la plupart des apps, tester un seul challenger audacieux et clairement différent contre le contrôle mène à une conclusion plus vite que quatre variations timides n'y arriveront jamais.

Utilise les emplacements pour des hypothèses réellement différentes — un bénéfice principal différent, un style visuel différent, portrait vs mise en page large multi-panneaux — pas pour des nuances de la même idée.

Pièges à éviter

• Changer plus d'une variable. Nouvelles captures d'écran et nouvelle description courte dans un même test = résultat impossible à interpréter. Isole la variable.
• Arrêter tôt sur un « gagnant ». Les avances précoces se résorbent. Trancher au jour 3 parce qu'une variante est en avance de 8 % est la meilleure façon de publier une fiche pire en toute confiance.
• Faire tourner moins de 7 jours. Tu ne capteras qu'une partie du cycle hebdomadaire et rateras le reste.
• Des stats trop strictes sur une app à faible trafic. Exiger 99 % / 0,5 % d'EMD avec des installations modestes garantit un test non concluant et coûteux en temps.
• Ignorer la rétention à 1 jour. Une capture d'écran qui promet trop peut faire grimper les installations et plomber la rétention. Surveille les deux chiffres.
• Oublier la séparation par défaut/localisé. Une expérience sur les graphiques par défaut ne touche pas les utilisateurs des fiches localisées — si ton audience est surtout localisée, teste là-bas.
• Ne tester que la dernière capture d'écran. Les 2 à 3 premiers panneaux font l'essentiel du travail de conviction sur le Play Store. Teste-les en premier. (Plus de détails sur les différences entre Play et Apple ici : Play Store vs App Store : différences des captures d'écran.)

La place de Mokbi

Mokbi ne fait pas tourner l'A/B test — c'est Play Console qui s'en charge, gratuitement. Ce qui ralentit la plupart des équipes, c'est de produire les variantes en premier lieu : un challenger crédible, c'est un jeu complet de captures d'écran, aux bonnes dimensions Play, avec la légende et la mise en page réellement changées. Dans Mokbi, tu conçois un jeu dans le navigateur, puis tu le dupliques et tu changes la légende principale, la mise en page ou le fond pour créer la variante B — et tu traduis les légendes en un clic si tu mènes des expériences localisées sur plusieurs marchés. La conception est gratuite avec un aperçu filigrané ; l'export sans filigrane illimité et la publication sur les stores viennent avec un abonnement — Solo à €29.99/mo (1 app) ou Studio à €49.99/mo (jusqu'à 5 apps), sans achat unique. Ça construit les challengers rapidement ; Play Console décide lequel gagne.

À lire ensuite

• A/B testing des captures d'écran avec Product Page Experiments — le pendant côté Apple
• Play Store vs App Store : différences des captures d'écran
• Guide des tailles de captures d'écran Google Play

Ouvrir l'éditeur →