Article

4min lecture

Avant de tester, établissez votre roadmap

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 !)

Article

8min lecture

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

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

 

Article

7min lecture

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

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

 

Article

9min lecture

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

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 !

Article

8min lecture

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

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

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

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.

Article

5min lecture

Avantages et inconvénients des tests multivariés

Lors d’un test A/B, vous ne devez modifier qu’un seul élément à la fois (ex : le libellé d’un bouton d’action) pour être en mesure d’en déterminer l’impact. Si vous modifiez simultanément le libellé et la couleur de ce bouton (ex : bouton « Acheter » bleu vs bouton « En profiter » rouge) et constatez une amélioration, comment savoir qui du libellé ou de la couleur a réellement contribué à cette performance ? L’apport de l’un est peut-être négligeable ou les 2 ont peut-être contribué à parts égales.

Intérêts des tests multivariés

Un test multivarié vise à répondre à cette question. Avec ce type d’expérimentation, vous testez une hypothèse pour laquelle plusieurs variables sont modifiées et déterminez quelle est la meilleure combinaison parmi toutes celles possibles. Si vous modifiez 2 variables et que chacune comporte 3 déclinaisons, vous avez donc 9 combinaisons à départager (nombre de variantes de la première variable X nombre de déclinaisons de la seconde).

L’intérêt d’un test multivarié est triple :

  • éviter d’avoir à mener de manière séquentielle plusieurs tests A/B et vous faire gagner du temps puisqu’on peut voir un test multivarié comme plusieurs tests A/B menés simultanément sur la même page,
  • déterminer l’apport de chaque variable dans les gains mesurés,
  • mesurer les effets d’interaction entre plusieurs éléments supposés indépendants (ex : titre de la page et visuel d’illustration).

Typologie de tests multivariés

Il existe 2 grandes méthodes pour mener des tests multivariés :

  • « Full Factorial » : il s’agit de la méthode à laquelle on fait généralement référence lorsqu’on parle de tests multivariés. Avec cette méthode, toutes les combinaisons de variables sont designées et testées sur une part équivalente de votre trafic. Si vous testez 2 variantes pour un élément et 3 variantes pour un autre, chacune des 6 combinaisons sera donc affectée à 16,66 % de votre trafic.
  • « Fractional Factorial » : comme son nom le suggère, seule une fraction de toutes les combinaisons est effectivement soumis à votre trafic. Le taux de conversion des combinaisons non testées est déduit de manière statistique en se basant sur celui de celles réellement testées. Cette méthode a l’inconvénient d’être moins précise mais de nécessiter moins de trafic.

Si les tests multivariés semblent être la panacée, il faut avoir conscience de plusieurs limites qui, dans la pratique, en réduisent l’attrait à des cas de figure spécifiques.

Limites des tests multivariés

La 1ère limite concerne le volume de visiteurs à soumettre à votre test pour obtenir des résultats exploitables. En multipliant le nombre de variables et de déclinaisons testées, vous atteignez rapidement un nombre de combinaisons important. Mécaniquement l’échantillon affecté à chaque combinaison sera réduit. Si pour un test A/B classique, vous attribuez 50 % de votre trafic à l’original et à la variation, vous n’allez attribuer que 5, 10 ou 15 % de votre trafic à chaque combinaison lors d’un test multivarié. Dans la pratique, cela se traduit bien souvent par des tests plus longs et une incapacité à atteindre la fiabilité statistique nécessaire à la prise de décision. C’est d’autant plus vrai si vous testez des pages profondes au trafic plus faible, ce qui est souvent le cas si vous testez des tunnels de commandes ou des landing pages de campagnes d’acquisition de trafic.

Le 2ème inconvénient est lié à la façon dont le test multivarié est envisagé. Dans certains cas, il est le résultat d’un aveu de faiblesse : les utilisateurs ne savent pas précisément quoi tester et pensent qu’en testant plusieurs choses à la fois, ils trouveront forcément une piste à exploiter. On retrouve ainsi souvent de petites modifications à l’œuvre durant ces tests. L’A/B testing, à l’inverse, impose une plus grande rigueur et de mieux identifier ses hypothèses de tests, ce qui amène généralement à des tests plus créatifs, appuyés par des données, avec de meilleurs résultats.

Le 3ème inconvénient est lié à la complexité. Mener un test A/B est bien plus simple, surtout dans l’analyse des résultats. Vous n’avez pas besoin de vous imposer une gymnastique complexe de l’esprit pour essayer de comprendre pourquoi tel élément interagit positivement avec tel autre dans un cas et pas dans un autre. Garder un process simple et rapide à exécuter permet d’être plus confiant et de réitérer rapidement ses idées d’optimisation.

Conclusion

Si sur le papier, les tests multivariés sont attirants, on ne peut que constater que mener des tests trop longtemps avec une forte incertitude sur l’obtention d’une fiabilité statistique représente un coût d’opportunité qui limite son intérêt. Pour obtenir des résultats exploitables et sur lesquels rapidement acter, mieux vaut s’en tenir à 90 % des cas à des tests A/B classiques (ou A/B/C/D). C’est d’ailleurs le ratio constaté parmi nos clients, y compris chez ceux ayant une audience de plusieurs centaines de milliers voire millions de visiteurs. Les 10 % restants sont plus réservés aux tests de « fine-tuning » quand vous avez êtes à l’aise avec la pratique du testing, avez obtenu des gains significatifs grâce à vos tests A/B et cherchez à dépasser certains seuils de conversion ou à gagner quelques incréments.

Enfin, il est toujours utile de rappeler que, plus que la typologie de tests (A/B vs multivariés), c’est bien la qualité de vos hypothèses – et par extension celle de votre travail de compréhension des problèmes de conversion – qui sera l’élément différenciateur permettant d’obtenir des up lifts et des résultats probants de votre activité de testing.

Article

10min lecture

Méthodologie d’A/B testing : comment s’y prendre ?

Afin d’effectuer des tests A/B efficaces, il est important de s’appuyer sur un cadre méthodologique rigoureux pour pouvoir obtenir des résultats concrets.

1. Définir les objectifs et les attentes

Un sentiment fréquent parmi les entreprises ayant mis en place un programme de testing est un manque de résultat de leurs tests. Cela s’explique par leur interprétation de la notion de succès.

Trois profils se détachent : « Un test est concluant si et seulement si… » :

  • Il produit une augmentation majeure du taux de conversion.
  • Il a eu un effet positif sur l’engagement des internautes, même si ces derniers ne convertissent pas directement.
  • Il a permis de modifier le design un peu daté de leur site sans impacter négativement les KPIs.

Les attentes vis-à-vis de l’A/B testing ainsi que les objectifs mesurés, dépendent beaucoup de la maturité des entreprises dans le domaine de la conversion. Attention, la macro conversion – situation dans laquelle seul le taux de conversion global est mesuré – est fortement déconseillée ! En réalité, peu de tests produiront des effets significatifs sur le taux de conversion, et il est important de tirer des enseignements de toutes les informations disponibles.

Une modification peut n’avoir aucun impact sur le taux de conversion global, mais impacter positivement les micros conversions, comme l’ajout au panier ou la création d’un compte utilisateur,       qui sont autant d’étapes vers la macro conversion. L’évolution de la valeur moyenne du panier d’achat est également à prendre en compte pour apprécier les résultats du test. Le succès est fait d’une succession de gains, parfois modestes.

2. Mettre en place une équipe projet ou un référent testing

La réussite d’un programme de testing ne repose pas uniquement sur l’outil d’A/B testing utilisé, mais sur l’expérience des personnes chargées de l’optimisation des conversions.

Attention, le nombre d’intervenants est parfois important lorsqu’on aborde le sujet sensible de la conversion. Dans beaucoup de structures, la personne voulant effectuer une modification doit d’abord obtenir l’aval du management, puis mobiliser des ressources graphiques et techniques pour mettre en place le test, et finalement recourir à un web analyste pour évaluer les résultats.

C’est pourquoi il est conseillé de mettre en place une équipe projet, composée de compétences diverses et capable d’analyser les données, d’identifier les problèmes de conversion et de se mettre dans la peau des utilisateurs finaux pour suggérer des solutions adaptées. Il est également utile d’avoir dans son équipe, un chef de projet ainsi qu’un sponsor. Le chef de projet coordonnera les équipes et sera le garant de la roadmap de tests, pendant que le sponsor appuiera auprès de la direction les initiatives d’optimisation et sera responsable du retour sur investissement des activités de testing.

Si par contre, la structure de l’entreprise ne justifie pas de telles ressources, avoir un référent qui centralise l’exécution des tests et l’analyse des résultats reste conseillé.

3. Formuler des hypothèses fortes de test

Un programme d’A/B testing doit nécessairement être alimenté par d’autres sources d’informations, afin d’identifier les problèmes de conversion et de comprendre au mieux le comportement des internautes. Cette phase d’analyse est critique et doit aboutir à la formulation d’hypothèses fortes à tester.

Une hypothèse correctement formulée est le premier pas vers le succès d’un programme d’A/B testing et doit respecter les règles suivantes :

  • elle doit être liée à un problème clairement identifié et dont les causes sont pressenties,
  • elle doit mentionner une solution possible au dit problème,
  • elle doit indiquer le résultat attendu, lequel est directement lié au KPI à mesurer.

Par exemple, si le problème identifié est un taux d’abandon élevé sur un formulaire d’inscription, lequel est supposé être trop long, une hypothèse valide pourrait être : « Raccourcir le formulaire en supprimant les champs facultatifs, tels que le téléphone et l’adresse postale, augmentera le nombre de contacts collectés ».

4. Prioriser les tests à mener

L’analyse des sources d’information met souvent en évidence plusieurs problèmes de conversion et permet de formuler différentes hypothèses de tests. Il faut maintenant prioriser celles-ci pour établir une roadmap et rythmera la mise en place des tests. Plusieurs éléments doivent être pris en compte pour prioriser ces hypothèses :

  • Le gain potentiel du test. Les pages à fort trafic présentant de gros problèmes de conversion (ex. : un taux de sortie élevé) sont des bons points de départ. Comment les trouver ? Analysez vos données web analytics !
  • La facilité d’implémentation du test. La complexité des solutions envisagées peut influencer la priorisation des tests en fonction des ressources disponibles.

Une fois la priorisation faite, les contours de la roadmap doivent être dessinés. Dans un souci de formalisation, n’hésitez pas à la mettre noir sur blanc en incluant le maximum d’informations (nom du test, type et l’URL de la page testée, date de lancement, hypothèse à confirmer, KPIs à mesurer ainsi que même l’impact potentiel l’effort d’implémentation (note de 1 à 3 par exemple).

Cette roadmap permettra de mobiliser, d’aligner et de coordonner les efforts des parties prenantes du projet pour atteindre les objectifs définis.

5. Mettre en place les tests

Les outils tels qu’AB Tasty permettent à chacun de lancer un test sans nécessiter de connaissances techniques. L’utilisateur peut alors modifier lui-même les pages de son site via un éditeur de type WYSIWYG (What You See Is What You Get). Après une rapide formation, ces outils sont rapides à prendre en main et permettent à l’utilisateur d’être rapidement autonome.

2 mises en place possibles : Concernant le mode de fonctionnement, deux tendances se dessinent : l’intégration totale des tests par l’entreprise ou la prise en charge d’un prestataire externe. L’avantage de ce dernier est la dimension de conseil en optimisation des conversions, ainsi que la création et mise en place du design des variations. Cependant, il est plus simple et flexible de former directement son équipe interne, afin d’être toujours libre de ses changements. Certains outils, comme AB Tasty, proposent un système de certification qui atteste de leur connaissance de l’outil et de leur expertise.

Encore une fois, le choix de l’outil de testing ainsi que votre internalisation ou non de l’activité, dépendra de la maturité de l’entreprise sur les sujets liés à la conversion et de ses ressources budgétaires et humaines. Chaque cas de figure sera donc différent et nous ne pouvons que recommander d’opter pour une solution adaptée à ses besoins et contraintes. Rien ne sert de disposer d’un outil complexe, si l’utilisateur souhaite être autonome, mais est, au final, dépendant d’un prestataire pour l’utiliser. À l’inverse, un outil trop simple à utiliser pourra s’avérer limité lorsque les besoins évolueront.

6. Analyser les résultats des tests

La phase d’analyse des tests est la plus délicate. La solution d’A/B testing doit au minimum proposer une interface de reporting indiquant :

  • les conversions enregistrées par variation
  • le taux de conversion
  • le % d’amélioration par rapport à l’originale
  • l’indice de fiabilité statistique enregistrée pour chaque variation

Les outils plus avancés permettent d’affiner les données brutes en segmentant les résultats par dimension (ex. : source de trafic, origine géographique des visiteurs, typologie de clients, etc.). Il est ainsi possible de mettre en évidence des sous-populations d’internautes pour lesquelles l’une des variations surperforme statistiquement, quand bien même le test paraitrait non concluant au niveau global (tous internautes confondus). Cette information a une valeur stratégique, car elle est va permettre d’orienter vos futures actions (ex.: personnalisation des contenus selon une segmentation client spécifique).

Attention : La segmentation des résultats ne doit pas pour autant faire oublier les principes de fiabilité statistique. Si un test s’avère fiable sur l’ensemble des internautes, ce ne sera pas forcément le cas sur un échantillon restreint. Il faut alors vérifier la fiabilité du test sur l’échantillon concerné !

Nos conseils : Intégrez vos tests au sein de votre outil de web analytics pour bénéficier de métriques complémentaires et pour pouvoir analyser l’impact du test sur d’autres dimensions. Afin de prendre en compte tous les comportements des internautes (par jour de la semaine, voire même par heure de la journée) nous vous recommandons également de laisser votre test actif au moins une semaine, deux dans l’idéal.

7. Documenter les tests menés

Il est primordial de correctement documenter et archiver les tests menés. Si plusieurs personnes sont en charge de l’optimisation des conversions, cela permettra de partager efficacement les informations. Il en est de même si un nouvel intervenant doit se plonger dans des tests menés plusieurs mois auparavant. Documenter un test consiste à garder une trace écrite, à l’issue de chaque test, d’informations telles que :

  • le nom du test,
  • la période du test,
  • l’hypothèse testée et les données qui ont permis d’identifier celle-ci,
  • une description des variations mises en place, captures d’écran à l’appui,
  • les résultats du test,
  • les enseignements du test,
  • le gain monétaire potentiel sur une année suite à la mise en place de la variation la plus performante.

Ce travail de documentation peut aussi permettre à l’équipe en charge du programme de testing d’identifier de nouvelles hypothèses à tester et d’évaluer le ROI de son activité.

8. Implémenter les versions gagnantes et valider les gains constatés

Dès lors que l’une des variations surperforme l’originale avec certitude, il est temps de mettre en production la variation gagnante. Selon l’organisation de l’entreprise, le délai entre chaque release du site (phase de mise en production) peut être important. Pour ne pas passer à côté du moindre gain, surtout si celui-ci est important, la plupart des outils d’A/B testing proposent d’afficher la variation gagnante à 100 % des internautes, le temps que les changements passent en production.

Une fois l’optimisation définitivement mise en place, il convient toutefois de contrôler que les niveaux de gains constatés durant le test se confirment sur le long terme. Continuer à suivre les KPIs peut s’avérer judicieux, car de nombreux facteurs exogènes peuvent expliquer que, durant le test, l’optimisation mise en place ait généré de meilleurs résultats (Ex : proximité d’une période de fêtes, origine du trafic, mise en place d’une campagne d’acquisition en parallèle, etc.).

9. Diffuser les résultats des tests

Il est important de partager au plus grand nombre les enseignements tirés des tests. Le management en premier lieu, doit avoir une synthèse des résultats en soulignant l’impact des tests sur les KPIs définis préalablement. Les enseignements plus larges pouvant impacter d’autres aspects de l’activité doivent également être mis en évidence. Le partage de l’information doit se faire à tous les niveaux de l’organisation pour qu’une culture du testing se mette progressivement en place.

10. Tester en permanence

L’A/B testing est un processus d’optimisation continue. À l’issue de chaque test, des enseignements sont tirés et viennent alimenter de nouvelles hypothèses de tests pour étoffer la roadmap. C’est, par ailleurs, dans la durée que les efforts porteront leurs fruits : les premiers tests ne produiront certainement pas les résultats escomptés, car la construction d’une expertise prend du temps.

Article

6min lecture

A/B testing : tag synchrone ou asynchrone ?

Deux versions de tags sont aujourd’hui disponibles chez AB Tasty : une version synchrone et une autre asynchrone. Ce billet de blog vise à décrypter ce qui se cache derrière ces 2 notions et leurs implications pour bien comprendre lequel choisir.

La performance web au coeur des débats

Ce n’est plus un secret pour personne, les performances techniques de votre site ont un impact majeur sur vos taux de transformation et vous devez vous assurer que les pages de votre site se chargent le plus rapidement possible pour offrir une expérience fluide à vos utilisateurs qui sont de plus en plus impatients et s’attendent à un niveau de performance élevé. Quelques centaines de millisecondes peuvent avoir un impact de plusieurs centaines de milliers d’euros, voire plus, à l’image d’Amazon qui a chiffré que toutes les 100 ms gagnées correspondaient à 1 % de CA additionnel.

En parallèle, vos besoins de tracking sont de plus en plus importants, car vous faites appel à de multiples solutions, notamment concernant l’acquisition de trafic, lesquelles nécessitent que vous ajoutiez leur tag JavaScript à vos pages pour mesurer les performances de vos campagnes. Chaque nouveau tag vient donc augmenter un petit plus le poids de vos pages. On comprend alors aisément pourquoi certains éditeurs sont fébriles dès qu’une nouvelle solution doit être installée. Leur principale crainte tient naturellement au fait qu’ils ne maitrisent pas l’infrastructure derrière ces solutions et n’ont pas de garantie qu’elle soit toujours disponible (notion d’uptime). Le risque est alors que le tag, faisant un appel aux serveurs de la solution et n’ayant pas de réponse, bloque le chargement de la page du client. Il existe heureusement une parade à ce problème qui consiste à utiliser des tags asynchrones, en lieu et place des traditionnels tags synchrones.

Les modes synchrone et asynchrone

Schématiquement, en mode synchrone, les scripts sont chargés les uns à la suite des autres de façon séquentielle : un script ne peut être chargé que si le précédent a fini d’être chargé. Si, dans la liste de tous les scripts appelés, l’un d’eux ne se charge pas, il bloque alors le chargement de tous les autres, pouvant aller jusqu’à bloquer le rendu de la page. Pour limiter ce risque, on a longtemps suggéré de placer l’ensemble des scripts en bas de page pour éviter ce scénario catastrophe : tous les éléments importants pour le rendu de la page ayant déjà été chargé, le mal est moindre si un script pose problème. Dans la pratique cela n’est pas toujours possible ou recommandé, notamment pour des raisons de fiabilité du tracking. À l’inverse, en mode asynchrone, les appels aux différents scripts se font en parallèle et votre navigateur n’empêche pas l’exécution d’un script si un autre échoue. Cela veut également dire qu’il n’est pas possible de contrôler précisément l’ordre d’exécution des scripts.

Compte tenu de leurs avantages, les tags asynchrones sont vite devenus la panacée dans le milieu des solutions technologiques pour rassurer leurs clients sur cet enjeu de performance, et sont aujourd’hui la solution recommandée pour la plupart des outils (ex. : tracking des campagnes d’acquisition, mesure d’audience, collecte de données, etc.).

Quelle version utiliser pour le testing ?

Dès lors qu’une nouvelle solution veut montrer patte blanche chez un éditeur, la disponibilité d’une version asynchrone de son tag est donc un prérequis et nombreux sont ceux qui le réclament pour les solutions de testing. Si ces dernières peuvent sans difficulté se plier à cette demande en fournissant une version asynchrone de leur tag (ce qui est le cas chez AB Tasty), c’est malheureusement oublier les spécificités de leur fonctionnement. Celles-ci ne se contentent pas de collecter des données, elles appliquent également des modifications visuelles sur les pages.

Concrètement, le tag de la solution de testing appelle un fichier JavaScript qui va s’auto-exécuter dès qu’il est reçu par le navigateur de l’internaute. Ce fichier contient le code qui va modifier les éléments de la page et manipule le DOM (Document Object Model) qui schématiquement contient tous les éléments constituant votre page. L’application de ces modifications fait face à un enjeu d’immédiateté important pour respecter l’expérience utilisateur. En effet, si les modifications sont appliquées avec un délai de quelques centaines de millisecondes, l’utilisateur final peut noter un effet de scintillement et voir très temporairement la version initiale puis la version modifiée. Ce n’est, d’une part, pas acceptable pour son expérience de navigation et d’autre part pour la fiabilité de votre expérimentation puisqu’il peut se rendre compte qu’il participe à un test (on parle d’effet Hawthorne). C’est pour cette raison que le mode synchrone reste à privilégier pour les solutions de testing. NB : si le mode synchrone s’impose pour l’application des modifications, la collecte des données, elle, s’accommode très bien du mode asynchrone.

tag-synchrone-asynchroneExigez des garanties au niveau des performances !

Les spécificités et les conditions du bon emploi des solutions de testing étant rappelées, les inquiétudes techniques évoquées au début de cet article refont surface. C’est à votre prestataire de dissiper vos doutes en vous apportant des garanties sur la performance de son infrastructure technique. Chez AB Tasty, nous avons mis en place plusieurs optimisations pour limiter le temps de chargement de notre script.

  1. Nous utilisons un fichier statique mis en cache suite à son premier appel (ce qui évite d’avoir à effectuer de nouvelles requêtes au cours de la même session).
  2. Nous limitons également le poids de ce fichier en y intégrant que le code nécessaire aux tests actifs, contrairement d’autres solutions.
  3. Nous diffusons également ce fichier plus rapidement (moins de 100 millisecondes pour le premier appel) en le distribuant sur de multiples serveurs géographiquement proches de l’internaute. C’est le principe du Content Delivery Network (CDN).
  4. Nous travaillons avec plusieurs d’entre eux et faisons également appel un prestataire de CDN balancing qui permet d’acheminer les requêtes vers les CDN les plus rapides à un instant T.
  5. D’autres optimisations plus complexes sont également mises en œuvre.

Si, malgré toutes ces précautions, vous doutez encore de l’infrastructure de vos potentiels prestataires, nous ne pouvons que vous conseiller de comparer leurs performances.

  • Prêtez attention à leurs références clients. Travaillent-ils avec des sites à forte volumétrie et à fort enjeu de performance, comme des sites e-commerce majeurs ?
  • Effectuez des benchmarks et des mesures techniques.
  • Demandez des engagements de services sur ces points (Service Level Agreement).