Test A/B mobile : 7 grosses erreurs et idées fausses à éviter

Ce n'est un secret pour personne que le marketing repose en grande partie sur les données. Il en va de même pour le marketing mobile et l'acquisition d'utilisateurs. Dans ce domaine, choisir les bons éléments de page de produit pour l'App Store et Google Play peut faire une différence cruciale dans le succès d'une application ou d'un jeu mobile. Le test A/B mobile est un outil qui aide à faire ce choix en fonction des données.

Cependant, combien de fois avons-nous entendu l'argument selon lequel les tests A/B n'apportent pas les résultats souhaités ou que quelqu'un n'est pas sûr de mener correctement les expériences mobiles ? Cela se produit souvent en raison d'erreurs courantes et d'une mauvaise interprétation des données. Dans cet article, je couvrirai les plus grandes erreurs et les conclusions trompeuses des tests A/B d'applications mobiles, dont la connaissance vous aidera à réussir.

1. Terminer un test avant d'obtenir la bonne quantité de trafic

C'est l'une des erreurs les plus courantes dans les tests A/B mobiles. Si vous êtes un adepte des tests A/B classiques, terminer un test avant d'obtenir la quantité de trafic nécessaire (taille de l'échantillon) présente un risque d'obtenir des résultats statistiquement peu fiables .

Pour obtenir des preuves fiables, vous devez attendre que le volume de trafic requis soit atteint pour les variantes A et B.

Si vous cherchez une alternative à l'option classique, recourez à l'A/B Testing séquentiel. Vous devrez commencer par spécifier le taux de conversion de base (taux de conversion de votre variation actuelle), la puissance statistique (80% par défaut), le niveau de signification et l'effet minimum détectable (MDE) - cela vous aidera à déterminer la taille de l'échantillon.

Le niveau de signification est de 5% par défaut, ce qui signifie que la marge d'erreur ne dépassera pas 5%. Vous pouvez personnaliser cette valeur avec le MDE - l'augmentation minimale attendue du taux de conversion que vous aimeriez voir . Remarque : ne modifiez pas le niveau de signification, le MDE ou la puissance statistique après avoir commencé une expérience.

Avec les tests A/B séquentiels, l'algorithme vérifiera en permanence vos variations sur le niveau de signification et la quantité de trafic restant jusqu'à la fin de l'expérience. C'est ainsi que cela fonctionne sur notre plateforme de test A/B SplitMetrics.

Leçon apprise : si vous exécutez des tests A/B classiques, ne terminez pas un test avant d'avoir atteint la bonne quantité de trafic. Sinon, essayez des tests A/B séquentiels, et vous pourrez vérifier les résultats à tout moment.

2. Terminer une expérience avant que 7 jours ne se soient écoulés

Pourquoi faut-il attendre au moins sept jours ? Eh bien, diverses applications et jeux mobiles connaissent des pics d'activité à différents jours de la semaine . Par exemple, les applications professionnelles surveillent les pics d'activité le lundi, tandis que les jeux sont les plus populaires parmi les utilisateurs le week-end.

Pour obtenir des résultats fiables à partir d'expériences de test A/B sur mobile, vous devez capturer les jours de pointe de votre application lors d'une expérience. Sinon, vous courez le risque de sauter aux conclusions.

Par exemple, vous exécutez des tests pour une application de gestion des tâches. Vous commencez une expérience le mercredi et la terminez le samedi. Mais la plupart de votre public cible utilise votre application le lundi. Ou vice versa, vous avez effectué des tests A/B pour votre jeu de course du vendredi au dimanche : les jours de pointe du jeu. Dans ce cas, les résultats seront également insuffisants.

Ainsi, même si vous avez évité l'erreur numéro un et que vous avez déjà obtenu le volume de trafic requis dès le premier jour, n'arrêtez pas l'expérience avant que sept jours ne se soient écoulés.

Leçon apprise : en raison des faibles pics d'activité qui varient pour chaque jeu ou application mobile, ne terminez pas une expérience avant la fin du cycle complet (sept jours).

3. Tester de trop petites modifications de conception

Une autre erreur courante dans les tests A/B mobiles consiste à comparer des variations qui se ressemblent presque en raison de différences mineures de conception.

Si la seule différence entre les icônes d'applications mobiles que vous testez est une couleur d'arrière-plan bleue au lieu du bleu clair, ou si vous avez ajouté un petit détail à une autre variante de capture d'écran, vous êtes définitivement en difficulté. Les utilisateurs ne remarquent tout simplement pas ces petits changements.

Dans ce cas, les deux variantes donneront le même résultat, et c'est tout à fait normal. Donc, si vous avez déjà essayé d'exécuter les tests A/B de l'App Store, mais que vous les avez abandonnés, étant donné que les variations ont fonctionné de la même manière, il est temps de réfléchir à ce qui n'a pas fonctionné. Peut-être que vos variantes se ressemblaient à peu près.

Pour vous assurer que vous testez A/B un changement significatif, montrez les deux versions à votre famille ou à vos amis. Laissez votre collègue regarder chaque variation pendant 3 à 5 secondes. S'ils ne connaissent pas la différence, vous feriez mieux de reconcevoir vos ressources visuelles.

Leçon apprise : si vous testez des variantes avec des changements de conception trop petits, vous devez vous attendre à ce qu'elles affichent le même résultat. De tels changements sont trop insignifiants pour les utilisateurs, il est donc préférable de tester les icônes d'applications et les captures d'écran qui diffèrent sensiblement les unes des autres.

4. Vos bannières publicitaires ont le même design que l'un des éléments visuels de l'App Store

Si vous utilisez un outil de test A/B mobile tiers, comme par exemple SplitMetrics, vous achetez du trafic et placez des bannières sur les réseaux publicitaires. Le fait est qu'une telle bannière ne doit pas ressembler à l'un des éléments visuels que vous testez , qu'il s'agisse d'une capture d'écran ou des mêmes éléments sur une icône.

Par exemple, vous exécutez des expériences pour votre application éducative. Vous concevez une bannière qui a le même élément que l'icône de la variante A, tandis que la variante B est complètement une autre icône. La variante A affichera le taux de conversion le plus élevé, car elle a le même design que celui que les utilisateurs de la bannière ont initialement vu et sur lequel ils ont cliqué.

Des études montrent que si les gens voient quelque chose à plusieurs reprises, leur cerveau traite les informations plus rapidement, ce qui leur procure un sentiment d'appréciation. Vous pouvez en savoir plus à ce sujet ici. Ainsi, les utilisateurs ont tendance à appuyer inconsciemment sur les images déjà familières.

Leçon apprise : lorsque vous travaillez sur des bannières publicitaires, faites en sorte que le design soit aussi neutre que possible. La conception de la bannière ne doit pas coïncider avec la conception de l'icône ou des variantes de captures d'écran de votre application.

5. Tester plusieurs hypothèses à la fois

Cela n'a aucun sens d'apporter plusieurs modifications et de les tester au sein d'une même expérience. Certains spécialistes du marketing mobile tirent de mauvaises conclusions après avoir effectué un test, car ils ont apporté plusieurs modifications et, en fait, ne peuvent pas savoir exactement ce qui a affecté le résultat.

Si vous avez décidé de changer la couleur des captures d'écran de la page produit de votre app store, créez une ou plusieurs variantes avec une autre couleur d'arrière-plan et lancez un test. Ne modifiez pas la couleur, l'ordre et le texte des captures d'écran en même temps. Sinon, vous verrez la variante gagnante (que ce soit la variante B), et vous n'aurez aucune idée si c'est le changement de couleur qui a réellement fonctionné.

Leçon apprise : si vous testez plusieurs hypothèses à la fois, vous ne pourrez pas comprendre laquelle d'entre elles est correcte.

6. Mal interpréter la situation lorsque deux variantes sont identiques mais que vous obtenez un gagnant

Lors de l'exécution de tests A/A, vous pouvez être confus lorsqu'un outil de test A/B affiche la variation gagnante entre deux actifs identiques. En particulier, cela est courant pour l'outil intégré du Google Play Store pour l'exécution d'expériences.

Sur la plateforme SplitMetrics, au seuil de 5% de significativité, dans un tel cas, vous verrez que le résultat est insignifiant.

Les petites différences entre deux variations exactement identiques sont une pure coïncidence. Différents utilisateurs ont réagi un peu différemment. C'est comme lancer une pièce : il y a 50-50 chances que vous obteniez pile ou face, et il y a 50-50 chances que l'une des variantes donne un meilleur résultat.

Pour obtenir un résultat statistiquement significatif dans une situation comme celle-ci, vous devez obtenir des résultats d'absolument tous les utilisateurs, ce qui est impossible.

Leçons apprises : si vous obtenez la variante gagnante en testant des actifs identiques, il n'y a rien de mal avec votre outil de test A/B, c'est juste une coïncidence. Cependant, avec des tests A/B séquentiels, vous verrez que le résultat est insignifiant.

7. S'énerver lorsqu'une nouvelle variante perd face à l'actuelle

Certains spécialistes du marketing mobile et responsables de l'acquisition d'utilisateurs sont déçus lorsqu'une expérience montre que la variante actuelle l'emporte, ce à quoi ils ne s'attendaient pas, et commencent à gaspiller un budget sur un trafic plus payant dans l'espoir que la nouvelle variante finira par gagner.

Il n'y a aucune raison de se sentir mal si votre hypothèse n'a pas été confirmée. Si vous aviez modifié quelque chose sur la page produit de votre app store sans tester, vous auriez perdu une partie de vos clients potentiels et, par conséquent, de l'argent. En même temps, après avoir dépensé de l'argent pour cette expérience, vous avez payé pour la connaissance . Vous savez maintenant ce qui fonctionne pour votre application et ce qui ne fonctionne pas.

Leçon apprise : tout arrive pour une raison, et vous ne devriez pas être désolé si votre test A/B n'a pas confirmé votre hypothèse. Vous avez maintenant une vision claire des actifs les plus performants pour votre jeu ou votre application.