Au lancement de DataLab, nous avons tout mis en œuvre pour offrir la meilleure expérience possible pour les travaux de science des données et d’analytique. Cela passait par un éditeur rapide et léger, la collaboration en temps réel et la production de rapports professionnels en lecture seule.
En parallèle, nous nous appuyions sur des outils tiers pour nos analyses internes. Des métriques produit comme le nombre d’utilisateurs de DataLab et le temps passé sur la plateforme étaient suivies avec d’autres solutions. Nous avons compris que si nous voulions faire de DataLab un véritable outil de travail professionnel, nous devions l’utiliser nous-mêmes.
Cet article revient sur notre manière de conduire les analyses internes auparavant et sur notre transition vers DataLab. Nous partageons également les avantages et les enseignements tirés de ce changement.
Nos analyses avant DataLab
Avant DataLab, notre principal outil d’analytique interne sur le produit était Metabase. Metabase est un outil de business intelligence connecté à un data lake contenant des informations sur le contenu et l’activité de DataLab. Avec Metabase, nous pouvions exécuter rapidement des requêtes SQL, générer des rapports et même créer des tableaux de bord dynamiques.
Metabase était largement utilisé par l’équipe. Nous l’employions pour suivre l’engagement des utilisateurs selon les types de contenu, le temps passé dans Workspace et le nombre d’utilisateurs actifs au quotidien, chaque semaine et chaque mois.
À cette époque, utiliser DataLab pour nos analyses restait peu fréquent. Nous y avions recours uniquement lorsque nous atteignions les limites de SQL ou des capacités de visualisation no-code de Metabase. Dans ces cas, nous exportions les données brutes, les ajoutions manuellement à un nouveau carnet et poursuivions l’analyse en Python. Mais ce processus était lourd et les mises à jour des données devenaient fastidieuses.
Pourquoi nous avons basculé vers DataLab
À mesure que DataLab s’est développé, les questions que nous voulions adresser sur nos utilisateurs et leur usage de DataLab se sont complexifiées. Aussi pratique que soit Metabase, bon nombre de nos analyses nécessitaient les outils supplémentaires offerts par Python et R.
Nous savions aussi que pour proposer la meilleure expérience possible, nous devions nous appliquer la même exigence en interne, une pratique souvent appelée « dogfooding ». En effet, quoi de mieux pour cerner les limites et les frustrations de DataLab que de l’utiliser au quotidien ?
Pour ces deux raisons, nous nous sommes fixé pour objectif, à l’été 2022, de transférer l’essentiel de nos analyses de Metabase vers DataLab.
La transition
La transition a commencé avec le lancement des cellules SQL dans DataLab. Nous pouvions interroger les mêmes données qu’avec Metabase, mais avec des résultats instantanément convertis en DataFrame Python ou R (selon l’outil utilisé). Il devenait facile d’alterner entre la requête sur notre base et l’analyse des résultats avec les outils de notre choix. En quelques semaines, nous avons migré la plupart de nos requêtes existantes de Metabase vers DataLab.
Au moment où nous écrivons ces lignes, 141 utilisateurs DataCamp différents ont passé 30 minutes ou plus dans DataLab. Comme le montre le graphique, la progression a été régulière !
Nous recrutons en continu de nouveaux DataCampers dans DataLab !
Les avantages du passage à DataLab
Depuis notre passage à DataLab, nous avons identifié plusieurs avantages clés au quotidien :
- Visualisations entièrement personnalisables : Metabase propose de nombreuses visualisations et options, mais leurs possibilités restent limitées. Avec DataLab, les résultats de nos requêtes SQL sont renvoyés sous forme de DataFrames. Nous pouvons ainsi utiliser des bibliothèques Python comme Plotly pour créer des graphiques avec annotations, thèmes personnalisés et types de visualisations avancés.
Exemple de visualisation créée dans DataLab à partir de nos données internes.
- Analyses avancées : En combinant SQL avec Python ou R, nous analysons instantanément nos données avec des techniques impossibles à réaliser uniquement en SQL. Cela nous a permis, par exemple, de segmenter nos utilisateurs et d’entraîner des modèles de classification pour prédire leurs usages de DataLab.
- Rapports descriptifs : Un tableau de bord convient parfaitement aux utilisateurs familiers du produit, mais il peut être difficile à interpréter pour les nouveaux venus ou des parties prenantes externes à l’équipe. Avec DataLab, nous pouvons intégrer des synthèses rédigées tout au long de nos rapports, lisibles ensuite par les décideurs concernés.
- Publications partageables et collaboratives : La possibilité de partager un lien vers un carnet publié est extrêmement précieuse. Certaines analyses publiées se retrouvent entre les mains de notre CEO et d’autres dirigeants, qui ajoutent leurs retours sous forme de commentaires et de questions. Combiné au caractère descriptif des carnets publiés, cela permet à la direction de parcourir les analyses à son rythme, sans brief en présentiel.
- Graphiques sans code : La plupart des DataCampers maîtrisent SQL, mais tout le monde n’est pas aussi à l’aise en Python ou R. Les cellules de graphiques permettent aux profils moins techniques de partager leurs insights avec des visualisations de qualité, sans écrire une ligne de code.
Nos cellules de graphiques no-code en action !
Ce que nous avons appris jusqu’ici
À la mi-octobre, les DataCampers totalisaient 4 132 heures passées dans DataLab ! Nous avons désormais migré tous les reportings centraux liés aux objectifs trimestriels et à l’usage produit vers DataLab. Voici les principaux enseignements et leur impact sur DataLab :
- La vitesse est essentielle : Attendre plus longtemps que prévu le chargement d’un carnet, l’exécution d’un code ou le retour d’une requête est frustrant. L’expérience doit être au moins aussi rapide, idéalement plus, qu’un Jupyter Notebook local. Notre équipe a considérablement réduit les temps de chargement des notebooks et des publications, et s’est assurée que l’exécution du code soit comparable à celle d’un notebook local.
- Tout le monde ne veut pas voir le code : Par le passé, nos publications contenaient de grandes cellules pleines de requêtes SQL complexes et de code Python dense. Utile pour la relecture technique par les collègues, cela masquait souvent l’essentiel : les insights. On pouvait déjà masquer des cellules en passant à l’éditeur JupyterLab dans DataLab, mais ce n’était pas reflété dans l’éditeur DataCamp Notebook. Forts de ce constat, nous avons publié une fonctionnalité pour masquer en toute simplicité le code et les cellules SQL dans vos carnets. Vous pouvez ainsi partager un rapport en lecture seule soigné avec toute partie prenante. Nos utilisateurs adorent.
- Relancer les notebooks peut être pénible : Une grande partie de notre suivi repose sur des mises à jour quotidiennes du nombre d’utilisateurs, des niveaux d’activité et de l’adoption des fonctionnalités. Contrairement à un tableau de bord dynamique qui se rafraîchit dès que de nouvelles données sont disponibles, les carnets doivent être relancés à chaque fois. À partir de cette expérience, nous prévoyons de prendre en charge la planification de l’exécution des carnets, pour garantir que les rapports contiennent toujours les informations les plus récentes.
À cela s’ajoutent de nombreux ajustements mineurs apportés à l’éditeur depuis notre bascule vers DataLab. L’interface, le tableau de bord et des fonctionnalités comme les cellules de graphiques font l’objet d’améliorations continues, guidées par les retours des utilisateurs, internes comme externes.
La suite
Si l’usage de notre propre produit a mis en lumière de nombreuses pistes d’amélioration, cela ne représente que la moitié de l’histoire. En complément des retours internes, notre équipe mène des entretiens avec des utilisateurs de DataLab. Ces échanges enrichissent nos constats et nous aident à repérer ce qui peut nous échapper lors des tests en interne.
Nous avons également lancé fin septembre une enquête utilisateur dans notre newsletter bimensuelle. Elle nous a permis de collecter des données quantitatives. Ces résultats nous aident à prioriser les chantiers clés pour DataLab et à mieux comprendre les usages du produit. Et bien sûr, les données de l’enquête ont été analysées et visualisées avec DataLab !
La principale raison évoquée par nos utilisateurs pour recourir à DataLab est de tester rapidement des extraits de code. Et vous, comment utilisez-vous DataLab ?
Dans les prochains mois, nous prévoyons d’aller encore plus loin vers un environnement analytique 100 % DataLab. Chaque nouvelle fonctionnalité et amélioration apportée par notre équipe d’ingénierie rend cette transition plus simple.
Si vous souhaitez utiliser DataLab pour vos propres besoins en analytique et en science des données internes, vous trouverez plus d’informations ici. Ou mieux encore, ouvrez un carnet Python ou R vierge et commencez à coder dès maintenant !