Obtenir ton design gratuit
· Optimisation · 4 min de lecture

A/B testing des captures d'écran avec Product Page Experiments

A/B testing des captures d'écran avec Product Page Experiments
TL;DR. Product Page Experiments est l'outil gratuit d'A/B testing d'Apple pour les captures d'écran de l'App Store. Ça fonctionne, mais c'est lent si tu l'utilises mal. Lance-le avec une hypothèse claire sur une seule variable à la fois, donne-lui la taille d'échantillon dont il a réellement besoin, et tu obtiens des résultats directionnels nets en deux semaines. Lance-le avec cinq variables et 50 % du trafic sur chacune, et tu récolteras du bruit pendant six semaines.

Product Page Experiments (PPE) est sorti avec iOS 15 et est depuis lors la méthode de référence pour faire de l'A/B testing sur les métadonnées de l'App Store. Tu configures un contrôle plus jusqu'à trois variantes de traitement, tu alloues le trafic, tu choisis un niveau de confiance, et Apple te dit laquelle a gagné. L'infrastructure est solide ; la rigueur autour de son utilisation, beaucoup moins.

Ce que PPE mesure vraiment

PPE mesure les impressions et les conversions sur la page produit elle-même. Plus précisément :

  • Impressions : les utilisateurs qui ont atterri sur ta page produit.
  • Conversions : les utilisateurs qui ont appuyé sur Obtenir/Acheter après être arrivés.

PPE ne mesure PAS le taux de clic depuis la liste de recherche (c'est-à-dire si les utilisateurs appuient sur ton résultat de recherche pour atterrir sur la page). Pour ça, il faudrait tester l'aperçu dans les résultats de recherche, qui utilise les 3 premiers panneaux de ta locale par défaut. PPE peut tester le carrousel complet, mais ne mesure que ce qui se passe une fois que l'utilisateur est déjà sur la page.

C'est important car les modifications des panneaux 4 à 10 n'affectent que la conversion sur la page produit, tandis que les modifications des panneaux 1 à 3 affectent à la fois le taux de clic depuis la liste de recherche et la conversion sur la page produit. PPE mesure le second, pas le premier.

La règle « une variable à la fois »

La tentation est de changer tout le carrousel entre les variantes. Ne le fais pas. Si la variante A a de nouvelles légendes, un nouvel angle d'appareil et une nouvelle palette, et que la variante A gagne — tu ne sais pas quel changement a provoqué la hausse. Tu ne peux pas non plus tirer d'enseignement transférable pour ton prochain test.

La discipline : change une seule chose par test. Nouvelle légende sur le panneau 1, tout le reste identique. Nouvelle couleur de fond, légendes identiques. Nouvel ordre de panneaux, contenu identique. C'est lent, mais chaque test produit un apprentissage sur lequel tu peux construire. Itérer vite sur du bruit, ce n'est pas avancer.

Taille d'échantillon : la partie que la plupart des équipes sous-estiment

PPE utilise les tests d'hypothèses fréquentistes standards. La taille d'échantillon dont tu as besoin dépend de :

  • Ton taux de conversion de référence (généralement 1-5 % pour les apps gratuites, moins pour les payantes).
  • L'effet minimal détectable qui t'importe (hausse relative de 5 %, 10 %, 20 % ?).
  • Ton trafic vers la page produit.

Ordre de grandeur : détecter une hausse relative de 10 % sur un taux de conversion de référence de 3 % nécessite environ 20 000 impressions par variante pour un niveau de confiance de 95 %. Si ton app reçoit 2 000 impressions sur la page produit par semaine, cela représente 10 semaines par test. La plupart des apps indépendantes n'ont pas le trafic nécessaire pour mener des tests statistiquement propres sur de petits effets. Les options honnêtes :

  • Tester uniquement les changements importants — changements de palette, ordre des panneaux, ton de légende fondamentalement différent. Ces tests atteignent la significativité rapidement parce que l'effet est plus grand.
  • Réduire l'allocation du trafic à une ou deux variantes plutôt que trois.
  • Accepter un résultat directionnel, pas significatif. Si une variante gagne régulièrement sur 4 semaines à 70 % de confiance, publie-la et lance un test différent ensuite.

La méthode de test qui fonctionne

  1. Choisis une hypothèse. « Des légendes plus grandes sur le panneau 1 amélioreront la conversion, car les miniatures réduisent les petites légendes à un texte illisible. » Une conjecture précise, pas « voyons ce qui marche ».
  2. Conçois la variante A : un seul changement. Même carrousel, seule la légende du panneau 1 est modifiée. Tout le reste identique.
  3. Alloue 50 % au contrôle, 50 % à la variante. Les tests à deux bras atteignent la significativité plus vite que ceux à trois ou quatre bras.
  4. Fixe la durée du test à l'avance. « On fait tourner ça 4 semaines ou jusqu'à 95 % de significativité, selon ce qui arrive en premier. » Résiste à l'envie de regarder et d'arrêter trop tôt.
  5. Documente le résultat. Qu'il gagne, perde ou soit non concluant — note-le. Sinon, tu relanceras le même test six mois plus tard.

Quoi tester, par ordre de priorité

  1. Légende du panneau 1. Impact le plus fort, car le panneau 1 domine à la fois les miniatures de recherche et la première impression sur la page produit.
  2. Ordre des panneaux. Précisément : quelle fonctionnalité mets-tu en avant ?
  3. Palette du carrousel / mode sombre vs clair. Effet important, rapide à tester.
  4. Inclinaison / orientation de l'appareil. Effet plus faible, mais simple à mettre en place.
  5. Ton de la légende (impératif vs descriptif). « Suis tes courses » vs « Tes courses, suivies ». Effet plus faible, signal plus difficile à lire.

Arrête de tester les polices, les légères variations de couleur ou le contenu des panneaux 8 à 10. Ces tests n'atteignent presque jamais la significativité, et les effets sous-jacents sont trop faibles pour que le gain vaille le budget de test.

Localisation dans PPE

PPE prend en charge les variantes par locale. Si tu lances un test dans ta locale par défaut et publies le gagnant, tu dois quand même appliquer manuellement le changement à chaque variante localisée du panneau. Choisis une locale avec suffisamment de trafic pour atteindre la significativité (généralement en-US) et traite le résultat comme un guide directionnel global pour les autres locales. Ne lance pas 39 expériences séparées.

Erreurs fréquentes

  • Regarder et arrêter trop tôt. La significativité fluctue aléatoirement pendant un test. Arrêter dès qu'une variante semble gagner mène à de mauvaises conclusions. Fixe une durée minimale et respecte-la.
  • Tester trop de variables. Les refontes complètes ne peuvent pas être testées en A/B proprement. Il faut un test séparé pour la nouvelle conception globale (multi-variables, accepte un certain biais), suivi de tests d'itération sur une seule variable sur le gagnant.
  • Lancer des tests pendant des périodes de bruit saisonnier. Black Friday, mises en avant dans l'App Store, campagnes marketing — tout ça ajoute du trafic et du bruit. Évite de tester pendant ces périodes, sauf si tu contrôles le pic.
  • Ignorer la locale. Un résultat de test US ne se généralise pas toujours à JP. Utilise-le comme hypothèse de départ, pas comme réponse définitive.

À faire ce mois-ci

  1. Estime tes besoins en taille d'échantillon. Introduis ton trafic et ton taux de conversion de référence dans un calculateur de taille d'échantillon avant de configurer le test.
  2. Choisis une hypothèse. Écris-la en une phrase.
  3. Conçois A vs B avec une seule variable modifiée. Lance dans App Store Connect.
  4. Fixe la durée d'exécution et note la date de fin dans ton calendrier.
  5. Documente le résultat quel que soit le résultat.

À lire ensuite

Ouvrir l'éditeur →