Quand on veut modifier ou optimiser des éléments sur sa boutique PrestaShop, on essaie en principe de faire appel à son bon sens et son intuition… En réalité, la meilleure méthode c’est de mesurer si le changement qu’on propose est efficace ou non.
C’est quoi un test A/B ?
Le principe est de montrer une page différente à l’internaute pour voir laquelle est la plus efficace… Par exemple on pourrait montrer à 50% des visiteurs la page standard et au 50% restant, la page modifiée pour voir laquelle est la plus efficace pour les ventes.
Concrètement cela peut s’appliquer sur n’importe quelle zone du shop… On peut par exemple avoir envie de mesurer si le bouton « Ajouter au panier » est plus efficace dans une couleur différente ou si un argumentaire de vente placé en dessous du bouton permet d’augmenter le taux de conversion.
Ensuite, le but est de mesurer sur le volume de commandes générées, si celles-ci proviennent d’internautes ayant vu la version A de la page ou la version B. En fonction des résultats, il sera possible ensuite de déterminer si oui ou non le changement doit être implémenté de manière définitive.
Faire de l’A/B test sur Prestashop sans plugin et sans service externe
Personnellement j’aime bien travailler avec la couche de base de PrestaShop et je me suis demandé s’il était concrètement possible de faire de l’A/B testing sans utiliser des services tiers… pour éviter d’investir de l’argent et du temps à apprendre à manipuler un nouvel outil.
Comme d’habitude, va construire un concept efficace avec des bouts de ficelles… Le principe est simple, on va dans le fichier de template TPL de PrestaShop vérifier si l’id_guest (identifiant du visiteur) est pair ou impair et grâce à cette technique on peut afficher une page différente en fonction de cet identifiant.
Ensuite, pour effectuer la mesure de l’efficacité on va préparer en back-office PrestaShop 2 requêtes SQL qui vont permet de connaitre à tout moment le nombre de commandes générées pour les visiteurs pairs ou impairs et voir quelle interface a mieux converti. Cette méthode de mise en oeuvre est certainement la plus courte et pertinente que j’ai pu trouver.
La bonne manière de procéder ? Effectuer un seul changement et attendre…
Avec la méthode que je vous propose, je vous conseille d’effectuer une modification à un emplacement précis / stratégique puis d’attendre… Pour obtenir un résultat fiable, il vous faudra un certain volume de commandes… si vous avez eu 1 ou 2 commandes difficile de trancher quelle est la meilleure interface.
En revanche, si vous avez eu 20 ou 30 commandes, vous allez déjà pouvoir vérifier quelle version a drainé le plus de ventes. Je conseille de faire un seul changement à la fois, sinon vous ne saurez pas quelle modification a eu l’impact sur vos ventes (ex. si vous faites un changement sur la fiche produit + sur la page de paiement).
Si le nombre de commandes avec la version A est presque équivalent à la version B, il faudra peut-être encore attendre un peu… Il est difficile de dire à une commande près si une interface est meilleure que l’autre. Vous pouvez donc laisser encore tourner le test quelques semaines avant de trancher.
Quel est le test A/B du jour que je vous propose ?
Ce que j’avais envie de montrer, c’est un exemple que tout le monde puisse tester sur sa boutique PrestaShop… Typiquement juste changer la couleur du bouton « Ajouter au panier », pour voir si la couleur d’un bouton peut favoriser l’interaction et les ventes.
Oui, mais pas que… juste en dessous du bouton, je vais par exemple ajouter un argument sur les frais de livraison qui sont toujours un gros frein en e-commerce. En l’occurrence dans la vidéo du jour, j’ajoute un texte mentionnant à partir de quel montant les frais de port sont offerts (ce qui peut provoquer un comportement différent côté perception client).
On peut imaginer une infinité de scénarios… par exemple d’afficher un bouton Whatsapp pour savoir si le fait de se montrer accessible et disponible influence la réassurance client… Ou même plus exotique, afficher votre photo dans le shop à des emplacements clés, indiquant que vous êtes disponible si le client a besoin de conseils.
Est-ce que je fais régulièrement des tests A/B avec mes clients ?
Certainement que vous allez rire… « Jamais ! »… Et là je vous propose un tutoriel sur quelque chose que je n’applique pas ? En fait sur beaucoup de boutiques de mes clients, la marge de progression est juste « énorme » il y’a beaucoup de sites e-commerce qui sont à l’état brut.
L’A/B testing est intéressant quand on a une boutique assez solide et déjà bien optimisée ou qu’on se pose une question fondamentale à laquelle on n’a pas la réponse. La plupart des sites e-commerce n’ont pas besoin d’aller jusque là, parce que les fondations sont encore trop fragiles.
Pourquoi faire de l’A/B testing quand vous avez un menu déformé ? Quand vos pages s’affichent mal ? Quand votre contenu est mal agencé ? Quand l’expérience mobile est freinante ? Vous l’aurez compris, bien souvent les fondamentaux sont à revoir… Bien souvent, on sait donc qu’il faut les corriger ces points, sans même faire un test utilisateur en amont.
Pour ce tutoriel PrestaShop vous avez à disposition :
- 1 x sql.txt (qui contient 2 requêtes pour la sélection des commandes)
- 1 x product-add-to-cart.tpl (pour faire un test A/B sur l’ajout au panier)
Résumé de la vidéo : Découvrir une méthode rapide pour faire de l’A/B testing sur PrestaShop
- Tout d’abord on fait un check dans Google pour se rendre compte que les outils d’A/B testing sont nombreux, mais demandent du temps de prise en main + un coût d’utilisation du service.
- Ensuite, on va directement modifier la page de la fiche produit (zone d’ajout au panier) et voir la différence d’affichage entre l’internaute A et le B.
- Puis en back-office on va tester l’exécution des requêtes SQL pour établir la mesure afin de savoir si c’est l’interface A ou B qui convertit le mieux.
- Assurez-vous toujours d’avoir un volume de données suffisant avant de prendre une décision définitive sur l’application du changement.
- Enfin réitérez l’expérience avec l’intégration d’une nouvelle modification via le test A/B chaque semaine / mois… (en fonction de vos objectifs)
Salut
Merci pour ce tuto très intéressant, par contre sur Prestashop 1.6 je n’arrive pas à récupérer id_guest dans le tpl via :
alors que j’arrive à récupérer id_customer par ex de la même manière :
Si quelqu’un à une piste ?
Merci
Hello,
Sur PrestaShop 1.6 j’ai pas eu l’occasion de faire le test mais peut-être qu’en faisant un
ou
permettra de vérifier dans la liste si la variable est présente.
À bientôt !
Merci de ton retour, j’ai vérifié sur la dernière version en 1.6 (1.6.1.24) et id_guest n’est pas présent en faisant un var_dump 🙁
Poudrant comme la table « ps_cart » est bien alimenté au niveau du champ « id_guest » je suppose qu’elle doit être présente sur les pages sous une autre forme que via getContext()->cookie
Si tu as une piste je suis preneur car j’aimerais vraiment pouvoir tester sur la 1.6
Merci
Bonjour,
L’idée est géniale et j’aimerais faire cela pour notre site, mais pour toute la page produit et non pas simplement pour l’ajout au panier.
Dans l’idée je souhaite dupliquer tous les fichiers tpl qui concernent la page produit afin de me faciliter la visualisation et les modifications de manière à garder les fichiers d’origines intact, et pour cela j’aimerais utiliser la variable {Context::getContext()->cookie->id_guest} en amont de ces fichiers, mais je n’arrive pas a trouver quel fichier gère cela. Pourtant il me semble avoir vu que les différents fichiers tpl sont appelé via un fichier « maitre » mais impossible de retrouver sa trace.
Avez-vous une idée?
Bonjour,
Il faudrait éventuellement tester l’approche du thème enfant cela permet de garder le thème original de PrestaShop intact : https://www.webbax.ch/2018/05/09/prestashop-1-7-theme-enfant-ep-52/
À bientôt !