Comment nous construisons des expériences en interne

L’expérimentation et l’analyse des expériences sont des procédures vitales chez Canva pour protéger l’expérience client. L’expérimentation est un outil de prise de décision inestimable, et chez Canva, c’est une étape cruciale dans notre processus de développement de produit pour tester rapidement des idées, mesurer l’impact et protéger l’expérience client de plus de 100 millions d’utilisateurs actifs mensuels. Nous divisons nos plateformes d’expérimentation en 2 composantes principales :

• Configuration de l’expérience : Création de drapeaux de fonctionnalités et d’assignations.
• Analyse de l’expérience : Mesurer l’impact du changement.

Dans ce billet de blog, nous plongerons dans la manière dont la deuxième composante, l’analyse de l’expérience, a évolué au cours des dernières années pour soutenir une croissance de 10 fois du nombre de data scientists et devenir un outil central dans l’architecture de données de Canva.

Informations de base

Chez Canva, l’expérimentation avec notre produit a toujours fait partie de notre parcours. Cependant, ce n’est qu’en 2019 que notre spécialité en science des données a développé la première version de notre cadre d’analyse d’expérience : un package Python où tout data scientist pouvait définir des métriques partagées et créer des configurations d’analyse. Nous pouvions calculer les résultats et les visualiser via une interface en ligne de commande.

Nous avions immédiatement une manière standardisée de calculer et d’interpréter les résultats à travers l’entreprise. De plus, le package calculait automatiquement des métriques de garde, nous permettant de surveiller l’impact d’une expérience sur les objectifs de l’entreprise, tels que les utilisateurs actifs ou le chiffre d’affaires.

C’était un premier pas incroyable, mais nous avons rapidement découvert que partager des captures d’écran via Slack ou Confluence était fastidieux. Nous capturions les résultats à un moment donné, et les data scientists devaient retraiter manuellement les résultats chaque fois qu’un intervenant demandait.

Pour résoudre ce problème, nous avons créé une application web Django pour planifier des mises à jour quotidiennes et fournir une interface pour partager les résultats d’analyse à travers l’entreprise. Nous continuions à créer et stocker des métriques et des configurations d’analyse dans le package Python, mais nous persistions désormais les résultats dans une base de données. Les intervenants pouvaient naviguer vers une interface utilisateur pour voir des résultats à jour quand ils le souhaitaient.

La manière dont nous présentions les résultats en ligne de commande fonctionnait assez bien jusqu’à présent, donc la façon dont nous les affichions dans l’application web n’était pas radicalement différente.

Au fil du temps, pour soutenir notre produit chinois en pleine croissance (canva.cn) et respecter les réglementations en matière de données, nous avons déployé une deuxième instance de l’application Django pour fonctionner en Chine. Avoir 2 applications signifiait que pour les expériences lancées à la fois sur canva.com et canva.cn, les intervenants devaient visiter les deux applications pour voir les résultats. Clairement, ce n’était pas une situation idéale.

Les gens commençaient à ressentir les douleurs de croissance de ce système :

• Les data scientists passaient beaucoup de temps sur la saisie de données et la configuration des analyses. Seuls ceux ayant les bonnes autorisations d’accès à l’entrepôt de données pouvaient valider et exécuter des analyses ad hoc.
• Les ingénieurs et les chefs de produit ne pouvaient pas se servir et explorer pourquoi une métrique particulière ne se comportait pas comme prévu. Au lieu de cela, ils devaient rencontrer leur data scientist (s’ils avaient la chance d’en avoir un) et itérer sur les données ensemble.
• L’intégration de nouveaux data scientists était longue et difficile. Ils devaient être familiers avec les outils en ligne de commande, GitHub et le formatage des fichiers YAML. Des fichiers YAML mal formatés signifiaient qu’ils devaient également apprendre à lire et déboguer les messages d’erreur Python. Il fallait souvent des mois à un nouveau data scientist pour se sentir à l’aise pour mener des analyses d’expérience.
• L’ampleur de la croissance de Canva signifiait que le nombre d’analyses continuait de croître, mettant à rude épreuve le système de sorte que les résultats n’étaient pas toujours à jour. Les intervenants étaient frustrés car ils se sentaient bloqués par les données. Les data scientists étaient frustrés car ils devaient calculer les résultats en dehors de la plateforme pour permettre des décisions plus rapides.

La confiance dans la plateforme s’érodait.

Évolution - Passer le relais à l’ingénierie

Jusqu’à présent, le cadre d’analyse d’expérience avait été construit et maintenu par des data scientists indépendamment de notre produit interne de drapeaux de fonctionnalités et d’assignations, Feature Control.

Il est devenu évident que pour élever Canva au rang d’organisation de classe mondiale axée sur les données, nous avions besoin d’analyses d’expérience fiables, dignes de confiance et accessibles à tous. Nous avons donc confié le cadre à une équipe d’ingénierie dédiée pour le réécrire et l’intégrer dans Feature Control.

La refonte a entraîné les améliorations suivantes :

• Nous créons et exécutons des configurations d’analyse à la demande via une interface à laquelle chaque Canvanaut peut accéder. Tout le monde dans l’entreprise peut exécuter une analyse d’expérience et explorer ses résultats.
• Tout le flux utilisateur d’expérimentation, de la création de drapeaux de fonctionnalités et de l’assignation d’utilisateurs à de nouvelles fonctionnalités, à l’examen de l’impact pour les utilisateurs mondiaux et chinois, se trouve au même endroit. Cela donne aux Canvanauts un outil de moins à se soucier et garantit que tous les utilisateurs de Canva reçoivent la même excellente expérience produit.

Le nouveau système comporte également de nombreux points forts techniques. Le premier était de regrouper des modèles statistiques d’expérience dans une bibliothèque Python, déployée en tant que lambda AWS. Cela a bien fonctionné car Python est intrinsèquement supérieur pour la modélisation statistique, facilitant aux data scientists d’apporter des modifications aux modèles de production. Un effet secondaire agréable de l’utilisation d’une lambda est qu’elle expose une API pour que les utilisateurs puissent l’appeler et l’utiliser pour des analyses ad hoc en dehors de notre plateforme.

Cette nouvelle architecture ressemble également et est écrite à la qualité d’un service produit standard Canva. Elle utilise les mêmes langages et infrastructures (Javascript, Java et MySQL), avec des alertes et un planning d’astreinte pour garantir un temps d’arrêt minimal.

Nous avons également lancé un programme d’éducation sur les aspects théoriques et pratiques de l’expérimentation, tels que la compréhension de nos modèles statistiques, la prise de décision et le débogage des problèmes. Ce programme a été essentiel pour autonomiser les Canvanauts à résoudre eux-mêmes leurs problèmes de données et a entraîné une baisse de plus de 50 % des demandes d’aide dans notre canal Slack d’équipe.

Notre architecture actuelle

Jusqu’à présent, nous n’avons construit que la moitié des fondations d’une excellente plateforme d’analyse d’expérience. Les composants de configuration d’analyse, tels que les métriques, sont toujours définis à l’aide de fragments SQL partiels, que nous voulons écrire d’une manière très spécifique. Les fragments SQL sont flexibles et permettent une construction rapide de nouvelles métriques, et ont fonctionné lorsque les data scientists configuraient les analyses d’expérience. Cependant, ils sont sujets aux erreurs et presque impossibles à écrire pour les utilisateurs non techniques, ce qui entraîne des métriques excessivement complexes et statistiquement invalides. Les fragments SQL ne sont pas évolutifs.

Dans notre dernière étape, nous voulions rendre les analyses d’expérience accessibles à tous et encourager tout le monde à expérimenter en utilisant les meilleures pratiques. Pour ce faire, nous avons complètement repensé la manière dont les utilisateurs créent les composants de leur analyse d’expérience pour avoir une interface de point-and-click qui abstrait le SQL de la plupart des flux utilisateur. Cette approche garantit que toutes les métriques sont cohérentes, correctes et statistiquement valides.

Sur le plan technique, nous stockons et gérons ces composants dans un microservice séparé. Cela nous permet de les utiliser facilement dans d’autres applications futures, telles que des analyses ad hoc ou des outils de business intelligence.

Dernières réflexions et perspectives

La plateforme d’expérimentation chez Canva a subi une transformation incroyable au cours des dernières années, et nous ne faisons que commencer. Nous nous concentrons sur la poursuite de l’accessibilité de l’expérimentation pour tous chez Canva. Certains de nos projets à venir incluent la rationalisation des flux de travail désormais fragmentés avec la configuration d’expériences et les analyses d’expériences, et l’amélioration continue de l’apprentissage des résultats d’expérience au sein de la plateforme.

Remerciements

Un grand merci à l’équipe actuelle des Expériences pour avoir apporté d’énormes améliorations dans la démocratisation de l’analyse d’expérience. En particulier, merci aux ingénieurs de l’équipe originale de Feature Control : , , , , , et pour avoir reconstruit les fondations d’ingénierie de notre plateforme d’analyse d’expérience. De plus, un merci spécial à notre spécialité en science des données, qui ont rédigé, maintenu et formé l’équipe d’ingénierie et l’ensemble de l’entreprise sur notre cadre d’analyse d’expérience. Vos contributions ont été inestimables pour façonner et faire progresser nos capacités.

Plus de Canva Engineering

Pour en savoir plus sur les projets d’ingénierie de Canva, consultez notre blog.

Source de l’article