Première catégorie : les tests « quick win »
Ces tests sont souvent simples à mettre en oeuvre : on modifie une bannière, on change le wording ou la couleur d’un bouton.
Ces tests sont souvent demandés par les équipes métiers, c’est-à-dire généralement par l’équipe acquisition ou merchandising. Ils sont simples à mettre en oeuvre : souvent moins d’un jour est nécessaire pour la création des variations dans l’outil de testing, le ciblage, le tracking et la recette
Ces tests engendrent souvent une augmentation modeste et localisée du chiffre d’affaires. Une modification d’un wording sur un call to action pourra ainsi générer un incrément de chiffre d’affaires de l’ordre de +10% pour les visiteurs ayant cliqué sur ce bouton, ce qui se traduit par un impact global sur les revenus du site assez faible.
A l’issu de la phase de testing, la variation gagnante peut être facilement déployée, souvent via une contribution dans le CMS réalisée directement par les équipes métiers.
Deuxième catégorie : les tests intervenant en phase de refonte de site
Les évolutions de certains parcours de conversion comportent un risque majeur : elles peuvent ne pas être comprises par les visiteurs et pénaliser durablement le taux de conversion. Or, une baisse même assez faible du taux de conversion peut avoir un impact majeur sur le chiffre d’affaires.
Pour réduire ce risque, il est nécessaire de valider les mises en production les plus impactantes par des A/B Tests.
Pour mener à bien ce type d’A/B Test, vous allez devoir travailler main dans la main avec le Product Owner responsable de la fonctionnalité qui a vocation à évoluer. C’est lui qui doit vous exposer son besoin, valider le ciblage et les variations que vous réalisez et qui servira de relais technique en cas de problème. C’est également grâce au contact avec le Product Owner que vous pourrez pousser en production la variation gagnante, sans quoi, on l’a vu, mener un A/B Test n’a pas d’intérêt.
Ce type d’A/B Tests nécessite une charge de travail souvent importante : les variations à déployer sont souvent complexes : modification importante du merchandising, test d’un nouveau parcours de conversion.
Cette surcharge de travail se retrouve au niveau des analyses qui doivent être plus poussées que pour des A/B Tests « quick win ». Le succès de l’A/B Test ne sera pas uniquement mesuré au nombre de macro-conversions post clics sur la fonctionnalités. Il faudra inclure les données sur les sessions ultérieures à l’A/B Test de manière à déterminer si les variations testées permettent de générer de la valeur. Par exemple : si l’A/B Test modifie en profondeur le parcours d’inscription il peut être intéressant de suivre le taux d’inscrits actifs et le taux de compte résilié à J+30 post inscription.
Ce type d’A/B Test a un impact important sur l’entreprise : il doit permettre de statuer quant au design et à l’ergonomie des nouvelles fonctionnalités à déployer sur le site. Le chiffre d’affaires incrémental généré par cet A/B Test peut être important !
Il faut donc garder à l’esprit qu’à l’heure des bilans ce type de test constituera donc souvent une vitrine du travail effectué sur l’année par l’équipe testing.
Test quick win ou test intervant en phase de refonte : quel type privilégier ?
Les tests quick win et les tests intervant en phase de refonte doivent tous les deux être menés, dans la mesure où ils sont complémentaires :
- les A/B Test « quick win » sont simples à réaliser et les variations gagnantes peuvent être facilement mises en production. L’incrément en chiffre d’affaires est souvent faible. Ces tests impliquent les équipes métiers
- les A/B Test intervenant en phase de refonte sont plus complexes, ils impliquent les product owners et peuvent se traduire par des gains de revenus significatifs. Dans tous les cas ces tests jouent un rôle important dans les refontes dans la mesure où ils permettent de trancher entre plusieurs hypothèses et d’éviter les mauvaises surprises liées à une mise en production hâtive d’une variation…
Par ailleurs, les tests intervenant en phase de refonte ne peuvent souvent être menés qu’à des périodes précises (souvent un mois avant la mise en production d’une fonctionnalité). A l’inverse, les A/B Tests « quick win » peuvent être menés à n’importe quel moment.
Une bonne pratique consiste donc à prioriser les A/B Tests intervenant en phase de refonte et à mener des A/B Tests « quick win » lorsque la période est plus « creuse »