Nous avons préparé pour les lecteurs de Habra une traduction d'un article de Michael Kaminsky, ancien directeur de l'analyse chez Harry's. Il parle de ce qui ne va pas avec les tests A / B. Commentaires sur le matériel par Gleb Sologub, directeur de l'analyse chez Skyeng.
Le concept de test A / B est basé sur l'hypothèse fondamentalement erronée qu'il existe une solution unique qui est en moyenne meilleure pour tous les clients. Les analystes devraient abandonner l'hypothèse que leur public est homogène et commencer à développer des systèmes qui permettent d'utiliser (et d'encourager) les résultats de tests autres que binaires.
Au cours des dernières semaines, deux articles très intéressants ont été publiés sur les interprétations non standard des tests A / B. L'un des articles du blog d'ingénierie Uber concerne le calcul de l'effet d'impact par les quantiles, et l'autre ( de l'excellent blog StitchFix Data Science ) traite de l'utilisation d'algorithmes contextuels de bandit pour réaliser la personnalisation.
Ces deux articles sont intéressants, mais il me semble qu'ils ont trop de théorie sur l'interprétation et la mise en œuvre des tests et manquent de faits. Je reformule ma thèse pour plus de clarté:
Les tests A / B traditionnels sont basés sur une hypothèse fondamentalement erronée. Dans la plupart des cas, l'option A sera meilleure pour certains sous-groupes et l'option B pour d'autres. Choisir A OU B perd initialement une combinaison soigneusement sélectionnée de A et B.
Malheureusement, appliquer cette approche aux tests, à l'optimisation et au développement de logiciels n'est pas facile. Cela nécessite de nouveaux outils statistiques, de nouveaux outils pour développer et soutenir des solutions logicielles, ainsi que la formation des parties prenantes, si vous souhaitez qu'elles soient impliquées dans le processus. Dans cet article, je donnerai un exemple motivant, puis je parlerai de certains des problèmes que vous rencontrerez lors de la création de systèmes qui s'adaptent à la nouvelle réalité. Je ne discuterai pas des données statistiques sous-jacentes et liées à la construction de ces types de systèmes (mieux lire l' article de StitchFix et cet article de Google ), mais je parlerai des opportunités que je vois aux niveaux stratégique et architectural.
Exemple motivant
Pour vous convaincre que c'est important, regardons un petit exemple. Bien que ces chiffres soient fictifs, ils représentent parfaitement ce que j'ai vu d'innombrables fois dans l'évaluation en temps réel des tests A / B.
Une autre société de matelas (EOMK) vend des matelas en ligne (vous pouvez voir leur publicité dans le métro). Ils veulent tester un bon de commande mis à jour optimisé pour les téléphones. Les concepteurs craignent un peu que, bien que la version mise à jour soit moins lourde, elle transmet également moins d'informations pendant le processus de commande, ce qui peut affecter négativement les conversions des utilisateurs avec des ordinateurs de bureau.
L'équipe démarre le test et obtient les résultats suivants:
Merde, aucune différence! Intuitivement, vous décidez de partager le trafic sur votre mobile et votre PC.
Ouah! La nouvelle version ... montrait exactement ce que les concepteurs attendaient! La situation est devenue meilleure pour les utilisateurs d'appareils mobiles et pire pour les utilisateurs de PC.
C'est dommage que notre test A / B n'ait montré aucun effet. Peut-être devrions-nous envoyer nos designers pour réfléchir à une nouvelle version du bon de commande.
Mais attends! Et si nous prenons en charge une version mobile optimisée pour les utilisateurs qui accèdent au site par téléphone? Et la version de bureau optimisée - pour les utilisateurs sur les ordinateurs de bureau? Et si nous créions une page de destination qui fonctionnerait mieux le week-end lorsque les gens ont plus de temps pour lire? Et si nous créions une annonce qui fonctionnait mieux en Californie plutôt qu'au Massachusetts?
Et si la page Web ne convenait pas à tout le monde à la fois?
Les tâches
Il est difficile de dire si cette idée est évidente ou révolutionnaire. C'est tellement évident que cela semble presque stupide. Mais si vous regardez comment la plupart des entreprises développent, testent et déboguent des produits logiciels, il s'avère qu'il s'agit d'un changement assez fondamental dans l'approche des problèmes logiciels.
De nombreuses entreprises n'ont toujours qu'une seule version de travail du site Web. Des tests peuvent être effectués, mais dès que l'un des tests gagne, la version perdante est défaussée et la seule version correcte apparaît, le «roi de la colline».
Afin de couvrir toute la diversité des clients et des utilisateurs, il est nécessaire de développer des solutions logicielles d'une manière fondamentalement différente. Nous avons besoin d'outils nouveaux et plus avancés, et nous devons également former les parties prenantes à une nouvelle façon de penser.
Aujourd'hui, essayer de gérer des scénarios d'utilisation avec autant de variables est très difficile (si possible). Étant donné que la gestion de tant d'options coûte cher, de nombreuses entreprises n'essaient même pas de personnaliser leur expérience client. Ensuite, je parlerai davantage des problèmes et décrirai les moyens de les résoudre.
Outils de programmation
Dans notre nouveau monde courageux, où nous fournissons une variété de contenus à différentes catégories d'utilisateurs (dans des proportions qui peuvent changer au fil du temps), nous aurons besoin d'outils pour le développement et l'analyse de nos logiciels.
Il semble que la conséquence la plus évidente de l'utilisation d'un tel paradigme sera une augmentation significative de la quantité de code dans le projet. Au lieu de supprimer les branches de code obsolètes après les tests, nous devrons les prendre en charge (peut-être pour toujours). C'est affreux!
En fait, nous devons rendre les applications plus modulaires afin de pouvoir constamment développer, tester, déployer et maintenir de nouvelles branches de code (par exemple, de nouvelles versions pour les tests).
Afin de pouvoir diriger les utilisateurs vers différentes branches du code en fonction de leurs caractéristiques (potentiellement le nombre de branches du script utilisateur peut être énorme), il est nécessaire de développer une architecture qui supportera une telle branche. Nous avons besoin d'un mécanisme de prise de décision centralisé qui peut choisir l'itinéraire pour cet utilisateur. Il est également nécessaire que les composants du chemin soient suffisamment interchangeables pour guider librement l'utilisateur le long du parcours, même s'ils ont été développés indépendamment les uns des autres et sans un seul cas d'utilisation.
Enfin, sans un seul cas d'utilisation holistique, nous avons besoin d'outils pour que les chefs de produit et les concepteurs puissent imaginer le chemin d'un client dans un jardin de chemins divergents. Comment introduire et évaluer de nouvelles fonctionnalités? Comment pouvons-nous suivre les étapes de cet utilisateur lorsqu'il a utilisé notre application? Comment empêcher une application de se transformer en une masse informe de code spaghetti?
Communication et formation
Il sera particulièrement difficile pour les personnes qui sont loin du processus de création d'un produit de porter ce nouveau regard sur le développement logiciel. Les managers sont habitués à prendre en charge le parcours d'un seul utilisateur, le seul son de la marque et la même expérience universelle d'interaction avec un client. Lorsque nous commençons à personnaliser l'expérience utilisateur, la possibilité de parler d'une solution logicielle d'un seul point de vue disparaît.
Nous devons éduquer les parties prenantes sur la valeur de cette nouvelle approche et les aider à réfléchir aux scripts personnalisés et au son de marque dans ce contexte. Il est nécessaire de développer des méthodes pour déterminer les itinéraires les plus courants. Et donnez aux gestionnaires les outils pour étudier le produit au nom d'un utilisateur d'un certain sous-groupe, afin qu'ils puissent acquérir une expérience d'interaction avec un produit personnalisé pour différents utilisateurs de différents points de vue.
Outils statistiques
Très probablement, dans un monde sans test A / B, nous devrons nous débarrasser de nombreux outils que nous avons traditionnellement utilisés pour optimiser les applications Web. Tous nos efforts pour former les chefs de produit et les spécialistes du marketing au lancement et à l'interprétation des tests A / B n'auront pas d'importance.
Dans ce nouveau monde, nous devrons développer de nouvelles méthodes de recherche et de visualisation d'échantillons de différentes tailles. Nous aurons besoin de nouvelles méthodes de comparaison plus avancées pour ne pas tomber dans le piège des comparaisons multiples .
Conclusions
Compte tenu de la véritable diversité de notre base d'utilisateurs, nous pouvons améliorer l'interaction avec un grand nombre d'utilisateurs, ce qui est très précieux. Malheureusement, comme cela arrive souvent lors du changement d'approche du développement et de la mise en œuvre des technologies, ces avantages sont coûteux. Nous avons un long chemin à parcourir entre le point où nous en sommes actuellement et un avenir passionnant et plus personnalisé, et je suis sûr que ce voyage sera passionnant.
Note de l'auteur:
J'exclus toutes les discussions sur les intervalles de confiance et la signification statistique pour plus de simplicité. Désolé.
Commentaire de Gleb Sologub, directeur des analyses chez Skyeng
Michael résume les tendances actuelles de la personnalisation et fantasme sur ce que devraient être les moyens et les méthodes de développement et d'analyse, lorsque tous les produits informatiques seront entièrement individualisés pour des utilisateurs spécifiques.
Jusqu'à présent, nous avons appris à personnaliser de deux manières: premièrement, en créant des scénarios distincts pour différents segments d'utilisateurs, deuxièmement, en développant des solutions algorithmiques pour afficher du contenu personnalisé à chaque étape de l'entonnoir.
Ainsi, Skyeng a certainement optimisé les versions mobiles du site et de la plateforme de formation, ainsi que différentes versions de ces produits pour les utilisateurs d'âges différents. De plus, nous avons effectué des tests AB et réalisé que les utilisateurs de différentes régions ont des besoins différents, après quoi nous avons introduit une différenciation de la description marketing en fonction de la région.
Aux exemples de personnalisation algorithmique, en plus de ceux cités par Michael, on peut ajouter à la fois les listes longues et largement utilisées de produits ou de contenus recommandés, ainsi que les succès relativement récents dans la génération d'affiches de films individuelles.
Cependant, tout cela peut être fait tout en continuant à utiliser les anciennes méthodes de développement et analyses.
Dans le même avenir que Michael décrit, les tests AB, tels qu'ils sont, ne valent peut-être pas la peine, mais ils auront besoin d'une modularité logicielle incroyable et de nouvelles méthodes d'analyse pour créer une variété infinie de scénarios utilisateur complètement individuels .
Chez Skyeng, nous avons déjà et nous élargissons une équipe de chercheurs et d'analystes qui étudient ces tendances et essaient de les appliquer pour améliorer nos produits.