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.
