Article

6min lecture

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

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.

Abonnez-vous à
notre Newsletter

bloc Newsletter FR

AB Tasty traite et stocke vos données personnelles pour vous envoyer des communications tel que détaillé dans notre politique de confidentialité ici.

Article

8min lecture

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

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.