Il existe des centaines d'articles sur Internet sur les avantages de l'analyse du comportement des clients. Cela concerne le plus souvent le secteur du commerce de détail. De l'analyse du panier alimentaire, de l'analyse ABC et XYZ au marketing de fidélisation et aux offres personnelles. Diverses techniques sont utilisées depuis des décennies, les algorithmes ont été pensés, le code a été écrit et débogué - prenez-le et utilisez-le. Dans notre cas, un problème fondamental s'est posé : chez ISPsystem, nous sommes engagés dans le développement de logiciels, pas dans la vente au détail.
Je m'appelle Denis et je suis actuellement responsable du backend des systèmes analytiques chez ISPsystem. Et voici l'histoire de la façon dont mon collègue et moi — les responsables de la visualisation des données — ont tenté d'examiner nos produits logiciels à travers le prisme de ces connaissances. Commençons, comme d'habitude, par l'histoire.
Au début, il y avait un mot, et le mot était « Allons-nous essayer ? »
À cette époque, je travaillais en tant que développeur dans le département R&D. Tout a commencé quand Danil a lu ici sur Habré — un outil d'analyse des transitions des utilisateurs dans les applications. J'étais quelque peu sceptique quant à l'idée de l'utiliser ici. À titre d'exemple, les développeurs de la bibliothèque ont cité une analyse d'applications où l'action cible était clairement définie - passer une commande ou une autre variante du mode de paiement de l'entreprise propriétaire. Nos produits sont fournis sur place. Autrement dit, l'utilisateur achète d'abord une licence et commence ensuite seulement son parcours dans l'application. Oui, nous avons des versions de démonstration. Vous pouvez essayer le produit là-bas pour ne pas avoir un cochon dans un sac.
Mais la plupart de nos produits sont destinés au marché de l’hébergement. Il s'agit de gros clients et le service de développement commercial les conseille sur les capacités des produits. Il s'ensuit également qu'au moment de l'achat, nos clients savent déjà quels problèmes notre logiciel les aidera à résoudre. Leurs parcours dans l'application doivent coïncider avec le CJM intégré au produit, et les solutions UX les aideront à rester sur la bonne voie. Spoiler : cela n’arrive pas toujours. L'introduction à la bibliothèque a été reportée... mais pas pour longtemps.
Tout a changé avec la sortie de notre startup - — plateformes de création d'une boutique en ligne à partir d'un compte Instagram. Dans cette application, l’utilisateur disposait d’un délai de deux semaines pour utiliser gratuitement toutes les fonctionnalités. Ensuite, il fallait décider de s'abonner ou non. Et cela s’inscrit parfaitement dans le concept « action route-cible ». C'était décidé : essayons !
Premiers résultats ou où puiser des idées
L'équipe de développement et moi avons connecté le produit au système de collecte d'événements littéralement en une journée. Je dirai tout de suite qu'ISPsystem utilise son propre système pour collecter les événements liés aux visites de pages, mais rien ne vous empêche d'utiliser Yandex.Metrica aux mêmes fins, ce qui vous permet de télécharger gratuitement des données brutes. Des exemples d'utilisation de la bibliothèque ont été étudiés et après une semaine de collecte de données, nous avons reçu un graphique de transition.
Graphique de transition. Fonctionnalité de base, autres transitions supprimées pour plus de clarté
Cela s'est avéré comme dans l'exemple : planaire, clair, beau. À partir de ce graphique, nous avons pu identifier les itinéraires et les passages les plus fréquents où les gens passent le plus de temps. Cela nous a permis de comprendre les éléments suivants :
- Au lieu d’un grand CJM, qui couvre une douzaine d’entités, seules deux sont activement utilisées. Il est nécessaire en outre de diriger les utilisateurs vers les endroits dont nous avons besoin à l'aide de solutions UX.
- Certaines pages, conçues par les concepteurs UX pour être de bout en bout, finissent par que les gens y consacrent un temps déraisonnable. Vous devez déterminer quels sont les éléments d'arrêt sur une page spécifique et les ajuster.
- Après 10 transitions, 20 % des personnes ont commencé à se fatiguer et à quitter la séance dans l'application. Et cela en tenant compte du fait que nous avions jusqu'à 5 pages d'intégration dans l'application ! Vous devez identifier les pages sur lesquelles les utilisateurs abandonnent régulièrement les sessions et raccourcir le chemin d'accès à celles-ci. Mieux encore : identifiez les itinéraires réguliers et permettez une transition rapide de la page source à la page de destination. Quelque chose en commun avec l’analyse ABC et l’analyse des paniers abandonnés, vous ne trouvez pas ?
Et ici, nous avons reconsidéré notre attitude quant à l'applicabilité de cet outil aux produits sur site. Il a été décidé d'analyser un produit activement vendu et utilisé - . C'est beaucoup plus complexe, il y a un ordre de grandeur plus d'entités. Nous attendions avec impatience de voir quel serait le graphique de transition.
À propos des déceptions et des inspirations
Déception #1
C'était à la fois la fin de la journée de travail, la fin du mois et la fin de l'année - le 27 décembre. Des données ont été accumulées, des requêtes ont été écrites. Il restait quelques secondes avant que tout soit traité et nous puissions examiner le résultat de notre travail pour savoir où commencerait la prochaine année de travail. Le service R&D, le chef de produit, les designers UX, le chef d'équipe, les développeurs se sont rassemblés devant le moniteur pour voir à quoi ressemblent les parcours utilisateurs dans leur produit, mais... nous avons vu ceci :
Graphique de transition construit par la bibliothèque Retentioneering
Inspiration n°1
Fortement connecté, des dizaines d’entités, des scénarios non évidents. Il était clair que la nouvelle année de travail ne commencerait pas par une analyse, mais par l'invention d'un moyen de simplifier le travail avec un tel graphique. Mais je ne pouvais pas m’empêcher de penser que tout était beaucoup plus simple qu’il n’y paraissait. Et après quinze minutes d'étude du code source de Retentioneering, nous avons pu exporter le graphique construit au format points. Cela a permis de télécharger le graphique sur un autre outil - Gephi. Et il est déjà possible d'analyser des graphiques : mises en page, filtres, statistiques - il suffit de configurer les paramètres nécessaires dans l'interface. C'est avec cette pensée en tête que nous sommes partis pour le week-end du Nouvel An.
Déception #2
Après le retour au travail, il s'est avéré que pendant que tout le monde se reposait, nos clients étudiaient le produit. Oui, si fort que des événements qui n'existaient pas auparavant sont apparus dans le stockage. Cela signifiait que les requêtes devaient être mises à jour.
Un peu de contexte pour comprendre la tristesse de ce fait. Nous transmettons à la fois les événements que nous avons marqués (par exemple, les clics sur certains boutons) et les URL des pages visitées par l'utilisateur. Dans le cas de Cartbee, le modèle « une action – une page » a fonctionné. Mais avec VMmanager, la situation était complètement différente : plusieurs fenêtres modales pouvaient s'ouvrir sur une seule page. En eux, l'utilisateur pourrait résoudre divers problèmes. Par exemple, URL :
/host/item/24/ip(modal:modal/host/item/ip/create)
signifie que sur la page « Adresses IP », l'utilisateur a ajouté une adresse IP. Et ici, deux problèmes sont visibles à la fois :
- L'URL contient une sorte de paramètre de chemin - l'ID de la machine virtuelle. Il faut l'exclure.
- L'URL contient l'ID de la fenêtre modale. Vous devez d'une manière ou d'une autre « décompresser » ces URL.
Un autre problème était que les événements que nous marquions avaient des paramètres. Par exemple, il existait cinq manières différentes d'accéder à la page contenant des informations sur une machine virtuelle de la liste. En conséquence, un événement a été envoyé, mais avec un paramètre indiquant la méthode par laquelle l'utilisateur a effectué la transition. Il y a eu de nombreux événements de ce type et tous les paramètres étaient différents. Et nous avons toute la logique de récupération de données dans le dialecte SQL pour Clickhouse. Les requêtes de 150 à 200 lignes commençaient à paraître quelque peu banales. Des problèmes nous entouraient.
Inspiration n°2
Un matin, Danil, parcourant tristement la requête de la deuxième minute, m'a proposé : « Écrivons des pipelines de traitement de données ? Nous y avons réfléchi et avons décidé que si nous devions le faire, ce serait quelque chose comme ETL. Pour qu'il filtre immédiatement et récupère les données nécessaires provenant d'autres sources. C'est ainsi qu'est né notre premier service analytique avec un backend à part entière. Il met en œuvre cinq étapes principales de traitement des données :
- Décharger les événements du stockage de données brutes et les préparer pour le traitement.
- La clarification est le « déballage » de ces mêmes identifiants de fenêtres modales, paramètres d'événement et autres détails qui clarifient l'événement.
- L'enrichissement (du mot « devenir riche ») est l'ajout d'événements avec des données provenant de sources tierces. À cette époque, cela incluait uniquement notre système de facturation BILLmanager.
- Le filtrage est le processus de filtrage des événements qui faussent les résultats de l'analyse (événements provenant de peuplements internes, valeurs aberrantes, etc.).
- Téléchargement des événements reçus dans le stockage, que nous appelons données propres.
Il était désormais possible de conserver la pertinence en ajoutant des règles de traitement d'un événement ou même de groupes d'événements similaires. Par exemple, depuis lors, nous n’avons jamais mis à jour le déballage des URL. Cependant, pendant cette période, plusieurs nouvelles variantes d'URL ont été ajoutées. Ils respectent les règles déjà fixées dans le service et sont traités correctement.
Déception #3
Une fois que nous avons commencé l’analyse, nous avons compris pourquoi le graphique était si cohérent. Le fait est que presque tous les N-grammes contenaient des transitions qui ne pouvaient pas être effectuées via l'interface.
Une petite enquête a commencé. J'étais confus quant au fait qu'il n'y avait pas de transitions impossibles au sein d'une même entité. Cela signifie qu'il ne s'agit pas d'un bug dans le système de collecte d'événements ou dans notre service ETL. On avait le sentiment que l'utilisateur travaillait simultanément dans plusieurs entités, sans passer de l'une à l'autre. Comment y parvenir ? Utilisation de différents onglets du navigateur.
Lors de l’analyse de Cartbee, nous avons été sauvés par sa spécificité. L'application a été utilisée à partir d'appareils mobiles, où travailler à partir de plusieurs onglets n'est tout simplement pas pratique. Ici, nous avons un bureau et pendant qu'une tâche est effectuée dans une entité, il est raisonnable de vouloir passer ce temps à configurer ou à surveiller le statut dans une autre. Et pour ne pas perdre votre progression, ouvrez simplement un autre onglet.
Inspiration n°3
Des collègues du développement front-end ont appris au système de collecte d'événements à distinguer les onglets. L'analyse pourrait commencer. Et nous avons commencé. Comme prévu, CJM ne correspondait pas aux chemins réels : les utilisateurs passaient beaucoup de temps sur les pages d'annuaire, les sessions abandonnées et les onglets aux endroits les plus inattendus. Grâce à l'analyse de transition, nous avons pu détecter des problèmes dans certaines versions de Mozilla. Dans ceux-ci, en raison des fonctionnalités d'implémentation, des éléments de navigation ont disparu ou des pages à moitié vides ont été affichées, qui ne devraient être accessibles qu'à l'administrateur. La page s'est ouverte, mais aucun contenu ne provenait du backend. Le comptage des transitions a permis d'évaluer quelles fonctionnalités étaient réellement utilisées. Les chaînes permettaient de comprendre comment l'utilisateur recevait telle ou telle erreur. Les données ont permis des tests basés sur le comportement des utilisateurs. Ce fut un succès, l'idée n'était pas vaine.
Automatisation des analyses
Dans l'une des démonstrations des résultats, nous avons montré comment Gephi est utilisé pour l'analyse graphique. Dans cet outil, les données de conversion peuvent être affichées dans un tableau. Et le chef du département UX a déclaré une pensée très importante qui a influencé le développement de l'ensemble de la direction de l'analyse comportementale dans l'entreprise : « Faisons la même chose, mais dans Tableau et avec des filtres, ce sera plus pratique.
Puis j'ai pensé : pourquoi pas, Retentioneering stocke toutes les données dans une structure pandas.DataFrame. Et ceci est, en gros, une table. C'est ainsi qu'est apparu un autre service : Data Provider. Il a non seulement créé un tableau à partir du graphique, mais a également calculé la popularité de la page et les fonctionnalités qui y sont associées, son impact sur la rétention des utilisateurs, la durée pendant laquelle les utilisateurs y restent et les pages que les utilisateurs quittent le plus souvent. Et l'utilisation de la visualisation dans Tableau a tellement réduit le coût d'étude du graphique que le temps d'itération pour l'analyse du comportement dans le produit a été presque divisé par deux.
Danil expliquera comment cette visualisation est utilisée et quelles conclusions elle permet de tirer.
Plus de tables pour le dieu de la table !
Sous une forme simplifiée, la tâche a été formulée comme suit : afficher le graphique de transition dans Tableau, offrir la possibilité de filtrer et le rendre aussi clair et pratique que possible.
Je ne voulais pas vraiment dessiner un graphique orienté dans Tableau. Et même en cas de succès, le gain, par rapport à Gephi, ne semblait pas évident. Il nous fallait quelque chose de beaucoup plus simple et plus accessible. Tableau! Après tout, le graphique peut être facilement représenté sous forme de lignes de tableau, où chaque ligne est une arête de type « source-destination ». De plus, nous avons déjà soigneusement préparé un tel tableau à l’aide des outils Retentioneering et Data Provider. Il ne restait plus qu'à afficher le tableau dans Tableau et à fouiller dans le rapport.
En parlant de la façon dont tout le monde aime les tables.
Cependant, nous sommes ici confrontés à un autre problème. Que faire de la source de données ? Il était impossible de connecter pandas.DataFrame ; Tableau ne dispose pas d'un tel connecteur. Créer une base distincte pour stocker le graphique semblait une solution trop radicale avec des perspectives vagues. Et les options de déchargement local n’étaient pas adaptées en raison de la nécessité d’opérations manuelles constantes. Nous avons parcouru la liste des connecteurs disponibles et notre regard s'est posé sur l'élément , qui se blottit désespérément tout en bas.
Tableau propose une riche sélection de connecteurs. Nous en avons trouvé un qui a résolu notre problème
Quel genre d'animal ? Quelques nouveaux onglets ouverts dans le navigateur - et il est devenu clair que ce connecteur vous permet de recevoir des données lors de l'accès à une URL. Le backend lui-même pour calculer les données était presque prêt, il ne restait plus qu'à le lier d'amitié avec WDC. Pendant plusieurs jours, Denis a étudié la documentation et s'est battu avec les mécanismes de Tableau, puis m'a envoyé un lien que j'ai collé dans la fenêtre de connexion.
Formulaire de connexion à notre WDC. Denis a fait sa façade et a veillé à la sécurité
Après quelques minutes d'attente (les données sont calculées dynamiquement sur demande), le tableau apparaît :
Voici à quoi ressemble un tableau de données brutes dans l'interface Tableau
Comme promis, chaque ligne d'un tel tableau représentait un bord du graphique, c'est-à-dire une transition dirigée de l'utilisateur. Il contenait également plusieurs caractéristiques supplémentaires. Par exemple, le nombre d'utilisateurs uniques, le nombre total de transitions, etc.
Il serait possible d'afficher ce tableau dans le rapport tel quel, de saupoudrer généreusement de filtres et de faire naviguer l'outil. Cela semble logique. Que pouvez-vous faire avec la table ? Mais ce n'est pas notre façon de faire, car nous ne créons pas seulement un tableau, mais un outil d'analyse et de prise de décision concernant les produits.
En règle générale, lors de l'analyse des données, une personne souhaite obtenir des réponses à ses questions. Super. Commençons par eux.
- Quelles sont les transitions les plus fréquentes ?
- Où vont-ils à partir de pages spécifiques ?
- Combien de temps passez-vous en moyenne sur cette page avant de la quitter ?
- À quelle fréquence effectuez-vous la transition de A à B ?
- Sur quelles pages se termine la session ?
Chacun des rapports ou une combinaison d'entre eux doit permettre à l'utilisateur de trouver indépendamment des réponses à ces questions. La stratégie clé ici est de vous donner les outils nécessaires pour le faire vous-même. Ceci est utile à la fois pour réduire la charge du service d'analyse et pour réduire le temps de prise de décision - après tout, vous n'avez plus besoin d'aller sur Youtrack et de créer une tâche pour l'analyste, il vous suffit d'ouvrir le rapport.
Qu'avons-nous obtenu ?
Où les gens s’écartent-ils le plus souvent du tableau de bord ?
Fragment de notre rapport. Après le tableau de bord, tout le monde est allé soit sur la liste des VM, soit sur la liste des nœuds
Prenons un tableau général avec des transitions et filtrons par page source. Le plus souvent, ils passent du tableau de bord à la liste des machines virtuelles. De plus, la colonne Régularité suggère qu'il s'agit d'une action répétitive.
D'où viennent-ils dans la liste des clusters ?
Les filtres dans les rapports fonctionnent dans les deux sens : vous pouvez savoir où vous êtes parti ou où vous êtes allé.
D'après les exemples, il ressort clairement que même la présence de deux filtres simples et d'un classement des lignes par valeurs vous permet d'obtenir rapidement des informations.
Demandons quelque chose de plus compliqué.
Où les utilisateurs abandonnent-ils le plus souvent leur session ?
Les utilisateurs de VMmanager travaillent souvent dans des onglets séparés
Pour ce faire, nous avons besoin d'un rapport dont les données sont agrégées par sources de référence. Et les soi-disant points d'arrêt étaient considérés comme des tâches - des événements qui servaient de fin à la chaîne de transitions.
Il est important de noter ici qu'il peut s'agir soit de la fin de la session, soit de l'ouverture d'un nouvel onglet. L'exemple montre que la chaîne se termine le plus souvent par une table avec une liste de machines virtuelles. Dans ce cas, le comportement caractéristique passe à un autre onglet, ce qui est cohérent avec le modèle attendu.
Nous avons tout d’abord testé sur nous-mêmes l’utilité de ces rapports en effectuant l’analyse de manière similaire , un autre de nos produits. Avec l’avènement des tableaux et des filtres, les hypothèses ont été testées plus rapidement et les yeux étaient moins fatigués.
Lors de l'élaboration des rapports, nous n'avons pas oublié la conception visuelle. Lorsque vous travaillez avec des tables de cette taille, c'est un facteur important. Par exemple, nous avons utilisé une gamme de couleurs calmes, faciles à percevoir pour les nombres, mise en évidence des couleurs des lignes en fonction des valeurs numériques des caractéristiques. De tels détails améliorent l’expérience utilisateur et augmentent les chances de succès de l’outil au sein de l’entreprise.
Le tableau s'est avéré assez volumineux, mais nous espérons qu'il n'a pas cessé d'être lisible
Il convient de mentionner séparément la formation de nos clients internes : spécialistes produits et concepteurs UX. Des manuels contenant des exemples d'analyse et des conseils pour travailler avec des filtres ont été spécialement préparés pour eux. Nous avons inséré des liens vers des manuels directement dans les pages du rapport.
Nous avons réalisé le manuel simplement sous forme de présentation dans Google Docs. Les outils Tableau vous permettent d'afficher des pages Web directement dans un classeur de rapport.
au lieu d'un épilogue
Qu’y a-t-il en fin de compte ? Nous avons pu obtenir un outil pour chaque jour relativement rapidement et à moindre coût. Oui, cela ne remplace certainement pas le graphique lui-même, la carte thermique des clics ou la visionneuse Web. Mais de tels rapports complètent de manière significative les outils répertoriés et fournissent des éléments de réflexion et de nouvelles hypothèses sur les produits et les interfaces.
Cette histoire n'a servi que de début au développement de l'analyse dans le système ISP. Au cours des six derniers mois, sept nouveaux services supplémentaires sont apparus, notamment des portraits numériques de l'utilisateur dans le produit et un service de création de bases de données pour le ciblage par sosie, mais nous en parlerons dans les épisodes suivants.
Source: habr.com