Vous avez configuré un test d'optimisation de la page de produit, il tourne depuis des semaines et le niveau de confiance refuse toujours d'atteindre 90 %. Parfois, l'amélioration passe même de +12 % à −3 % avant de remonter.
Le test n'est pas cassé. C'est presque toujours l'une de deux choses : pas assez d'impressions, ou un changement trop petit pour être mesuré. Ce guide montre combien d'impressions un test demande réellement et comment en concevoir un qui aboutit dans la limite de 90 jours fixée par Apple.
Ce que signifie « confiance » dans App Store Connect #
Pour chaque traitement, App Store Connect affiche les impressions, le taux de conversion, l'amélioration par rapport à l'original et un niveau de confiance. Apple indique qu'un traitement fait mieux ou moins bien dès qu'il atteint 90 % de confiance.
Concrètement : 90 % de confiance signifie que la différence observée a peu de chances d'être due au hasard. En dessous, la variante est peut-être meilleure, ou vous regardez peut-être du bruit. Apple recommande d'attendre qu'au moins un traitement atteigne 90 % avant de l'appliquer.
Le test ne s'arrête pas tout seul une fois ce seuil atteint. Il tourne jusqu'à ce que vous l'arrêtiez, que vous appliquiez un traitement ou qu'il atteigne 90 jours.
Combien d'impressions un test demande #
Le nombre d'impressions nécessaires dépend surtout de l'ampleur de la hausse que vous cherchez à détecter. Le tableau ci-dessous repose sur un test standard de comparaison de deux proportions, avec 90 % de confiance et 80 % de puissance. Apple ne publie pas sa méthode exacte : considérez ces chiffres comme des estimations de planification, pas comme des promesses.
Impressions nécessaires par variante (l'original en demande autant) :
| Taux de conversion actuel | Hausse de +5 % | Hausse de +10 % | Hausse de +20 % | Hausse de +30 % |
|---|---|---|---|---|
| 2 % | 248 000 | 64 000 | 17 000 | 7 700 |
| 3 % | 164 000 | 42 000 | 11 000 | 5 100 |
| 5 % | 96 000 | 25 000 | 6 400 | 3 000 |
Deux choses sautent aux yeux :
- Diviser la hausse par deux multiplie à peu près les impressions par quatre. Détecter +5 % demande environ 15 fois plus d'impressions que détecter +20 %.
- Un taux de conversion plus faible demande plus de trafic. Les événements rares sont plus difficiles à mesurer.
Ce que cela représente en jours #
Voici le même calcul exprimé en jours, pour un taux de conversion de 3 %, une variante et 50 % du trafic envoyé vers le test :
| Impressions par jour | Hausse de +5 % | Hausse de +10 % | Hausse de +20 % | Hausse de +30 % |
|---|---|---|---|---|
| 500 | 656 jours ❌ | 168 jours ❌ | 44 jours | 21 jours |
| 2 000 | 164 jours ❌ | 42 jours | 11 jours | 6 jours |
| 10 000 | 33 jours | 9 jours | 3 jours | 2 jours |
Une app qui reçoit 500 impressions par jour ne peut pas détecter une hausse de 10 % en 90 jours, peu importe combien de temps elle attend. C'est la raison la plus fréquente pour laquelle un test n'atteint jamais le niveau de confiance : il n'avait aucune chance d'y arriver.
Essayez vos propres chiffres dans le calculateur gratuit de test A/B pour l'App Store. Il indique aussi la plus petite hausse que votre trafic peut détecter en 90 jours.
Cinq façons de faire aboutir un test #
1. Tester un changement plus important #
C'est de loin le levier le plus efficace. Au lieu de changer un mot dans une légende, changez toute la première capture, ou tout le style des légendes. Un changement audacieux susceptible de faire bouger la conversion d'au moins 20 % se mesure avec un trafic modeste ; un ajustement qui vaut 3 %, non. Notre liste de 25 idées de tests A/B pour vos captures en contient beaucoup d'audacieuses.
2. Utiliser moins de variantes #
Chaque variante a besoin de la totalité des impressions. Avec 2 000 impressions par jour, une hausse de 10 % et 50 % du trafic vers le test, une variante demande environ 42 jours. Trois variantes demandent environ 126 jours, ce qui dépasse la limite. Si le trafic est juste, testez une variante à la fois.
3. Envoyer plus de trafic vers le test #
Avec une variante, une répartition 50/50 est la plus rapide. Avec davantage de variantes, envoyez plus de trafic vers le test : la répartition la plus rapide donne le même nombre de visiteurs à chaque version, soit 67 % vers le test avec deux variantes et 75 % avec trois. Dans l'exemple ci-dessus, passer trois variantes de 50 % à 75 % ramène le test de 126 à 84 jours.
La contrepartie : si une variante est moins bonne, plus de gens la voient pendant le test.
4. Tester là où se trouve votre trafic #
Un test inclut les localisations que vous choisissez, et seules les impressions de ces marchés comptent. Tester sur un petit marché, c'est attendre le trafic de ce marché. Commencez par votre marché le plus fréquenté, ou incluez plusieurs marchés dont vous attendez la même réaction. Voir les tests A/B de captures localisées.
5. Tester par semaines complètes, et ne pas y toucher #
Les visiteurs de la semaine et ceux du week-end ne se comportent pas de la même façon : faites donc tourner vos tests au moins une ou deux semaines complètes, même si les chiffres semblent tranchés plus tôt. Et n'arrêtez pas le test le premier jour où il dépasse 90 %. Vérifier tous les jours et s'arrêter au premier chiffre flatteur rend les fausses victoires bien plus probables.
Quand abandonner un test #
Si un test a reçu les impressions prévues par votre estimation et que la confiance reste faible, c'est un résultat en soi : la variante ne fait pas une différence assez grande pour compter. Arrêtez le test, gardez l'original et essayez une idée plus audacieuse. Ce n'est pas un test raté. Vous savez désormais que cet élément ne compte pas beaucoup pour vos utilisateurs.
Rendez les tests assez simples pour les répéter #
Le trafic limite le nombre de tests que vous pouvez mener par an, alors chacun doit en valoir la peine. Créer les variantes ne devrait pas être ce qui vous ralentit. Dans Screenshot Studio, un changement de design s'applique à toutes les langues et à toutes les tailles d'appareil, et la variante est téléversée directement dans votre test d'optimisation de la page de produit. Lisez aussi les erreurs d'optimisation de la page de produit qui gâchent un test.