Catégorie : A/B Testing

Article

12 Jan 2022
6min lecture

1,000 Experiments Club : entretien avec Lukas Vermeer de Vista

AB Tasty

AB Tasty

Pour lancer une dynamique d’expérimentation au sein d’une entreprise, Lukas Vermeer recommande de démarrer par de petits objectifs simples.

Lukas Vermeer a pris ce conseil très au sérieux lorsqu’il a plongé tête baissée dans le monde de l’IA et du machine learning aux premiers stades de leur développement, alors que la demande du secteur était encore faible. Par des missions de conseil auprès de diverses entreprises, Lukas a découvert son environnement de travail idéal : une scale-up , dans laquelle il pouvait mettre à profit son expertise en matière de données et de machine learning.

C’est là qu’intervient Booking.com. Lukas a rejoint l’agence néerlandaise de voyages en ligne en pleine phase d’expansion et a par la suite dirigé l’équipe expérimentation pendant 8 ans, faisant passer l’équipe de 3 à 30 personnes.

Une fois l’équipe expérimentation de Booking.com arrivée à maturité, Lukas s’est lancé dans une nouvelle aventure en 2021 pour rejoindre Vista en tant que directeur de l’expérimentation. Il construit et façonne la culture de l’expérimentation et exploite le potentiel des données pour renforcer l’impact de Vista en tant que leader dans le secteur des solutions design et marketing pour les petites entreprises.

Lukas a échangé avec Marylin Montoya, VP Marketing chez AB Tasty, à propos du processus et de la culture de l’expérimentation : depuis les méthodes jusqu’aux rôles des équipes impliquées dans l’expérimentation. Voici quelques éléments essentiels à retenir de leur conversation.

.

Expérimentez de manière stratégique

Il est primordial de connaître le but de votre expérimentation. Lukas conseille de concentrer ses efforts sur les tests de fonctionnalités majeures capables de générer un réel changement ou d’avoir un impact sur les résultats de l’entreprise, plutôt que sur le design de l’UI.

Demandez- vous : “Quelles grandes questions motivent actuellement votre business case ? Quelles sont les principales hypothèses sur lesquelles repose votre planification stratégique ?”, dit-il. Plutôt que d’augmenter la quantité d’expérimentations, il vaut mieux se concentrer sur des expérimentations plus importantes mais correctement exécutées.

Pour mettre en place une culture de l’expérimentation au sein d’une organisation, Lukas suggère d’utiliser la méthode de la flywheel. La première expérimentation doit attirer l’attention en divisant l’opinion des employés quant à savoir si elle fonctionnera. Cela démontre qu’il peut être difficile de prédire le succès des expérimentations soulignant ainsi “la valeur non-quantifiable de l’expérimentation”. Nous devons reconnaître que tout comme il est essentiel de ne pas livrer un mauvais produit (qui pourrait faire baisser les revenus), il est tout aussi crucial d’avoir une idée stratégique des investissements à réaliser à l’avenir.

Structurez votre organisation pour réussir vos expérimentations

La structure de votre entreprise et de vos équipes va jouer sur la fluidité de mise en œuvre de vos expérimentations. Le conseil de Lukas ? L’équipe développement de produits doit s’approprier complètement les expérimentations.

L’équipe expérimentation doit quant à elle faciliter les expérimentations en fournissant les outils, la formation et l’assistance technique à l’équipe développement de produits, qui pourra ensuite mener les expérimentations en toute autonomie.

En formant les product managers au processus d’expérimentation (en leur montrant par exemple les différents tests et outils à leur disposition, leurs points forts et leurs points faibles, les hypothèses à formuler et le bon moment pour les utiliser), ils peuvent tester leurs idées en toute autonomie et prendre une décision en s’appuyant sur un portfolio de méthodes expérimentales.

Toutefois, l’expérimentation revêt également un aspect social qu’il ne faut pas négliger. Au vu de la nature subjective de l’interprétation et de l’analyse de données, Lukas souligne l’importance d’un échange sur les résultats et d’un retour sur le processus d’expérimentation afin de l’optimiser.

“Tout l’intérêt d’une expérimentation (…) consiste à motiver une décision, et cette décision doit être appuyée par les preuves dont on dispose”, déclare Lukas. Tout comme les scientifiques soumettent leurs articles à des pairs avant publication, les expérimentations basées sur une méthode scientifique doivent suivre les mêmes lignes directrices en documentant dans le reporting l’hypothèse, la méthode, les résultats et les conclusions (une opinion partagée par Jonny Longden, invité du podcast 1,000 Experiments Club).

Le pire ennemi de la culture de l’expérimentation : leadership ou roadmaps ?

Dans le domaine du développement de produit, Lukas indique que lorsque l’on parle de “roadmaps”, il ne s’agit pas tout à fait de cela. Il s’agit plutôt d’une liste linéaire d’étapes qui sont censées permettre d’atteindre un objectif. Le problème, c’est qu’il n’y a pas souvent d’itinéraires bis ou d’alternatives si l’on s’écarte du plan initial.

Il n’est pas évident de changer de cap après une première expérimentation ratée, explique Lukas. Cela s’explique par le concept “d’escalade de l’engagement”, c’est à dire que plus vous investissez de temps et d’énergie dans quelque chose, et plus il est difficile de changer de cap.

Alors, est-il temps d’abandonner totalement les roadmaps ? Selon Lukas, elles devraient simplement servir à reconnaître l’existence d’une incertitude inhérente. Le développement de produit est rempli d’inconnues, et elles n’apparaissent que lorsque les produits sont conçus et montrés aux clients. C’est pour cela que le modèle construire-mesurer-apprendre fonctionne : parce que l’on avance de quelques pas avant de vérifier si l’on prend la bonne direction.

Lukas souligne que l’objectif ne devrait pas être de “livrer un produit finalisé dans deux mois” mais plutôt, d’intégrer l’incertitude aux livrables et d’énoncer l’objectif en conséquence. Par exemple, vérifier si les clients réagissent de la manière souhaitée.

Que pouvez-vous apprendre d’autre de notre conversation avec Lukas Vermeer ?

  • Quand expérimenter et comment bâtir une culture de l’expérimentation
  • L’importance de l’autonomie des équipes expérimentation
  • Les trois niveaux de l’expérimentation : méthode, conception, exécution
  • Comment accélérer le processus d’expérimentation
A propos de Lukas Vermeer

Lukas Vermeer est un expert de l’implémentation et de la mise à l’échelle de l’expérimentation, doté également d’une expérience dans le domaine de l’IA et du machine learning. Actuellement, Lukas est directeur de l’expérimentation chez Vista. Avant cela, il a passé plus de huit ans chez Booking.com où il a exercé les postes de data scientist et de responsable produit, avant d’être nommé directeur de l’expérimentation. Il continue de proposer son expertise en tant que consultant pour des entreprises qui commencent à intégrer l’expérimentation. Son tout dernier article coécrit “It Takes a Flywheel to Fly: Kickstarting and Keeping the A/B Testing Momentum,” aide les entreprises à débuter et à accélérer le processus d’expérimentation grâce à la flywheel “l’investissement suit la valeur,  qui suit l’investissement”.

A propos de 1,000 Experiments Club

Le 1,000 Experiments Club est un podcast produit par AB Tasty et animé par Marylin Montoya, VP Marketing chez AB Tasty. Rejoignez Marylin et l’équipe marketing alors qu’ils s’entretiennent avec les experts les plus compétents du monde de l’expérimentation pour découvrir leurs points de vue sur ce qu’il faut faire pour créer et exécuter des programmes d’expérimentation réussis.

Partager sur

LinkedIn Facebook Twitter

Article

1 Fév 2020
8min lecture

A/B Testing Côté Client et Serveur : le Meilleur des 2 Mondes Réuni !

Anthony Brebion

Anthony Brebion

Nous enrichissons notre plateforme d’optimisation des conversions d’une solution d’A/B testing server-side. Une nouvelle qui réjouira tous les férus d’expérimentation qui peuvent désormais tester n’importe quelle hypothèse, sur n’importe quel device.

Qu’il s’agisse de tester des modifications visuelles envisagées par votre équipe marketing ou des modifications avancées liées à votre back-office et indispensables à la prise de décision de votre équipe produit, nous vous proposons une solution adaptée.

Quelles différences entre A/B testing côté client et côté serveur ?

Les outils d’A/B testing “client-side” vous aident à créer les variations de vos pages en manipulant, dans le navigateur, le contenu qui est envoyé par votre serveur à l’internaute. La magie opère donc au niveau du navigateur (appelé “client” en informatique) grâce au langage JavaScript. A aucun moment, votre serveur n’est sollicité ou n’intervient dans ce processus : il renvoie toujours le même contenu à l’internaute.

Les outils d’A/B testing “server-side”, à l’inverse, déchargent votre navigateur de tout traitement. Dans ce cas, c’est votre serveur qui se charge de renvoyer aléatoirement à l’internaute une version modifiée.

4 raisons pour A/B tester côté serveur

Mener un test A/B côté serveur présente de nombreux avantages.

1. Dédié aux besoins de votre équipe produit

A/B tester côté client se résume parfois à des modifications de surface. Celles-ci concernent l’aspect visuel, comme l’organisation de la page, l’ajout / suppression de blocs de contenus ou encore la modification de texte. Si vous souhaitez tester des modifications plus profondes qui touchent à votre back office, comme la réorganisation de votre tunnel d’achat, les résultats de votre algorithme de recherche ou de tri produits, les choses se compliquent.

[clickToTweet tweet= »En A/B testant côté serveur, vous étendez le champ des possibles, en agissant sur tous les aspects de votre site, qu’il s’agisse du front ou du back-end. #abtesting #CRO » quote= »En A/B testant côté serveur, vous étendez le champ des possibles, en agissant sur tous les aspects de votre site, qu’il s’agisse du front ou du back-end. »]

Tout cela est possible car vous gardez la maîtrise du contenu retourné par votre serveur au navigateur. Votre équipe produit va se réjouir car elle fait un énorme bond en avant en termes de flexibilité. Elle peut désormais tester tous types de fonctionnalités et se doter d’une vraie approche data-driven pour améliorer sa prise de décision. La contrepartie de cette flexibilité est que le testing côté serveur nécessitera l’implication de votre équipe IT pour implémenter les modifications. Nous y reviendrons par la suite.

Votre équipe produit peut désormais tester tous types de fonctionnalités.

2. De meilleures performances

La dégradation des performances – temps de chargement ou effet flicker – se retrouve souvent en tête des reproches faits aux solutions d’A/B testing côté client.

Dans les cas les plus extrêmes, certains sites limitent l’ajout de tag JavaScript à leur seul pied de page pour éviter un éventuel impact sur leur performance technique. Cette politique exclut automatiquement le recours aux solutions d’A/B testing côté client, car un tag en “footer “ est souvent synonyme d’effet flicker.

En utilisant une solution d’A/B testing server-side, vous n’avez plus de tag JavaScript à insérer sur vos pages et restez maître de tous les goulots d’étranglement potentiels sur les performances de votre site. Vous êtes aussi garant de la politique de sécurité de votre entreprise et du respect des procédures techniques internes.

3. Adapté à vos règles métiers

Dans certains cas de figure, votre test A/B peut se limiter à des modifications de design mais vous êtes confrontés à des contraintes métier qui rendent difficile l’interprétation d’un test A/B classique.

Par exemple, un e-commerçant peut légitimement vouloir prendre en compte dans ses résultats les commandes annulées ou exclure les commandes extrêmes qui faussent ses analyses (notion de “outliers”).

Avec un test A/B côté client, la conversion est enregistrée dès qu’elle se produit côté navigateur, lorsque la page de confirmation d’achat est chargée ou qu’un événement de type transaction est déclenché. Avec un test A/B côté serveur, vous avez la maîtrise totale de ce qui est pris en compte et pouvez, par exemple, exclure en temps réel certaines conversions ou en enregistrer d’autres à posteriori, par lot.

4. De nouvelles opportunités omni-canal

Qui dit solution d’A/B testing server-side dit solution omni-canal et multi-device.

Avec une solution côté client – qui repose sur le langage JavaScript et les cookies – vous limitez votre terrain de jeu aux terminaux qui disposent d’un navigateur web, qu’il s’agisse d’une version desktop, tablette ou mobile. Impossible donc d’A/B tester sur des applications mobiles natives (iOS ou Android) ou sur des objets connectés, existants et à venir.

A l’inverse, avec une solution server-side, dès lors que vous êtes en mesure de réconcilier l’identité d’un consommateur quel que soit le device utilisé, vous pouvez délivrer des tests A/B ou des campagnes de personnalisation omni-canal dans une logique de parcours client unifié. Votre terrain de jeu vient soudain de s’agrandir 😉 et les opportunités sont nombreuses. Pensez objets connectés, applications TV, chatbot, beacon, digital store, …

L’A/B testing server-side, quels cas d’usage ?

Maintenant, vous vous demandez peut-être ce que vous pouvez concrètement tester avec une solution côté serveur que vous ne pouviez pas tester avec un outil côté client ?

Téléchargez notre présentation : 10 exemples de tests côté serveur que vous ne pourriez pas mener côté client.

Au programme : test de formulaire d’inscription, test de tunnel de commande, test d’algorithme de recherche, test de fonctionnalité…

Comment mettre en place un test A/B côté serveur ?

Pour mettre en place un test A/B côté serveur vous faites appel à notre API. Nous décrivons ici les grandes lignes de son mode de fonctionnement. Pour plus de détails, contactez notre support qui vous fournira une documentation technique complète.

Lorsqu’un internaute arrive sur votre site, vous interrogez notre API en lui passant en paramètre l’ID de visiteur, qui identifie ce dernier de manière unique. AB Tasty vous fournit cet ID que vous stockez (ex: cookie, session storage…). Si un visiteur possède déjà un identifiant lors d’une visite ultérieure, vous utilisez celui-ci.

Sur les pages où un test doit se déclencher, vous interrogez ensuite notre API en lui passant en paramètres l’ID du visiteur et l’ID du test en question. Cet ID de test est accessible depuis notre interface, lorsque vous créez le test. En réponse à votre requête, AB Tasty renvoie l’ID de variation à afficher. Votre serveur doit alors construire sa réponse en se basant sur cette information.

Vous devez également informer nos serveurs de collecte dès qu’une conversion a lieu, en passant un appel API avec l’ID de visiteur et des données relatives à cette conversion comme son type (action tracking, transaction, custom event…) et/ou sa valeur.

Nous mettons à votre disposition tout notre savoir faire pour l’analyse des résultats et l’optimisation de vos tests grâce à nos algorithmes d’allocation dynamique de trafic, qui répondent à la problématique dite du multi-armed bandit.

Vous l’aurez compris, mettre en place un test A/B côté serveur requiert l’intervention de votre équipe technique et implique un changement de mode organisationnel.

[clickToTweet tweet= »Alors que l’A/B testing côté client est géré et centralisé par votre équipe marketing, l’A/B testing côté serveur est décentralisé au niveau de chacune de vos équipes produits ou projets. » quote= »Alors que l’A/B testing côté client est géré et centralisé par votre équipe marketing, l’A/B testing côté serveur est décentralisé au niveau de chacune de vos équipes produits ou projets. »]

Faut-il se passer des tests A/B côté client ?

La réponse est non. L’A/B testing côté client et côté serveur ne sont pas antinomiques mais complémentaires. Les entreprises les plus performantes utilisent les deux conjointement selon leurs besoins et les équipes impliquées.

  • L’A/B testing côté client est facile d’accès, idéal pour les équipes marketing qui veulent agir en toute autonomie, sans avoir à solliciter leur DSI. Le maître mot ici est AGILITE. Vous pouvez tester rapidement beaucoup d’hypothèses.
  • L’A/B testing côté serveur s’adresse davantage aux équipes produits dont les besoins impliquent davantage de règles métier et sont étroitement liés aux fonctionnalités produits. Le maître mot ici est FLEXIBILITE.

En vous proposant le meilleur des deux mondes, AB Tasty confirme son rôle de partenaire incontournable pour tous vos besoins de testing et de prises de décision data-driven.

N’hésitez pas à nous contacter pour discuter de tous vos projets de testing, mêmes les plus fous.

Partager sur

LinkedIn Facebook Twitter

Article

12 Déc 2019
6min lecture

Le problème, c’est le choix : les limites de l’A/B testing

Hubert Wassner

Hubert Wassner

Qu’est-ce que la méthode d’A/B testing ? Il s’agit de comparer deux versions d’une même page web ou d’une application entre elles dans le but de déterminer la plus performante. Le principe de fonctionnement repose sur l’analyse statistique qui permet alors de définir quelle version est plus efficace selon l’objectif de conversion fixé. À quoi sert précisément l’A/B testing ? Dans quels cas particuliers l’appliquer ? Et pour quels résultats ? Tour d’horizon.

À qui s’adresse plus particulièrement l’A/B testing ? La méthode est principalement utilisée au sein des directions marketing des entreprises de toutes tailles, et de tous secteurs, en tant que technique d’optimisation du taux de conversion (Conversion Rate Optimization – CRO). Toutefois, la méthodologie n’est pas sans poser problème : en effet, les limites des analyses statistiques utilisées se retranscrivent sous forme de limites marketing.

Pour mieux comprendre, il est important de plonger dans les subtilités de l’A/B testing.

Le graal des spécialistes marketing : les décisions business basées sur l’A/B testing

Pour les directeurs Marketing, la prise de décisions a pour objectif d’accroître le chiffre d’affaires. Résultat, une majorité d’entre eux se creusent la tête pour répondre à ces questions :

  • Est-il nécessaire de diminuer le prix pour vendre plus ?
  • Ou, au contraire, les augmenter pour améliorer le panier moyen, au risque d’obtenir un taux de conversion inférieur ?
  • Les produits doivent-ils être classés par ordre de prix croissants ? Ou décroissants ?
  • Devez-vous élargir votre gamme de produits ou la restreindre ? Ou les deux ? Ou ne rien changer ?
  • Les promos de type « 3 produits achetés pour le prix de 2 » sont-elles un bon moyen d’augmenter votre panier moyen ?
  • Est-il préférable de proposer la livraison gratuite sans condition de dépenses ou à partir d’une certaine valeur de panier ?

Et si vous pouviez tester vos hypothèses business pour prendre la bonne décision ?
Malheureusement, les analyses statistiques utilisées aujourd’hui sont très limitées en termes d’interprétation des résultats.

Le principe de base de l’A/B testing

Pour rappel, le test consiste à exposer deux variantes de la même page (nommées A et B) à deux populations homogènes en séparant de façon aléatoire les visiteurs du site. Pour chaque variation, les donnés suivantes sont collectées :

  • Le nombre de visiteurs
  • Le nombre d’achats
  • La valeur du panier d’achat

Sur le papier, il devrait être relativement simple de définir quelle variation a généré le plus de revenus et, par conséquent, de déterminer quelle version est la plus performante. Néanmoins, comme n’importe quelle expérience sur le comportement humain, les données sont soumises au hasard. Résultat : si la variation B génère un panier moyen plus important que la variation A, cela ne signifie pas pour autant que B sera toujours meilleur que A.

La raison ? Difficile d’affirmer que la différence observée pendant un test sera répétée dans le futur. Voilà pourquoi les outils d’A/B testing utilisent des analyses statistiques pour qualifier les différences observées et identifier la variation la plus pertinente. Objectif : aider à séparer les données significatives des fluctuations aléatoires et imprévisibles qui ne sont pas corrélées aux différences entre les variations.

« Le problème, c’est le choix »

En e-commerce, la variation B peut être considérée comme la meilleure si elle génère :

  • Un gain de conversions : la variation amène à convertir plus d’achats
  • Un gain au niveau du panier d’achat moyen : le panier moyen de la variation B est supérieur à celui de la variation A
  • Un gain « mixte » : la variation B génère à la fois plus de conversions et un panier moyen plus élevé

Le gain de conversions

C’est la donnée la plus simple à analyser dans la méthode d’A/B testing. L’outil statistique utilisé : le test Bayésien. La caractéristique fonctionnelle la plus importante de ce test repose sur l’intervalle de confiance du gain de conversion mesuré.

Par exemple : on peut dire que la variation B produit un gain de 5 à 10 % – ce qui signifie que la variation B générerait entre 5 et 10 % d’achats supplémentaires par rapport à la variation A. Dans ce cas, il est facile de déterminer que la variation B est plus performante. Vous pouvez alors la valider en tant que « meilleure variation » et la proposer à l’ensemble de votre audience…

… Mais est-ce vraiment suffisant pour définir de façon définitive quelle est la variation la plus pertinente ? C’est ce que nous allons voir dans la suite de cet article.

Le gain de panier moyen

Cet indicateur est bien plus complexe à analyser. Les outils d’A/B testing utilisent le test Mann-Whitney U, également appelé Wilcoxon. Contrairement au test Bayésien, cette analyse ne fournit qu’une simple probabilité de gain sans préciser l’importance du gain. Par exemple, vous mesurez une différence de +5€ dans le panier moyen relatif à la variation B, ainsi qu’une probabilité de gain (donné par le test Mann-Whitney) à 98 %. Vous pourriez croire que ce gain de 5€ est sûr à 98 %, mais en réalité, il se peut que vous n’obteniez qu’un gain de +0,1€. L’analyse statistique a toujours raison : c’est un gain ! C’est simplement que le test Mann-Whitney ne prédit que l’existence du gain, pas de quel montant il sera !

Mais le pire est qu’une variation « gagnante » en termes de taille de panier moyen selon le test de Mann-Whitney pourrait en réalité générer moins de revenus, en raison de la présence de valeurs extrêmes qui faussent l’analyse. Comment l’éviter ? Une option pourrait être de supprimer ces valeurs avant d’analyser les résultats. Toutefois, il est à noter que cette solution n’en reste pas moins inévitablement biaisée : la variation la plus performante ne dépend que de la ligne « valeurs extrêmes » que vous aurez artificiellement définies.

Le gain mixte

Le moyen le plus efficace d’identifier la meilleure variation est de déterminer un gain significatif à la fois en termes de conversion et de panier moyen. En réalité, c’est même le seul cas où une décision peut être prise sans le moindre doute !

  • Vous observez un certain gain de conversion mais une perte de panier moyen → impossible de prendre une décision avisée car vous ne connaissez pas le montant de la perte, et ignorez si le gain obtenu va compenser cette perte.
  • L’analyse démontre une perte de conversions et un gain dans le panier d’achat moyen → même constat.
  • Perte ou gain indéfini dans le panier moyen → si vous ne connaissez pas l’évolution du panier moyen, impossible d’être sûr de la pertinence de la variation.

Ce dernier scénario représente la situation le plus courante. En effet, les statistiques liées au panier moyen nécessitent généralement plus d’informations que le taux de conversion afin de proposer une analyse pertinente.

Comme vous pouvez le constater, la majorité de tests A/B concluent à la certitude d’un gain de conversion. Mais sans information sur l’évolution du panier moyen, ces conclusions doivent être remises en question. On pourrait alors argumenter que c’est la raison pour laquelle on parle « d’optimisation du taux de conversion » plutôt que « d’optimisation business ».

Faut-il alors en conclure que l’A/B testing ne sert à rien ? Heureusement non ! Aujourd’hui, la plupart des tests A/B se concentrent sur l’expérience utilisateur, l’interface utilisateur et le design : couleurs, formulation, visuels, mise en pages d’un produit… En marketing, on parle de « réduire la friction du parcours d’achat », en d’autres termes, limiter le nombre de visiteurs insatisfaits et qui quittent le site sans avoir effectué le moindre achat.

Mais pour pouvoir aller plus loin que les tests basés sur l’ergonomie et s’attaquer aux vraies questions de marketing, nous avons besoin d’inventer le prochain test Mann-Whitney qui sera capable d’estimer la taille du gain ou de la perte générée par l’expérimentation. Voilà qui donnera définitivement un second souffle à l’A/B testing.

Revoir l’intervention de notre Chief Data Scientist, Hubert Wassner, et d’Aurélie Bastian, Manager Web Analytics et Conversion de Sutter Mills, à l’occasion de Digital Innovation 2019.

Partager sur

LinkedIn Facebook Twitter

Article

28 Juil 2019
4min lecture

Avant de tester, établissez votre roadmap

Anthony Brebion

Anthony Brebion

Quels tests lancer ? Dans quel ordre ? Comment éviter les conflits entre plusieurs tests ? Quels sont les risques et comment les minimiser ? Avant de vous lancer, voilà les questions qu’il faut se poser ! Suivez nos conseils pour établir votre roadmap de test.

Avant de commencer votre testing, il faut baliser votre chemin. Pour être au clair sur vos objectifs, définir vos priorités et anticiper les risques mais aussi fixer un calendrier, la feuille de route est un outil indispensable. Elle vous permettra de suivre l’avancement de votre projet et de tenir l’ensemble de vos contributeurs informés et impliqués (nous vous proposons un modèle en format Excel, prêt à l’utilisation).

Votre feuille de route doit (notamment) comprendre les 8 éléments suivants :

1 – Nom des tests

Veillez à donner des noms précis et explicites à vos tests (de préférence identiques à ceux utilisés dans l’outil AB Tasty). On préfèrera par exemple un titre court et explicite « [HP]wordingCTA » à une phrase entière : « Test sur le wording du CTA de la Page d’Accueil ».

2 – Description des tests

Afin que l’ensemble des contributeurs soient associés à la démarche de testing et puissent suivre l’évolution du processus, une description courte mais explicite est à privilégier. Par exemple, la formulation « Modification du wording du CTA ‘Je m’inscris’ par ‘Je m’abonne’ » permet à n’importe qui de comprendre la teneur et les enjeux du test.

3 – Niveau de priorité des tests

Il est indispensable de hiérarchiser vos tests par degré d’importance afin de déterminer leur ordre de développement et de lancement. Pour cela, à vous d’apprécier :

  • les bénéfices espérés pour le test
  • la difficulté technique du test

Après les premiers résultats des tests, vous pourrez ajuster votre hiérarchisation pour plus d’efficacité et optimiser votre testing.

4 – Périmètre testé

Autre information essentielle à consigner dans votre feuille de route : le périmètre testé. Cela vous permettra d’éviter les conflits (plusieurs tests lancés au même moment sur la même page) ou les possibles effets de bords. Pour cela, nous vous conseillons de découper l’architecture de votre site en grands ensembles et de leur associer une couleur dans votre feuille de route. Par exemple : bleu pour la page d’accueil, orange pour les pages listes, vert pour les pages produits, jaune pour le tunnel, etc.

5 – KPI primaires et secondaires

Pour chaque test, il convient de définir a priori un indicateur clé de performance (KPI) primaire (ou objectif de macro conversion). Cet indicateur, qui a motivé la création du test, vous permettra d’en évaluer les bénéfices. Il peut s’agir du nombre de clics sur le bouton d’ajout au panier, du nombre d’inscriptions à la newsletter, du chiffre d’affaire généré…
Il faut également définir des KPIs secondaires (ou objectifs de micro conversion), des indicateurs apportant des compléments d’analyses et permettant d’affiner l’information apportée par les résultats du KPI primaire récoltés durant le test. On peut citer à titre d’exemple le temps passé sur le site, le nombre de pages vues, le taux de rebonds…

6 – Ressources nécessaires

L’implémentation de certains tests peut nécessiter…

  • des développements techniques
  • des développements ergonomiques
  • un lancement à une date spécifique

qu’il est important de préciser dans votre feuille de route.

7 – Date de lancement et de fin estimée du test

Cette information permet de donner de la lisibilité aux équipes quant aux retours qu’ils pourront faire à leur hiérarchie ainsi qu’aux éventuels prochains lancements de tests. Parallèlement cela permet également de mettre en place un rétroplanning précis de l’activité testing.

8 – Possibles effets de bord / Personnes à contacter / Alertes

Il s’agit ici d’aménager un espace d’annotation et de commentaires, qui vous sera utile en cas de problèmes. Notez les contacts et informations utiles, les personnes à alerter, des points d’attention à ne pas oublier… cela vous permettra de gagner beaucoup de temps (et de vous éviter quelques frayeurs !)

Partager sur

LinkedIn Facebook Twitter

Article

25 Sep 2018
8min lecture

Le modèle LIFT : trouvez des hypothèses de tests par typologie de pages

AB Tasty

AB Tasty

Nous avons vu comment trouver des hypothèses de tests grâce à vos données, puis grâce à l’UX et l’UI. Voyons maintenant comment trouver des idées par typologie de pages.

Au quotidien, nous réfléchissons toujours à des hypothèses de tests en travaillant méthodiquement par type de page. Chaque page a son propre objectif, ses enjeux et ses codes. En tant qu’expert du CRO, nous nous appuyons sur les meilleures techniques pour trouver des hypothèses de tests toujours plus pertinentes. Voyons comment procéder avec la méthode par typologie de pages !

Qu’est-ce que la proposition de valeur ?

Votre proposition de valeur est une formule coût / avantages évaluée inconsciemment et automatiquement dans l’esprit de votre client potentiel lorsqu’ils rencontrent votre interface digitale (site web, landing page, etc). C’est un élément crucial. Considérez-la comme une équation entre les avantages et le coût : si les avantages perçus l’emportent sur le coût perçu, alors vos prospects seront prêts à convertir !

En moins de 5 secondes, l’utilisateur doit être capable de comprendre votre proposition de valeur. Elle doit être claire, compréhensible et pertinente sur vos pages.

Pour convertir, il faut que la proposition de valeur réunisse quelques caractéristiques que Chris Goward a développé (et breveté !) dans ce qu’il a appelé “Le Modèle LIFT”.

Le Modèle LIFT

Le Modèle LIFT (Landing Page Influence Function for Tests) est un modèle d’optimisation des conversions basé sur 6 facteurs de conversion qui vous permettent d’évaluer les pages de votre interface du point de vue du visiteur.

“Le Modèle LIFT consiste à vous mettre dans la peau du client potentiel et à proposer des idées qui répondront à leurs besoins.”
– Chris Goward, Founder & CEO, WiderFunnel

Ce schéma représente bien cette méthode. Pour atteindre le niveau supérieur – les conversions – c’est le travail d’un ensemble de facteurs et une proposition de valeur forte. Chris Goward décrit la proposition de valeur comme « l’ensemble des avantages et des coûts perçus, dans l’esprit du client potentiel, au moment de mener une action ». Lorsque la proposition de valeur dépasse les coûts, les utilisateurs sont prêts à convertir.

Mais avoir une bonne proposition de valeur ne suffit pas. Elle doit être pertinente et clairement énoncée, sans distractions ou éléments anxiogènes.

Votre travail consiste donc à améliorer les aspects positifs tout en réduisant les points négatifs.

 

Léa Benquet, CSM chez AB Tasty

 

Maintenant que nous avons vu ce qu’est la proposition de valeur d’une page, voyons comment activer méthodiquement les autres leviers pour élaborer des hypothèses de tests pertinentes.

En pratique

Pertinence

Etat Pur a souhaité mettre en avant la pertinence de sa proposition de valeur en proposant du contenu à forte valeur ajoutée. Sur la version originale, nous pouvons distinguer deux blocs : le premier présente la formule personnalisée avec une offre de 20% sur les premiers soins, le second présente l’innovation et les bénéfices d’avoir des produits personnalisés en fonction de sa peau.

L’équipe digital d’Etat Pur a testé une variation en inversant les deux blocs pour une lecture plus logique : d’abord l’explication, ensuite l’offre.

L’inversion des blocs sur la homepage a permis d’augmenter les transactions de 9%.

Clarté

Bien que la page produit sur le site web de Princesse TamTam soit déjà épurée et compréhensible, l’équipe digitale de la marque savait qu’il était possible de donner encore plus de lisibilité à ces pages.

Pour plus de clarté, elle a opté pour la simplification de la page produit. En cachant la description du produit (passée au format onglet), la fiche produit n’affiche que l’essentiel et rend ainsi le CTA plus visible.

Ces améliorations ont permis de maximiser les clics sur le CTA de + 12%.

Distraction

Quand nous passons d’un écran d’ordinateur à celui d’un smartphone, les informations sont perçues autrement. Ünkut l’a bien compris et a voulu tester l’optimisation du CTA selon le device.

Sur mobile, l’internaute était obligé de scroller pour découvrir le CTA sur les fiches produits – et donc passer à l’action. De plus, beaucoup d’informations sont disponibles avant le CTA, ce qui peut être source de distraction pour le visiteur.

L’équipe digitale de la marque a déployé une variation avec un CTA fixe au scroll, ce qui a permis d’augmenter de 55% les clics sur ce CTA et de manière générale les transactions de 7%.

Anxiété

La marque agnès b. avait identifié un point de friction chez les consommateurs d’agnès b. durant leur parcours d’achat. Supprimer l’anxiété dans le parcours d’un acheteur permettrait-il réellement d’augmenter les ventes ?

C’est ce que l’équipe digitale a voulu tester en maximisant la visibilité des éléments de réassurance dès la page produit.

En précisant que la livraison est offerte dès 250 € et que les retours sont gratuits sur la fiche produit, les internautes se sentent rassurés. Et grâce à ça, les transactions ont doublé.

Urgence

Les techniques de stress marketing peuvent être très utiles, à condition qu’elles soient bien utilisées. Attention, trop de messages d’urgence peuvent rapidement créer un contexte anxieux !

BrandAlley a utilisé cette technique pour inciter l’internaute à prendre une décision plus rapidement. En affichant que le produit consulté n’est bientôt plus disponible, le produit devient alors rare et donc encore plus désirable. Il faut agir vite !

Une technique efficace qui a augmenté le taux de transactions de 4% sur le site de BrandAlley.

Le modèle LIFT est aussi simple que puissant : une fois que vous aurez maîtrisé ces 6 facteurs, vous serez en mesure de les appliquer dans un contexte précis et ainsi maximiser vos conversions. Ce modèle nous permet de mettre en lumière une chose très importante : se mettre à la place de l’internaute. C’est uniquement en voyant votre site, vos pages ou vos landing pages sous un autre oeil que vous serez en mesure de les optimiser davantage.

De nombreux clients nous demandent ce qui ne va pas dans leurs tests précédents, pourquoi ils n’ont pas fonctionné autant qu’ils espéraient ? Dans chaque cas, nous utilisons cette méthode pour évaluer les différents types de pages et ainsi, développer des hypothèses de tests fiables et adaptées à un contexte très précis. Conversions garanties 😉

 

Guillaume Le RouxGuillaume Le Roux, CSM chez AB Tasty

 

Partager sur

LinkedIn Facebook Twitter

Article

21 Sep 2018
7min lecture

UX & UI : notre méthode infaillible pour trouver des hypothèses de tests

AB Tasty

AB Tasty

Nous avons vu dans notre précédent article qu’en moyenne 80% des campagnes lancées génèrent des résultats neutres. C’est-à-dire ayant un résultat ni positif, ni négatif. Comment tirer profit d’un test au résultat neutre ? Honnêtement, c’est très compliqué quand les chiffres ne parlent pas d’eux-mêmes …

Au-delà d’avoir des résultats inexploitables, votre stratégie d’acquisition perd tout son intérêt. Attirer du trafic sur votre site, sans leur proposer une interface adaptée et en lien avec leur besoin, revient à jeter l’argent par les fenêtres !

Pour consacrer votre temps et vos ressources uniquement sur des tests ROIstes, nous avons quelques méthodes pour trouver des hypothèses de tests fiables. Après l’étude de vos données analytiques pour trouver des idées de tests, voici notre méthodologie par l’UX et l’UI.

Qu’est-ce que l’UI et l’UX ?

Pour expliquer simplement et de façon imagée la différence entre l’Interface Utilisateur et l’Expérience Utilisateur, prenons ces deux bouteilles de ketchup :

D’un côté, le packaging a été conçu de façon classique, en respectant les normes d’utilisation – avec une ouverture par le haut. Il s’agit d’une conception purement orientée “produit” : c’est ce que l’on appelle l’Interface Utilisateur (UI).

Mais l’expérience utilisateur est une tout autre histoire !

De l’autre côté, nous avons un packaging totalement différent mais qui prend en compte l’utilisation du produit : l’ouverture se trouve en bas pour éviter au consommateur de retourner le contenant lorsqu’il l’utilise. C’est particulièrement désagréable de devoir attendre que le liquide descende jusqu’au goulot. Il s’agit ici d’une conception qui prend en compte les normes liées au produit mais aussi les besoins utilisateurs : on appelle ça l’Expérience Utilisateur (UX).

Dans le deuxième exemple ci-dessus, l’UX Designer a étudié les usages et les comportements de sa cible afin d’adapter son produit aux besoins. Et cela donne un produit parfaitement cohérent. Sur votre site web c’est pareil : pour concevoir une expérience utilisateur adaptée, il faut étudier les usages !

Léa Benquet, CSM chez AB Tasty

 

Comprendre les usages sur un site web ou mobile

L’UX, c’est l’étude et l’optimisation du ressenti d’un utilisateur lorsqu’il est confronté à une interface digitale. On va observer, analyser et comprendre l’usage pour adresser à l’internaute l’interface qui va répondre à ses besoins.

En réalité, quand on commence à s’intéresser aux usages autour d’une marque ou d’un produit, c’est beaucoup plus large qu’on ne le pense ! Pour la SNCF, par exemple, l’Expérience Utilisateur commence sur un site web quand on achète son billet de train et se termine lorsqu’on sort du train à destination. Dans ce cas – et comme dans beaucoup d’autres – il y a énormément de points de contact d’où la difficulté de mesurer un ROI sur l’Expérience Utilisateur.

L’UI pourrait se résumer à l’organisation des éléments graphiques et textuels pour proposer une interface attrayante. L’addition est simple : usage + ergonomie = conversions.

On comprend facilement avec cet exemple ce qu’il se passe quand on conçoit un produit sans avoir analysé son usage, son besoin :

Sur un site web ou mobile, c’est la même chose ! Si une interface est mal pensée, pas adaptée, ne répond pas à un besoin ou si elle est tout simplement pas compréhensible, l’utilisateur va s’en détourner complètement. Ce qui donnera des taux de rebond ou de sortie élevés.

Commencer à optimiser avec une démarche UX

Pour commencer votre démarche UX, la première étape est de s’interroger : est-ce que les éléments sur la page ont un intérêt ou non ? Et plus spécifiquement, à ce niveau du parcours ? Une fois que vous avez acté sur leur intérêt, vous pouvez passer à la deuxième étape : jouer sur l’UI pour trouver le bon design de chaque élément.

En d’autres termes, tester la nécessité d’un élément avant de déterminer son design. L’inverse est totalement contre productif – tester des changements de couleurs sur des éléments inutiles, cela vous conduit à des tests toujours neutres car c’est la présence de cet élément qui n’est pas utile pour les users.

Quelques exemples concrets

UX – Épurez votre page panier

Princesse TamTam a identifié quelques éléments inutiles sur sa page panier comme le footer, des éléments de cross-sell et l’inscription à la newsletter. Les équipes ont voulu tester une variation simplifiée de la page pour éviter les points de fuite et focaliser l’internaute sur son objectif – valider son panier.

En supprimant ces éléments, l’internaute repère plus rapidement et facilement les points de rassurance qui peuvent être déterminants dans sa décision d’achat. Les résultats parlent d’eux-mêmes : + 130% clics sur le CTA “poursuivre” et + 4% de transactions.

UI – Créez un CTA au design rassurant

Autre exemple avec le site L’Argus, qui a souhaité optimiser son CTA d’ajout au panier. Initialement le CTA était le prix du véhicule. Il s’agit évidemment d’un élément indispensable mais d’un point de vu UI, le contenu et la couleur rouge du CTA n’invitaient pas l’internaute à cliquer. En dissociant le prix du CTA, le taux de clics a bondi de +574% sur le CTA.

Le contenu “voir le détail” couplé à la couleur verte du bouton, ce CTA semblait moins engageant pour l’internaute et donc plus rassurant. Ce qui insiste forcément le taux de clics.

L’a/b testing va permettre de tester des changements afin d’optimiser le site web ou l’application mobile en se basant sur les besoins cachés des utilisateurs. Evidemment, les utilisateurs eux-mêmes ne sont pas toujours en mesure de prendre du recul sur une interface pour y apporter des recommandations claires et précises.

C’est tout l’enjeu de l’UI et de l’UX : comprendre le besoin du client en observant et en analysant son comportement on-site.

Guillaume Le RouxGuillaume Le Roux, CSM chez AB Tasty

 

Partager sur

LinkedIn Facebook Twitter

Article

17 Sep 2018
9min lecture

Comment trouver des hypothèses de tests pertinentes grâce à vos données?

AB Tasty

AB Tasty

Nos Customers Success Manager sont des experts du CRO, et ils accompagnement chaque jour nos clients dans le déploiement de leur stratégie d’optimisation. Le CRO est une méthode d’optimisation complexe qui suit différentes étapes cruciales. Le testing est l’une de ces étapes et va permettre de valider des hypothèses d’optimisation avant de les mettre en production.

Chez AB Tasty, nos CSM voient se lancer en moyenne 240 tests par jour et malgré les bonnes idées d’optimisation de nos clients, ils ont fait un constat très révélateur : sur 10 tests lancés, seulement 2 auront un impact significatif (positif ou négatif). Ce qui veut dire qu’en moyenne, 80% des campagnes mises en place génèrent des résultats neutres. En bref, un résultat neutre signifie que vous n’avez pas rentabilisé votre stratégie d’acquisition, que vous n’avez pas tiré profit du trafic de votre site. L’hypothèse de départ issue du test n’était peut être pas appropriée. Alors comment trouver des hypothèses de tests pertinentes ?

“Methodology is More Valuable than Tips”

– Chris Goward

Pour trouver de vraies hypothèses et lancer des tests qui auront un impact, il n’y a pas de recette magique. Nous allons vous livrer 3 méthodes, à travers une série d’articles, pour booster l’impact de vos tests. Commençons par la première méthode : l’étude de vos données analytiques.

Ce que vos données essayent de vous dire

L’idée est de vous proposer quelques conseils pour savoir ce qu’il faut regarder en priorité dans vos données analytiques pour aller chercher des insights pertinents lors de prochains tests.

 

Pourquoi étudier vos données ? Tout simplement parce que c’est une mine d’informations concernant vos internautes, leurs habitudes, leurs préférences et surtout comprendre comment ils naviguent sur votre site et interprètent vos messages. C’est ici que vous dégagerez les meilleures hypothèses de tests adaptées à vos problématiques business, votre interface et votre audience.

 

Léa Benquet, CSM chez AB Tasty

 

 

Identifier les devices prioritaires

Parmis les premières données à observer, vous avez les devices utilisés par vos internautes. Savoir sur quel device votre audience consulte votre site est une information capitale ! Ces données pourront vous aider à connaître les habitudes de vos clients et sur quels devices concentrer vos efforts d’optimisation.

exemple de données par device

Si vous découvrez qu’ils utilisent majoritairement leurs ordinateurs, il est judicieux de vous pencher sur des pistes d’optimisation sur ce device car le trafic y est conséquent et qualifié si les taux de transaction y sont également les plus élevés. En revanche, il sera également intéressant d’aller dégager des axes d’optimisation sur les devices les moins utilisés sur lesquels des points bloquants doivent persister. Le manque à gagner y est sans doute conséquent.

AB Tasty vous permet en quelques clics de mettre en place des tests ou des campagnes de personnalisation sur chaque device grâce à un user agent intégré à l’éditeur et des ciblages natifs par devices.

En pratique

La Poste a découvert que de nombreux internautes utilisent leur mobile pour consulter leur site. Et que depuis leur smartphone, ils avaient du mal à voir les images sur les fiches produits. L’interface n’avait pas été pensé pour eux !

Ils ont lancé un A/B Test sur mobile avec une variation où les images seraient agrandies sur les pages produits. Cette variation a permis d’augmenter le nombre de clics sur le CTA “ajouter au panier” de 3% et les transactions de 9%.

Identifier les rayons prioritaires

Les pages de votre site avec le moins bon taux de transformation ont une marge d’amélioration importante. Ce sont des leviers de croissance à ne pas manquer. Pourtant, la plupart du temps, nous passons à côté de cette opportunité car nous avons tendance à penser qu’une page qui ne convertit pas ou qui affiche un mauvais taux de transformation est moins importante, moins prioritaire, ne représente aucune valeur. Mais c’est faux !

exemple de données de transformation de panier

Dans notre exemple ci-dessus, il s’agit de données d’un site e-commerce. Nous constatons à travers ces données que les internautes ont tendance à ajouter des articles au panier mais ne vont pas jusqu’au bout de leur acte d’achat. Nous pouvons alors réfléchir à optimiser ces pages : il y aurait-il une confusion dans le choix des tailles ? Un manque d’élément de réassurance ? Un manque de photos inspirantes ? Déjà beaucoup d’hypothèses de tests à explorer.

En pratique

Malgré un prix plus bas en période creuse, MSC Cruises a constaté que les internautes ne parvenaient pas concrétiser leur achat. Pour maximiser son taux de transformation notamment sur des catégories à forte valeur ajoutée, MSC Cruises a alors souhaité tester l’affichage du prix de ces croisières.

En effet, le prix des croisières peuvent varier selon les périodes (en fonction des saisons, des vacances scolaires, etc). L’idée était d’afficher le prix maximum à côté du prix actuel pour la croisière SEASIDE lorsque celui ci est moins élevé que le prix de base (lead management). Ici en période creuse, le prix est forcément moins cher que si nous étions en pleine saison !

Ainsi représenté, le prix actuel est perçu comme une affaire pour les internautes. Ce qui a permis d’augmenter les transactions de 20% sur cette catégorie de croisière et les revenues de +10% pour MSC Cruises.

Identifier les principales pages de sortie du site

Les données comme le taux de sortie ou le taux de rebond sont très importantes pour identifier les points faibles de votre site. Sur un parcours d’achat ou de conversion de manière générale, votre internaute sera confronté à plusieurs étapes. Chaque étape doit le rassurer dans son choix. Il doit se sentir confiant et en sécurité tout au long de son parcours, de la page article jusqu’au paiement.

Il suffit juste de trouver le gap qui vous fait perdre vos clients potentiels et dégager des axes d’amélioration prioritaires sur ces pages où le trafic se perd. Vos données peuvent vous aider dans cette quête !

En pratique

BDV a utilisé le Session Recording pour identifier ce gap dans son tunnel de conversion. Observer ses internautes a permis à notre client de faire un constat intéressant : le scroll (le fait de faire défiler la page du site) de la page panier était très étendu. Nous avons remarqué de fréquents allers et retours des internautes entre le haut de page et le bas de page pour vérifier leur panier avant de valider.

Ces vidéos ont permis de dégager une nouvelle hypothèse de test pertinente : tester un module panier fixe au scroll pour simplifier la navigation des internautes sur cette page de paiement clés, qui s’est avéré particulièrement probant !

Vos données peuvent vous en apprendre bien plus que ce que vous pensez ! Dans ces exemples, nos clients ont pu identifier des pistes d’optimisation fiables grâce à leurs propres données.

 

Sans ces précieuses informations, est-ce que La Poste aurait eu l’idée d’agrandir les images de ses fiches produits sur mobile ? Et chez MSC Cruises auraient-ils mené un A/B Test sur les croisières en période creuse ? Peut-être qu’ils auraient mené 8 tests avant d’arriver à ce résultat. Sans aucun doute, cette méthode leur a fait gagner du temps et de l’argent.

 

Guillaume Le RouxGuillaume Le Roux, CSM chez AB Tasty

 

Vos données sont une mine d’or à exploiter pour trouver des idées de test. Elles vont mettre en lumière des évidences dont vous ne soupçonnez peut être pas la force. Cette méthode a fait ses preuves auprès de nombreux clients comme La Poste, MSC Cruises et BDV pour mener des tests avec un réel potentiel.

Il n’y a pas de bonne ou de mauvaise hypothèse de test. L’objectif ici est plutôt d’éviter de perdre du temps et de l’argent à déployer des tests sans grand intérêt pour votre site. Pour cela, il faut travailler des hypothèses de tests pertinentes en étudiant vos données pour proposer des axes d’amélioration cohérents avec vos problématiques, votre secteur, les particularités de votre site et surtout celles de vos internautes.

L’étude de vos données analytiques est une de nos premières méthodes pour booster l’impact de vos tests. Découvrez nos 2 autres méthodes dans nos prochains articles !

Partager sur

LinkedIn Facebook Twitter

Article

14 Sep 2018
8min lecture

Server-Side Testing : Définition, Avantages et Exemples

AB Tasty

AB Tasty

AB Tasty a récemment mis à la disposition de ses clients une version Beta du Server-Side Testing. Cela ouvre un nouveau monde des possibilités de tests – mais cela nous a aussi fait comprendre que tout le monde n’est pas vraiment familier avec les tests server-side, quand sont-ils utiles et comment ils peuvent être pleinement exploités ?

Alors, voici un bref récapitulatif pour ceux d’entre vous qui s’interrogent encore sur le Server-Side Testing !

Les tests Server-side et client-side

Avant de nous lancer dans la définition et les explications, reprenons la terminologie. Nous avons fait le choix de ne pas traduire ces termes, pour ne pas rentrer dans des confusions de langues !

Si vous utilisez une solution SaaS d’optimisation de site web (comme AB Tasty), vous connaissez déjà les solutions de test server-side et test client-side.

Les tests client-side signifient simplement que les modifications liées à l’optimisation du site ne se produisent que dans le navigateur du visiteur, c’est-à-dire du côté du client. Pour faire cela, vous n’avez pas nécessairement besoin de connaissances en matière de développement web. C’est d’ailleurs une de nos promesses chez AB Tasty ! Même si parfois la connaissance de HTML, JS ou CSS peut être utile.

C’est l’une des principales choses à retenir sur les tests client-side : l’interface web est la salle de contrôle de vos tests et tous les scripts sont exécutés sur les navigateurs de vos visiteurs.

Image Source

Cependant, la facilité d’utilisation des tests client-side – peu ou pas de développement web nécessaire – comporte également des inconvénients. À savoir, le scope de vos tests reste largement lié au design : changement de couleur, contenu, mise en page, suppression ou ajout d’éléments, etc.

Avec les tests client-side, le scope de vos tests reste largement lié au design : changement de couleur, contenu, mise en page, suppression ou ajout d’éléments, etc.

Pour certaines entreprises, c’est très bien et déjà suffisant. Il existe d’innombrables idées de test que vous pouvez déployer en client-side, mais après un certain temps, beaucoup veulent aller plus loin. C’est là que le test server-side entre en jeu.

Client-Side Server-Side
Marketing + Tech Tech + Marketing
Agilité et Réactivité Scénarios avancés et Restrictions
WYSIWYG + HTML/CSS/JS Code / App Implementation
Contenu, UI et UX Fonctionnalités et Logique Business
Web Technologies Plateforme et Language Agnostique

Des tests plus riches avec le Server-side

Dans un certain sens, les tests server-side suppriment les solutions intermédiaires (le tag AB Tasty est utilisé pour les tests client-side). A la place d’une solution, les développeurs peuvent utiliser directement le code et accéder directement aux sources, ainsi travailler sur les serveurs qui vont charger le site sur le navigateur de l’utilisateur final. Les équipes Marketing peuvent toujours définir les paramètres d’un test dans l’interface AB Tasty, mais toute l’implémentation se fait au niveau du serveur web.

Les campagnes client-side et server-side sont définies dans la même interface AB Tasty. Dans la capture d’écran ci-dessus, vous pouvez définir vos variations, vos objectifs ainsi que l’allocation du trafic (dynamique ou non). Oui tout ça dans la même interface ! Le design des variations est l’étape juste après.

Nous générons les identifiants associés et fournissons à vos développeurs des instructions pour prendre en charge votre implémentation.

Étant donné que l’implémentation des tests server-side est plus directe, cela permet des tests et des campagnes d’optimisation beaucoup plus riches.

Cependant, le fait est que pour implémenter des tests server-side il est indispensable de maîtriser les langages de back-end, tels que PHP, Node.js ou Python. Si c’est votre équipe marketing qui exécute votre stratégie CRO, elle est peut-être déjà accompagnée d’un développeur web. D’autres peuvent chercher à embaucher ce profil en freelance. Quoi qu’il en soit, si vous souhaitez démarrer avec des tests server-side, vous allez avoir besoin de deux choses :

  • Un accès au code source de votre site web
  • Un développeur compétent pour configurer et gérer les campagnes server-side

Les avantages et les limites

Entre les tests client-side et server-side, il n’existe pas une méthode mieux que l’autre – les deux ont leur place dans une stratégie CRO. Il s’agit de choisir ce qui convient à votre entreprise en fonction de vos ressources et de vos objectifs. Très souvent, vous voudrez utiliser les deux techniques à la fois.

Les avantages du client-side testing

  • Simple et rapide à lancer ou à complexifier
  • Pas besoin d’avoir des connaissances en développement web (les équipes marketing ne sont pas dépendantes des équipes techniques)
  • Toutes les données de test stockées dans une interface SaaS claire et lisible

Les limites du client-side testing

  • La portée des tests est de nature « esthétique » (forme, couleur, configuration)
  • Difficile ou impossible d’impliquer plusieurs canaux (desktop, mobiles, IoT…)

Les avantages du server-side testing

  • Test complexe, riche
  • Omnicanal

Les limites du server-side testing

  • Des compétences en développement web sont indispensables
  • Les équipes marketings sont moins autonomes

Avec AB Tasty, vos tests server-side bénéficieront des mêmes avantages que les client-side : reporting riches, statistiques bayésiennes fiables et algorithme d’allocation dynamique du trafic vous permettant d’optimiser au maximum chaque visite sur votre site.

Quelques exemples de tests server-side

Mais, le server-side testing vaut-il l’investissement ? Cela dépend de vos ressources, de vos objectifs et de votre niveau de maturité. Certains des exemples suivants illustrent à quel point les tests server-side peuvent être puissants :

Passer du “freemium” au “premium” en douceur

Les entreprises qui proposent une version gratuite de leur produit savent qu’à un moment donné, elles vont devoir commencer à facturer ces services aux clients. La question est, à quel moment exactement ?

C’est la question que se posait AlloVoisins, un site web français d’échanges de services entre voisins. Grâce à la solution server-side d’AB Tasty, ils ont pu effectuer un test d’un mois pour déterminer combien d’annonces gratuites on pouvait publier (et accepter) avant de devoir passer à la version payante. Jauger le moment idéal leur a permis de continuer à offrir un service gratuit pour attirer de nouveaux clients, sans perdre des revenus.

Trouver la limite idéale pour la livraison gratuite

Déterminer la valeur limite du panier avant d’offrir la livraison gratuite … Un problème majeur pour de nombreux sites e-commerce. Une approche server-side testing peut vous aider à déterminer la limite idéale qui incite vos clients à acheter, sans trop dépenser.

Tester vos algorithmes de recherche

Tout test lié à votre moteur de recherche ou “searchandizing” doit passer par une approche server-side. Pourquoi ? Les tests impliquant un nombre de produits consultés, la vitesse à laquelle les produits sont ajoutés au panier, le taux de transaction, la valeur moyenne des commandes… Tous ont besoin d’une méthodologie server-side.

Trouver le formulaire de Paywall idéal

Si vous êtes un média en ligne, les paywalls font probablement partie de votre site web.

Il est possible de mettre en place un paywall client-side, mais les internautes pourront facilement les contourner en supprimant leurs cookies ou leur historique de navigation. Pour une solution fiable à 100%, les règles de déclenchement doivent être gérées côté serveur. De cette façon, vous pouvez tester en toute sécurité l’impact de différents types de configurations de paywall sur votre taux d’abonnement.

Je veux en savoir plus sur le server-side testing avec AB Tasty!

Vous souhaitez en savoir plus sur les tests server-side ? Consultez notre ebook sur 10 tests que vous ne pouvez exécuter que côté serveur.

Prêt pour la prochaine étape ? Contactez-nous pour en savoir plus sur notre solution Contact@abtasty.com

Partager sur

LinkedIn Facebook Twitter

Article

31 Jan 2018
6min lecture

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

AB Tasty

AB Tasty

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

Partager sur

LinkedIn Facebook Twitter

Article

21 Fév 2017
7min lecture

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

Anthony Brebion

Anthony Brebion

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.

Partager sur

LinkedIn Facebook Twitter