Dans ce 6e article de notre série “Cookieless World”, qui a déjà fait l'objet d'une brève présentation dans l'article précédent intitulé "How to prepare your digital marketing efforts towards a cookieless world - Cookieless Series Part 2", nous nous penchons sur l'avenir de l'optimisation du taux de conversion et des A/B tests.
Les cookies étant également utilisés par les outils de A/B test, quel sera l'impact sur ces outils à l'avenir ? Existe-t-il des solutions alternatives ?
L'impact de la suppression progressive des cookies tiers
Aujourd'hui, de nombreux annonceurs ont mis en place, à grande ou à petite échelle, des équipes au sein de leur entreprise qui se concentrent sur l'amélioration de l'expérience du client et de son parcours vers la conversion sur leurs sites web ou autres produits. Ceci dans le but d'améliorer l'impact sur le business. Lors de ce processus, souvent appelé optimisation du taux de conversion (CRO en anglais, pour conversion rate optimisation), une grande importance est accordée à l'utilisation d'un cadre permettant des tests et apprentissages continus. La possibilité de tester de multiples variations de, par exemple, structures de pages, design et autres éléments, permet d'identifier ces éléments qui rendent l'expérience de l'utilisateur plus facile et plus agréable.
Dans la boîte à outils de l'expert en CRO, un outil est particulièrement crucial. Il s'agit de l'outil d’A/B test qui permet à l'équipe travaillant sur le CRO de vérifier ses hypothèses et de tester plusieurs variations les unes par rapport aux autres. Il existe aujourd'hui un grand nombre de ces outils sur le marché. Pour n'en citer que quelques-uns, on retrouve Google Optimize, Optimizely, AB tasty, VWO ou Adobe target et bien d'autres encore.
La plupart de ces outils ont un élément spécifique en commun: ils utilisent certains cookies pour diviser les groupes d’utilisateurs en un groupe de test et un groupe de contrôle. Le cookie sert ici à identifier si un utilisateur va voir la variante A ou la variante B dans le cadre d'un test lorsqu'il visite le site web. Ce processus d'identification est crucial dans un environnement de test, car il ne faudrait pas que les utilisateurs voient à la fois la variante A et la variante B. Ainsi, le chevauchement pourrait provoquer une pollution dans notre groupe de test/contrôle et fausser les résultats du test.
Sachant maintenant que les outils d’A/B test, si cruciaux pour l'optimisation des produits, dépendent si fortement des cookies, que se passera-t-il si les cookies venaient à disparaître demain ? Comment réaliser des tests efficaces sans cookies ?
Comment fonctionne le server-side testing ?
Comme nous l'avons déjà souligné dans l'un des articles précédents sur le server-side tagging, il est possible d'utiliser le server-side tag management afin de contourner la dépendance aux cookies d'aujourd'hui. C'est également le cas pour les A/B tests.
Le server-side testing est une méthode d’A/B test où les variations d'un test sont faites directement sur le serveur web et ensuite envoyées au navigateur du visiteur. Cette méthode diffère du client-side testing, où le test est envoyé côté client par JavaScript et où les changements ne se produisent que dans le navigateur du visiteur.
Le server-side testing est plus robuste car il permet d'exécuter des tests complexes et avancés (par exemple, tester des changements comme un ensemble de résultats de requêtes de base de données), tandis que le client-side testing porte sur des tests plus simples, liés au design et à l'interface utilisateur (par exemple, tester les titres ou les couleurs des boutons). Le server-side testing pouvant gérer des scénarios plus complexes, son implémentation est également plus technique et nécessite d'importantes compétences en matière de coding, contrairement à celle de client-side testing qui est plus simple.
Aujourd'hui, de plus en plus d'entreprises passent du client-side testing au server-side testing, pour des raisons telles que les performances de chargement des pages, le contrôle des données, etc. Mais aussi, et surtout, parce qu’il permet de conserver des données pertinentes sur l'utilisateur pour les A/B tests sous la forme de cookies de premier niveau, côté serveur.
Justine Heeren
| LinkedinCette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
