Article

6min lecture

A/A Testing : perte de temps ou réel intérêt ?

Méconnu et sujet à de vives discussions sur son utilité, l’A/A Testing apporte pourtant une vraie valeur ajoutée pour ceux qui cherchent à intégrer une solution d’A/B Testing avec rigueur et précision.

Mais avant toute chose …

Qu’est-ce que l’A/A Testing ?

L’A/A Testing est un dérivé de l’A/B Testing. Cependant, au lieu de comparer deux versions différentes (de votre page d’accueil, par exemple), on compare ici deux versions identiques.

Deux versions identiques ? Oui !

L’objectif principal d’un A/A Testing est simple : vérifier que la solution d’A/B Testing a été correctement configurée et est efficace.

On utilise l’A/A Testing dans 3 cas :

  • Pour vérifier l’exactitude de l’outil d’A/B Testing
  • Pour définir un taux de conversion de référence pour de futurs tests
  • Pour statuer sur une taille optimale d’échantillon pour les tests A/B

1. Vérifier l’exactitude de l’outil d’A/B Testing

Lorsqu’on effectue un test A/A, on compare donc 2 versions strictement identiques d’une même page.

Logiquement, le but d’un test A/A est d’afficher des valeurs similaires en termes de conversion. L’idée étant ici de prouver que la solution de test est efficace.

En toute logique, on organisera donc un A/A Test lorsque on met en place une nouvelle solution d’A/B Test ou que l’on passe d’une solution à une autre.

Cependant, il arrive qu’un « gagnant » soit déclaré sur deux versions pourtant identiques. Il faut donc chercher à comprendre « pourquoi » et c’est là tout l’intérêt de l’A/A Testing.

  • Le test peut ne pas avoir été conduit correctement
  • L’outil peut ne pas avoir été bien paramétré
  • La solution d’A/B Testing peut être inefficace.

2. Définir un taux de conversion de référence

Imaginons que vous souhaitiez mettre en place une série d’A/B Tests sur votre page d’accueil. Vous paramétrez la solution mais un problème surgit : vous ne savez pas sur quel taux de conversion comparer les différentes versions.

Dans ce cas précis, un A/A Test vous aidera à trouver le taux de conversion « référence » pour vos futurs A/B Tests.

Exemple : Vous lancez un A/A Test sur votre page d’accueil pour laquelle votre objectif est le remplissage d’un formulaire de contact. En comparant les résultats, vous obtenez des résultats quasi-identiques (et c’est normal) : 5,01% et 5,05% de conversion. Vous pouvez désormais utiliser cette donnée avec la certitude qu’elle représente bien la réalité de votre taux de conversion et activer vos A/B Tests pour essayer de dépasser ce taux. Si vos A/B Tests vous indiquent qu’une « meilleure » variation réalise 5,05% de conversion, c’est qu’en réalité il n’y a pas de progrès.

3. Trouver une taille d’échantillon pour de futurs tests

Le problème lorsqu’on compare deux versions similaires, c’est le paramètre « chance ».

En effet, les tests étant formulés sur des bases statistiques, il existe bien une marge d’erreur qui peut influencer les résultats de vos campagnes d’A/B Testing.

Pour diminuer cette marge d’erreur, pas de secret : il faut souvent augmenter la taille de l’échantillon de trafic pour diminuer le risque que des facteurs aléatoires (dits « de chance ») viennent biaiser les résultats.

En effectuant un test A/A, vous pourrez donc « voir » à quelle taille d’échantillon la solution de test se rapproche le plus de « l’égalité parfaite » entre vos versions identiques.

En somme, un A/A test vous permet de trouver la taille d’échantillon pour laquelle le facteur « chance » est minimisé : vous pourrez donc vous servir de cette taille d’échantillon pour vos futurs tests en A/B. Cela dit, les tests A/B requièrent de façon générale une taille d’échantillon inférieure.

L’ A/A Testing : une perte de temps ?

La question fait débat dans le milieu de l’A/B Testing : faut-il oui ou non prendre le temps de faire de l’A/A Test avant de faire de l’A/B Test.

Et c’est là toute la question : le temps.

Faire des A/A Tests prend un temps et un trafic considérable

En réalité, faire des A/A Tests prend du temps, considérablement plus de temps que des A/B Tests car le volume de trafic nécessaire pour prouver que les deux « variations identiques » amènent au même taux de conversion est conséquent.

Le problème, selon ConversionXL, est que l’A/A Testing est chronophage et empiète sur du trafic qui pourrait être utiliser à conduire de « vrais tests », c’est à dire destinés à comparer deux variations.

Enfin, l’A/A Testing est beaucoup plus facile à mettre en place sur des sites à fort trafic.

L’idée étant que si vous dirigez un site qui se lance, ou un site à faible trafic, il est inutile de perdre votre temps à faire de l’A/A Test : concentrez-vous plutôt sur l’optimisation de votre tunnel d’achat ou sur votre Customer Lifetime Value : vous arriverez à des résultats beaucoup plus probants et surtout beaucoup plus intéressants.

Une alternative intéressante : la comparaison de données

Pour vérifier l’exactitude de votre solution d’A/B Testing, il existe un autre moyen simple à mettre en place. Pour cela, il faut que votre solution d’A/B Testing puisse intégrer une autre source de données analytiques.

En faisant cela, vous pourrez comparer les données et voir si elles pointent au même résultat : c’est une autre façon de vérifier l’efficacité de votre solution de test.

Si vous constatez des différences significatives de données entre les deux sources, vous savez que l’une des deux est :

  • Soit mal paramétrée
  • Soit inefficace et doit donc être changée

Vous avez aimé cet article ? Nous serions ravis d’échanger davantage avec vous.

Campaign Trigger

Abonnez-vous à
notre Newsletter

bloc Newsletter FR

AB Tasty traite et stocke vos données personnelles pour vous envoyer des communications tel que détaillé dans notre politique de confidentialité ici.

Article

7min lecture

A/B Testing : comment gérer l’effet flicker ?

L’effet flicker consiste, lors d’un test A/B, à voir brièvement la page originale avant la page alternative, le temps pour le navigateur d’appliquer vos modifications. Il n’existe aucune méthode miracle pour éradiquer ce problème, certaines annoncées comme révolutionnaires ayant leurs limites. En revanche, il existe de nombreuses bonnes pratiques à suivre pour accélérer la prise en compte de vos modifications et rendre cet effet imperceptible.

L’effet flicker, c’est quoi ?

Si vous n’avez jamais entendu parler de l’effet flicker, vous en avez sans doute déjà fait l’expérience sans le savoir : la page testée se charge puis, au bout de quelques millisecondes, votre modification s’affiche. Résultat : vous voyez en un battement de cils, 2 versions de votre page : l’originale et la modifiée. Il en résulte un effet déplorable pour l’expérience utilisateur, sans parler de la pertinence de votre test puisque l’utilisateur peut prendre conscience qu’il est soumis à un test.

Cet effet est lié au principe de fonctionnement côté navigateur de nombreuses solutions d’A/B testing, lesquelles appliquent une surcouche JavaScript lors du chargement de la page pour en modifier les éléments. Dans la plupart des cas, vous ne constatez aucun effet mais si votre site est déjà long à charger ou qu’il fait appel à des ressources externes gourmandes, vos modifications prennent du temps à être appliquées. L’effet flicker, jusque-là passé inaperçu, est alors visible.

Existe-t-il une méthode miracle pour supprimer l’effet flicker ?

Certains fournisseurs annoncent utiliser des innovations techniques permettant d’éradiquer l’effet flicker. Attention, il ne s’agit ni plus ni moins que d’une technique déjà connue, laquelle présente des limites et qui est déjà implémentable par n’importe quelle solution. En analysant les documentations des principaux acteurs du marché, on constate également qu’ils ne poussent cette méthode qu’en dernier recours, si toutes les alternatives n’ont rien donné, car l’effet flicker varie pour chaque site et dépend beaucoup de leur performance initiale.

Alors en quoi consiste cette méthode ? Il s’agit de masquer temporairement l’affichage du contenu en ayant recours à une propriété CSS de type visibility: hidden ou display: none sur l’élément body. Cette propriété a pour effet de masquer le contenu de la page aussi rapidement que possible (pour peu que le tag de la solution soit placé dans la balise <head> de la page) puis à réactiver sa visibilité une fois que les modifications ont eu le temps de s’appliquer. Il n’y a donc plus d’effet flicker « avant/après ». Celui-ci est en revanche remplacé par un effet “page blanche/après”.

Le risque avec une telle méthode est que si la page rencontre le moindre problème de chargement ou que la méthode est mal implémentée, l’internaute peut se retrouver avec une page blanche pendant plusieurs secondes, voire bloqué sans aucun moyen d’action. Un autre inconvénient réside dans l’impression de lenteur que la méthode introduit. Il faut donc s’assurer que le blocage du rendu ne dure pas trop longtemps (quelques millisecondes) mais suffisamment pour laisser le temps aux modifications de s’appliquer. Et bien sûr, pour maintenir la validité de l’expérimentation, vous devez appliquer ce retardement d’affichage à la version de contrôle pour ne pas biaiser les comportements liés à une impression de vitesse différente.

Vous l’aurez compris, si vos modifications mettent du temps à s’appliquer, vous ne voudrez pas afficher une page blanche trop longtemps et devrez, au final, toujours vous en remettre aux bonnes pratiques présentées ci-dessous qui visent, elles, à accélérer l’application des modifications.

C’est pourquoi, chez AB Tasty, nous ne recommandons pas cette méthode pour la majorité de nos utilisateurs et ne la proposons pas par défaut. Elle reste toutefois facilement implémentable en utilisant un peu de code JavaScript.

Comment limiter l’effet flicker ?

Si vous ne souhaitez pas recourir à la méthode présentée ci-dessus, quelles solutions s’offrent à vous ? Voici les meilleures pratiques à suivre pour réduire cet effet et souvent y mettre fin complètement :

  1. Optimiser le temps de chargement de votre site en utilisant toutes les techniques disponibles : mise en cache des pages, compression, optimisation des images, utilisation d’un CDN, parallélisation des requêtes avec le protocole HTTP 2 …
  2. Placer le tag de la solution d’A/B testing le plus haut possible dans le code source, à l’intérieur de la balise <head> et avant l’appel à des ressources externes gourmandes (ex : web font, librairies JavaScript diverses et variées…).
  3. Utiliser la version synchrone du script AB Tasty, la version asynchrone augmentant les chances de flicker
  4. Ne pas utiliser un gestionnaire de tags pour appeler le tag de votre solution (ex : Google Tag Manager). Certes, c’est moins pratique mais vous pouvez facilement contrôler la priorité de déclenchement de votre tag.
  5. Ne pas insérer la librairie jQuery dans le tag de votre fournisseur si votre site y fait déjà appel. La majorité des solutions d’A/B testing côté navigateur repose sur jQuery. AB Tasty vous permet néanmoins de ne pas charger ce célèbre framework JavaScript si vous l’utilisez déjà par ailleurs. Ce sera autant de Ko à ne pas charger.
  6. Réduire la taille du script chargé par votre solution en supprimant les tests non actifs. Certaines solutions incluent dans leur script l’intégralité de vos tests, qu’ils soient en pause ou en draft. Chez AB Tasty, par défaut, seuls les tests actifs sont inclus, néanmoins, si vous avez de nombreuses personnalisations en cours, il peut être opportun de les passer en production de manière définitive et de les désactiver côté AB Tasty.
  7. Prêter attention à la nature des modifications apportées. Insérer plusieurs centaines de lignes de codes pour construire votre modification causera inévitablement plus d’effet flicker qu’une simple modification de style CSS ou de wording.
  8. Se reposer au maximum sur les feuilles de style. Il est souvent possible d’arriver à un même résultat visuel en utilisant des feuilles de styles. Par exemple, vous pouvez vous contenter d’une instruction JavaScript qui ajoute une classe CSS à un élément, cette dernière se chargeant de modifier son aspect, plutôt que plusieurs lignes de script qui manipulent le style de cet élément.
  9. Optimiser le code de vos modifications. En tâtonnant lors de la mise en place de vos modifications via l’éditeur WYSIWYG, vous pouvez ajouter sans le savoir plusieurs instructions JavaScript qui ne sont pas nécessaires. Analysez rapidement le code généré dans l’onglet “Edit Code” et optimisez-le en ré agençant ou en supprimant les parties inutiles.
  10. S’assurer que la solution utilisée fait appel à un (ou plusieurs) CDN pour charger le plus rapidement possible le script contenant vos modifications, quel que soit l’endroit où se trouve votre internaute.
  11. Pour les utilisateurs avancés : mettre en cache les sélecteurs jQuery en tant qu’objets pour ne pas avoir à retraverser le DOM à plusieurs reprises et/ou coder les modifications en JavaScript plutôt qu’en jQuery, notamment pour cibler les éléments par class ou id.
  12. Utiliser des tests par redirection dans la mesure du possible et si cela reste pertinent après avoir mis en relation la nature de la modification et le temps de mis en œuvre d’un tel test.

Si après avoir mis en place ces optimisations, vous constatez encore un effet flicker, vous pouvez vous résoudre à utiliser la technique consistant à masquer le contenu de la page tant que tous les éléments ne sont pas chargés. Si vous n’êtes pas sûr de comment vous y prendre, adressez-vous à notre support.