Comment configurer un environnement d'expérimentation pour le développement de produits basé sur les données

En tant que propriétaire de produit, il est courant de se demander s'il faut procéder avec l'option A ou l'option B. Ou quelle version de l'écran doit être implémentée pour obtenir de meilleurs résultats ? Prendre de telles décisions peut être difficile, surtout lorsque vous êtes soumis à des délais serrés avec des ressources limitées. De plus, ces décisions sont prises sur la base d'un jugement personnel ou en copiant l'approche d'un concurrent, ce qui peut conduire à des résultats sous-optimaux.

La bonne nouvelle est que l'on peut éviter de tels écueils en mettant en place un environnement d'expérimentation simple qui nécessite relativement peu d'efforts. Dans cet article, nous décrirons comment vous pouvez y parvenir.

Table des matières

• Pourquoi la configuration d'un environnement de test est-elle importante ?
• Mythes
• Configurer votre environnement de test
  • Définir l'objectif de votre future expérience
  • Concevoir l'architecture de votre environnement d'expérimentation
  • Analyser et interpréter les résultats
  • Mise à l'échelle de l'option préférée.
• Conclusion.

Pourquoi la configuration d'un environnement d'expérimentation est-elle importante ?

La configuration d'un environnement de test est importante pour deux raisons :

• Premièrement, cela vous permet de vous assurer qu'une fois que vous implémentez une nouvelle fonctionnalité, vous choisissez la meilleure option basée sur une approche basée sur les données.

  
  

• Deuxièmement, cela vous permet d'améliorer en permanence les fonctionnalités existantes de votre produit en comparant les options « telles quelles » aux options hypothétiques « à venir » et en effectuant une analyse « et si ».

Mythes

Avant de passer à l'approche, démystifions certains des mythes qui égarent généralement les propriétaires de produits :

J'ai besoin de beaucoup de ressources pour mettre en place un environnement complexe permettant de faire des expériences et des tests A/B

Incorrect : l'approche décrite prend moins d'une semaine des ressources de votre ingénieur logiciel.

J'ai besoin d'un processus de collecte de données bien établi et d'un suivi détaillé des événements

Faux : Vous pouvez vous appuyer sur une base de données existante qui stocke des informations sur le cycle de vie de l'entité principale de votre produit. Par exemple, les statuts des commandes si vous êtes un service de livraison.

J'ai besoin d'une équipe d'analystes dédiée qui traitera mes demandes au quotidien

Faux : une fois que vous avez compris l'approche et les métriques de votre expérience, vous pouvez extraire régulièrement des données par vous-même à l'aide d'une simple requête SQL.

Approche

Pour configurer votre environnement d'expérimentation, il est conseillé de suivre ces étapes :

1. Définissez l'objectif de votre future expérience, comprenez les options et choisissez les métriques

Avant de contacter votre concepteur de produit, définissez les objectifs et les mesures à mesurer dans le cadre de votre expérience. Dans le cas d'une question classique "Option A ou Option B", il est généralement simple de savoir ce que vous souhaitez obtenir en mettant en œuvre un changement. Par exemple, vous pouvez vous adresser à une partie spécifique de l'entonnoir.

À titre d'illustration, supposons que vous travaillez dans une entreprise de livraison et que vous vous concentrez actuellement sur le formulaire de création de commande. Vous souhaitez vous adresser à un pourcentage relativement faible d'utilisateurs qui fournissent leur adresse de livraison, puis sélectionnent une méthode d'expédition. Imaginez également que vous avez deux nouvelles versions du parcours :

1. Version actuelle : un écran nécessite la saisie d'adresses et l'affichage de la carte avec une épingle en fonction de l'adresse fournie. L'écran suivant permet de sélectionner une méthode d'expédition en fonction de l'adresse fournie.

   
   

2. Nouvelle version : Un seul écran nécessite de saisir l'adresse et d'y sélectionner le mode d'expédition.

L'objectif est de déterminer laquelle des options conduit à une part plus élevée d'utilisateurs qui ont fourni leur adresse et sélectionné une méthode d'expédition. Les métriques sont assez simples : % d'utilisateurs qui ont fourni leur adresse et sélectionné une méthode d'expédition.

En fait, il existe 2 façons de mesurer ces données :

1. Basé sur les données déjà disponibles par la conception de votre backend . Par exemple, considérez une base de données contenant des informations sur le cycle de vie de la commande. Votre commande peut avoir des états ou des statuts tels que :

   
   

   1. Brouillon créé

   2. Essayez de trouver des méthodes d'expédition

   3. Options d'expédition trouvées/Options d'expédition introuvables

      
      

2. Suivi des événements - ce n'est pas quelque chose qui fonctionnera immédiatement et nécessite donc des efforts supplémentaires pour être mis en œuvre. Cependant, le suivi des événements permettra une analyse plus granulaire pour vous, par exemple, le type d'appareil et le nom du navigateur peuvent être passés en tant que paramètre de vos événements.

Dans les prochaines sections de cet article, nous nous concentrerons sur la première approche, c'est-à-dire l'architecture de données existante, sans suivi des événements.

2. Concevoir l'architecture de votre environnement d'expérimentation

2 étapes principales doivent être effectuées dans le cadre du déroulement de l'expérience :

• Créer une expérience avec les paramètres sélectionnés
• Définissez une étape du parcours de l'utilisateur lorsque l'utilisateur doit être affecté à l'un ou l'autre groupe et assurez-vous que l'interface utilisateur pertinente s'affiche en conséquence

Créer une expérience :

L'idée est de proposer un cadre de test A/B léger qui devrait être aussi simple que possible et devrait vous permettre de créer des expériences avec les paramètres suivants :

• ID du test
• Échantillon maximal
• Numéro et noms de chaque groupe
• Probabilité d'appartenir à chaque groupe

La possibilité de configurer ces paramètres vous permet de définir une limite d'échantillon et de choisir aléatoirement les candidats à l'expérience jusqu'à ce que la taille d'échantillon souhaitée soit atteinte.

Le client et le serveur ont besoin de changements pour cela : le serveur doit suivre le nombre de candidats par expérience et le backend décidera si l'utilisateur actuel doit faire partie d'une expérience ou non. Le backend décidera si l'utilisateur authentifié doit faire partie de l'expérience en fonction de la taille actuelle de l'échantillon et d'une probabilité fixe. De plus, le backend doit conserver une collection d'utilisateurs faisant partie d'une expérience donnée afin de fournir des expériences cohérentes aux utilisateurs et de calculer correctement les résultats de l'expérience.

Voici à quoi pourrait ressembler le point de terminaison pour la configuration de l'expérience :

POST /api/your-service/experiment-create

Demande:

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

Réponse:

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Décider quand et comment l'utilisateur doit être affecté à des groupes expérimentaux :

Vous aurez besoin d'un point de terminaison distinct qui sera responsable de l'attribution d'un utilisateur spécifique à l'expérience et au groupe correspondant. Appelons-le experiment-enrollments .

Lors de la conception de l'ensemble de l'environnement, vous devez comprendre clairement à quelle étape du parcours utilisateur le point de terminaison experiment-enrollments doit être appelé. De plus, il se peut que tous les utilisateurs ne doivent pas participer à l'expérience. C'est pourquoi il serait également utile de fournir un jeton d'authentification utilisateur dans un point de terminaison.

Dans notre exemple, si nous voulons nous concentrer uniquement sur les nouveaux utilisateurs qui effectuent leur première commande, user-auth nous permettra de déterminer de quel type d'utilisateur il s'agit et s'il doit être inscrit à l'expérience. Assurez-vous également qu'une fois le point de terminaison appelé, toutes les informations nécessaires sont disponibles et tiennent compte des spécificités de votre parcours et de votre cycle de vie.

Le critère d'évaluation experiment-enrollments est décrit ci-dessous. Il peut être appelé à une étape spécifique du voyage (par exemple avant d'atterrir sur l'écran nécessitant une adresse de livraison) pour des types d'utilisateurs spécifiques (par exemple uniquement les nouveaux utilisateurs qui n'ont pas encore fourni l'adresse) et calculera si l'utilisateur actuel doit participer dans une expérience donnée ou non :

POST /api/your-service/experiment-enrollments , le jeton d'authentification de l'utilisateur est requis

Demande:

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Réponse:

 {200, enrolled: true/false, group_name: group_1,}

Pour illustrer à quoi ressemblerait le flux de données théorique, supposons le même exemple de flux de création de commande dans la société de livraison. Vous sélectionnez entre 2 options d'écran de création de commande.

Les endpoints suivants sont mentionnés dans le schéma ci-dessous, à savoir :

• /créer-commande-brouillon (étape 3)

• /trouver-méthode-d'expédition (étape 16)

• /soumettre-commande (étape 20)

  
  

sont fournis à l'appui de l'exemple illustratif et ne font pas nécessairement partie de l'environnement d'expérimentation

En outre, l'architecture illustrative et simplifiée des bases de données est fournie ci-dessous.

Il existe 3 tableaux principaux :

1. Experiments set - il contient toutes les expériences que vous avez créées précédemment. La base de données est mise à jour chaque fois que vous appelez le point de terminaison /experiment-create .

   
   

2. Experiments database - elle contient tous les enregistrements associés à chaque inscription d'un utilisateur spécifique. La base de données est mise à jour chaque fois que vous appelez le point de terminaison experiment-enrollments

   
   

3. Order lifecycle database - elle est fournie pour prendre en charge l'exemple illustré de la façon dont les données liées à l'expérience peuvent être stockées. Le fait est que ce tableau (ou tout tableau similaire qui correspond aux spécificités de votre produit) vous permettra de voir si l'entrée (par exemple la création de la commande) a réussi ou non pour l'utilisateur spécifique inscrit dans l'un des groupes expérimentaux que vous avons défini. Dans notre exemple, nous pouvons compter sur le statut de méthode d'expédition sélectionnée qui permet de conclure que l'utilisateur a fourni avec succès les détails d'expédition, puis a sélectionné l'une des méthodes d'expédition suggérées.

   
   

   
   

Aperçu de l'approche de conception et de mise en œuvre

Avantages:

1. L'échantillon obtenu est hétérogène
2. La taille de l'échantillon est connue à l'avance
3. Les résultats peuvent être calculés rapidement, en fonction de la probabilité d'échantillonnage fixe

Les inconvénients:

1. Nécessite des modifications du frontend et du backend
2. Le calcul des résultats s'appuiera sur plusieurs bases de données, dont certaines n'ont pas pu être initialement conçues à des fins d'analyse.

Tâches et devis indicatifs :

• [ ] undefined [Backend] Créer un modèle et exposer le point de terminaison du compteur d'extraction : ~2 points d'histoire
• [ ] undefined [Backend] Exposer le point final du compteur d'incrément : ~2 points d'histoire
• [ ] undefined [Backend] Exposer les points de terminaison pour récupérer et incrémenter le compteur : ~ 1 point d'histoire
• [ ] undefined [Frontend] Points de terminaison du compteur d'appels pour basculer entre les flux d'inscription : ~3 points d'histoire

Une fois que vous avez conçu votre backend, alignez-vous avec votre équipe frontend sur la meilleure façon pour eux de recevoir les informations et à quelle étape du flux.

Gardez à l'esprit et atténuez les principales dépendances :

• Assurez-vous que vos équipes sont alignées sur un contrat en amont afin que la partie frontend puisse être implémentée en parallèle avec le backend.
• Essayez d'éviter que votre frontend ne soit bloqué jusqu'à ce que tout le backend soit terminé
• Quel que soit l'environnement de test, toutes les options de l'interface utilisateur doivent être implémentées de toute façon

3. Analyse et interprétation des résultats

Une fois que votre expérience a duré suffisamment longtemps, il est important d'analyser et d'interpréter les résultats pour tirer des conclusions significatives.

Définissez la liste des champs dont vous avez besoin pour calculer l'impact sur les métriques sur lesquelles vous avez décidé de vous concentrer plus tôt.

À partir de l'exemple illustratif ci-dessus, les sources de données seraient 2 tables :

• Experiments database :

  • Entrée : identifiant de l'expérience pour laquelle vous recherchez des résultats

  • Sortie : liste de tous les identifiants d'utilisateurs qui participent à une expérience spécifique, le groupe auquel chaque utilisateur a été affecté et l'horodatage auquel l'utilisateur a été affecté

    
    

• Order lifecycle database
  • Entrée : liste des utilisateurs concernés par votre expérience et horodatage de leur inscription à l'expérience
  • Sortie : statuts finaux de toutes les commandes associées à ces utilisateurs et traitées après l'inscription de l'utilisateur au test

Sur la base de ces données, vous pouvez calculer le pourcentage de commandes créées avec succès pour chacun des groupes de test.

Lors de l'analyse de vos résultats, il est important de regarder au-delà des chiffres bruts. Vous souhaiterez également rechercher une signification statistique pour vous assurer que les différences que vous observez entre vos groupes de test ne sont pas uniquement dues au hasard. Je ne me concentrerai pas trop sur cette partie car je vois déjà de nombreux articles liés à ce sujet avec ceci et d'autres ressources en ligne. Quoi qu'il en soit, une connaissance excessive n'est pas requise ici : à mon avis, être capable d'appliquer le Z-Test ou le T-Test pour vérifier la signification de la différence entre les 2 groupes serait suffisant.

Néanmoins, une fois que vous avez déterminé que vos résultats sont statistiquement significatifs, vous pouvez commencer à tirer des conclusions sur l'option de votre produit qui a obtenu les meilleurs résultats.

4. Mise à l'échelle de l'option préférée

Une fois que vous avez mené à bien une expérience et obtenu un degré de confiance suffisant concernant la meilleure option, l'étape suivante consiste à étendre vos modifications à l'ensemble de votre produit. Il peut y avoir plusieurs approches :

• Le plus simple consiste à ajuster la configuration de votre test afin que 100 % des utilisateurs appartiennent au groupe qui affiche les meilleurs résultats . Vous devrez réserver du temps pour nettoyer le code à l'avenir afin que l'affichage de cette partie spécifique de l'interface utilisateur soit indépendant de l'environnement de test

  
  

• La moins simple est si votre produit est disponible sur plusieurs plates-formes. Soyez très prudent lorsque vous supposez que les résultats des tests sur le flux Web s'appliquent au flux de l'application mobile (et vice versa). Parfois, il vaut mieux prévenir que guérir et exécuter une expérience distincte de la même manière, mais sur une autre plate-forme.

De conclure

Avoir son propre environnement d'expérimentation est un outil très pratique pour tout chef de produit. Quel que soit le stade de maturité de votre produit actuel, la création d'un environnement de test ne devrait pas prendre trop de temps. Payer un coût unique assez faible pour le faire fonctionner vous montrera assez rapidement le retour sur investissement.

Enfin, voici quelques conseils pour vous assurer que les résultats de l'expérience ont du sens :

• Tout d'abord, comprenez quelles mesures seront affectées (le cas échéant) par la mise en œuvre du changement que vous envisagez.
• Définissez clairement vos objectifs et vos métriques avant de commencer votre test
• Gardez votre expérience aussi simple que possible, en vous concentrant sur un changement clé à la fois
• Soyez prudent lorsque vous envisagez d'extrapoler les résultats de votre expérience sur d'autres plates-formes ou d'autres services similaires
  

En suivant ces bonnes pratiques, vous pouvez mettre en place un environnement d'expérimentation efficace qui peut vous aider à prendre des décisions basées sur les données et à optimiser vos taux de conversion au fil du temps.