Bonnes pratiques pour des captures d’écran App Store qui résistent à un test
TL;DR:
- La plupart des bonnes pratiques pour les captures d’écran App Store ne sont pas des pratiques. Ce sont des hypothèses qui ont fonctionné pour l’app de quelqu’un d’autre.
- Seules deux choses sont immuables : ce qu’Apple impose et ce que le store affiche mécaniquement.
- Vous testez tout le reste sur votre propre trafic.
- Dans Apple Ads, cette différence coûte de l’argent, car vous payez par tap.
- Un ensemble d’assets faible se traduit par un tap plus cher, pas seulement par une capture d’écran moins performante.
Ce qui compte réellement comme bonnes pratiques pour les captures d’écran App Store
Les bonnes pratiques pour les captures d’écran App Store se répartissent en deux catégories, et les mélanger est l’erreur la plus fréquente.
Les contraintes sont ce qu’Apple impose et ce que le store affiche mécaniquement. Ce ne sont pas des opinions. Respectez-les une fois, puis cessez de les relire.
- Captures d’écran dans les résultats de recherche. Selon l’orientation, les une à trois premières images apparaissent dans les résultats de recherche, et uniquement lorsqu’aucune vidéo d’aperçu de l’app n’est disponible, conformément aux indications d’Apple sur la page produit. Les autres attendent que quelqu’un ouvre la page produit.
- Tailles et formats. Les spécifications des captures d’écran d’Apple définissent les limites d’importation. Notre article sur les tailles et dimensions des captures d’écran App Store contient la liste opérationnelle.
- L’icône de l’app. Elle est présente partout : dans les résultats de recherche, sur la page, sur l’écran d’accueil. Plus de détails dans comment concevoir une icône d’app.
- La vidéo d’aperçu de l’app. Elle se lance automatiquement sans son, et jusqu’à trois peuvent figurer sur une même page. Lorsqu’il y en a une, elle prend l’emplacement dans les résultats de recherche que vos captures d’écran auraient occupé. La page Apple sur les aperçus d’app contient les règles.
Point clé : Une règle sur les captures d’écran en dehors de la couche des contraintes est une hypothèse, pas une bonne pratique, tant que votre propre trafic ne prouve pas le contraire.
Les hypothèses sont tout le reste. Arrière-plan sombre. Légendes sur la première image. Un visage sur la première capture. Ordre des fonctionnalités.
Chacune a été validée auprès d’une autre audience avec une autre intention de recherche. Pour votre app, c’est une supposition accompagnée d’une belle capture d’écran.
Alors, classez chaque règle dans l’une ou l’autre catégorie avant de briefer un designer. Ensuite, traitez la catégorie des hypothèses comme un point de départ, jamais comme une exigence. Les idées qui méritent d’être testées se trouvent dans notre article sur l’optimisation des captures d’écran App Store.
Pourquoi vos captures d’écran déterminent ce que vous payez dans Apple Ads
Vos captures d’écran déterminent ce que vous payez, car Apple Ads facture par tap, et non par impression. Trois éléments distincts déterminent le résultat, et il est utile de les séparer.
- Votre enchère est un plafond. Elle limite ce que vous pouvez payer. Elle ne détermine pas ce que vous payez.
- La pertinence détermine la diffusion. La sémantique du mot-clé par rapport à votre fiche store détermine si vous êtes éligible, avant même qu’une question de création n’entre en jeu.
- La réponse aux assets détermine la valeur d’une impression. L’icône de l’app et les premières captures d’écran influencent le taux de tap. Le reste de la page produit influence le taux de conversion du tap au téléchargement.
Point clé : Une enchère plafonne le coût possible d’un tap. La pertinence et la réponse aux assets déterminent si vous êtes affiché et ce que vous payez réellement.
Passons maintenant à la partie qui relève de l’observation, et non d’un mécanisme documenté.
Ce que j’ai observé, c’est qu’une app qui convertit mal reçoit moins de volume et des taps plus chers. Ce sont exactement les deux problèmes que les gens essaient de corriger en augmentant une enchère. Apple ne publie pas cette logique ; considérez-la donc comme un schéma à surveiller plutôt que comme une règle sur laquelle planifier.
La conclusion pratique reste valable dans les deux cas. Un ensemble d’assets faible est un problème de prix, pas seulement de design.
C’est là que le travail sur les assets s’arrête généralement trop tôt. La refonte est publiée, et personne ne revient vérifier ce qui est arrivé au CPT ou au taux de tap.
Les pages produit personnalisées donnent à chaque intention de recherche ses propres assets
Les pages produit personnalisées sont des variantes de pages produit qui affichent un ensemble d’assets différent selon le trafic, et un groupe d’annonces Apple Ads peut pointer vers une page spécifique.
C’est important, car une page par défaut unique servant tout le monde est un outil de moyennage.
Une personne qui recherche le nom de votre marque et une personne qui recherche un terme de catégorie générique ne sont pas les mêmes. Aujourd’hui, elles arrivent sur des assets identiques.
Une hypothèse de départ : la personne qui recherche la marque veut être rassurée, tandis que celle qui recherche une catégorie veut voir votre différenciation dès la première capture. C’est un point de départ pour un test, pas un fait sur le comportement des utilisateurs.
Point clé : Segmenter les assets par intention de recherche est ce que permettent les pages produit personnalisées. Ce qu’il faut dire à chaque intention, c’est le test qui le décide.
Le nombre de pages dont vous avez besoin dépend de vos thèmes de mots-clés, pas d’un nombre cible. Les candidats naturels :
- Marque
- Concurrent
- Catégorie et générique
- Fonctionnalité ou cas d’usage
Un thème avec sa propre intention et un volume suffisant peut avoir sa propre page. Un thème sans ce volume peut parfaitement rester sur la page par défaut.
C’est l’argument du groupe d’annonces à mot-clé unique appliqué à la création. Un contrôle fort lorsque le volume le justifie, une pure surcharge lorsqu’il ne le justifie pas. Ce n’est pas une règle à appliquer partout.
Les mécanismes sont expliqués dans les pages produit personnalisées dans l’App Store et dans la documentation Apple sur les pages produit personnalisées.
Comment effectuer des tests A/B sur les assets App Store sans deviner
Un test d’assets App Store ne répond à une question que lorsque le groupe d’annonces qui le sous-tend possède un véritable historique. Une poignée d’installations par mois mesure du bruit, pas la création.
C’est pourquoi un outil sérieux refuse de démarrer sans historique. Pour être transparent : je travaille chez Adapty, donc ce n’est pas un avis neutre.
- Historique. Les tests A/B de CPP d’Adapty Ads Manager exigent que le groupe d’annonces source ait au moins 28 jours, avec des impressions, des taps et des installations sur cette période.
- Variantes. Un test compare 2 à 4 pages produit. Votre page par défaut peut servir de contrôle lorsque vous voulez savoir si une page personnalisée surpasse votre référence. Un test portant uniquement sur des pages personnalisées convient aussi.
Le niveau de trafic détermine également la vitesse de rotation des variantes :
| Intervalle de bascule | Niveau de trafic | Durée de test typique |
| Horaire | Élevé (5 000+ impressions par jour) | Jours |
| Quotidien | Normal | Semaines |
| Hebdomadaire | Faible (moins de 400 impressions par jour) | Mois |
Un trafic faible n’empêche pas un test. Cela signifie simplement que la réponse prendra des mois.
Point clé : Un test d’assets n’a de sens que lorsque le groupe d’annonces qui le sous-tend a suffisamment d’historique pour distinguer le signal du bruit.
Pour en lancer un
- Convenez de la métrique décisive avant le lancement, alors que personne ne regarde encore les résultats. Le tableau des variantes indique le TTR, le taux de conversion tap-téléchargement, le CPT, le CPA, les dépenses, les revenus et le ROAS.
- Choisissez un groupe d’annonces avec un historique, afin de pouvoir comparer plusieurs pages entre elles.
- Choisissez 2 à 4 variantes, avec ou sans votre page par défaut comme contrôle.
- Définissez la précision, soit la plus petite différence de conversion que le test peut détecter. Les options vont de 1 % à 5 %, avec 5 % par défaut ; 3–4 % est le choix équilibré.
- Définissez le niveau de confiance, de 80 % à 99 %, avec 90 % par défaut. Un niveau de confiance plus élevé nécessite davantage de données et de temps.
- Lancez-le. Le système clone le groupe d’annonces une fois par variante, exécute un clone à la fois et effectue la rotation selon votre calendrier. L’original est restauré à la fin.
- Interprétez strictement la règle du gagnant. Une variante est la gagnante globale uniquement lorsqu’elle mène sur la métrique décisive avec un niveau de confiance d’au moins 95 %. Avant que les variantes aient des impressions comparables, rien n’est mis en évidence.
La product page optimization d’Apple couvre les tests sur le trafic organique. Le processus ci-dessus en est la version pour les médias payants.
Nous développons encore une chose : tester les créations publicitaires elles-mêmes pour Apple Ads, et pas seulement les pages produit. Ce n’est pas encore publié.
