Comment décider des événements à suivre ?

Il s'agit de la cinquième partie de la série en cinq parties sur les données client . Voici les parties un , deux , trois et quatre .

Commencez par poser des questions.

Pour décider des événements à suivre et des données à collecter, vous devez répertorier les questions que vous vous posez sur vos utilisateurs et leur utilisation du produit.

Vous vous rendrez compte qu'il y a tellement de choses que vous voulez savoir une fois que vous aurez commencé à lister vos questions. Les questions engendrent d'autres questions, et lorsque cela se produit, vous voudrez probablement obtenir toutes les réponses en même temps. En raison de la façon dont ce processus fait ressentir la plupart des gens, appelons ces questions des questions brûlantes .

Si vous ne vous sentez pas de cette façon, vous n'êtes probablement pas désireux d'en savoir beaucoup ou n'avez pas une forte conviction dans vos hypothèses. Cependant, ne laissez pas cela vous empêcher de poser des questions - vous pourriez être agréablement surpris ou complètement déçu lorsque vous découvrirez les réponses.

Il est beaucoup plus facile de poser des questions sur les données une fois que vous êtes en mesure de visualiser les données, mais cela peut également être contre-productif si vous continuez à créer des rapports ou à visualiser des données sans d'abord poser les questions brûlantes.

Questions brûlantes

Les questions brûlantes peuvent être simples comme "combien d'utilisateurs se sont inscrits au cours des 7 derniers jours ?" ou complexe comme "combien d'utilisateurs du secteur SaaS se sont inscrits au cours des 7 derniers jours et ont invité un autre utilisateur dans leur organisation ?"

Lorsque vous pensez à des questions brûlantes, il est utile de commencer à énumérer les actions suivantes :

• Actions qu'un utilisateur doit effectuer pour atteindre le moment aha (événement d'activation)
• Actions indiquant qu'un utilisateur est prêt à effectuer un achat ou à mettre à niveau un compte
• Actions qui alimentent l'engagement des utilisateurs et fidélisent un utilisateur
• Actions qui signalent qu'un utilisateur ne tire pas suffisamment de valeur du produit
• Actions susceptibles d'entraîner le désabonnement d'un utilisateur

C'est également le bon moment pour commencer à remettre en question l'expérience du produit et à réfléchir à vos offres de base. Les questions suivantes s'appliquent à la majorité des produits technologiques :

• Quel est le temps de valorisation ou combien de temps les utilisateurs mettent-ils pour atteindre le moment aha ?
• Quels sont les différents chemins empruntés par les utilisateurs après leur inscription ?
• Quels sont les points de friction dans le parcours utilisateur ?
• Quelles sont les fonctionnalités les plus utilisées par les utilisateurs actifs ?
• Quelles sont les fonctionnalités les moins utilisées par les utilisateurs payants ?
• Quelles fonctionnalités entraînent la conversion d'utilisateurs gratuits en utilisateurs payants ?

Événements et propriétés d'événement

Une fois que vous avez une liste des questions brûlantes (entre 5 et 10 est un bon nombre pour commencer), vous pouvez passer à l'étape la plus critique : définir les événements et les propriétés des événements.

C'est là que vous commencez enfin à créer un plan de suivi des données.

Outre les événements principaux, vous devez également commencer à réfléchir aux différentes données que vous souhaitez collecter lorsqu'un événement particulier a lieu. Ce guide contient des exemples d'événements courants et des propriétés associées qui fourniront un contexte sur la façon de penser à ce processus.

Il y a quelques autres choses couvertes ci-dessous que vous devez savoir avant de commencer à créer un plan de suivi.

Clics, vues et processus

Il est très important de garder à l'esprit les différences entre les clics, les vues et les processus qui se déroulent à l'intérieur de votre produit : chaque bouton cliqué, page consultée ou processus terminé peut être suivi comme un événement unique.

De plus, dans certains cas, un événement peut être suivi comme l'un des trois : une vue de page, un clic sur un bouton ou l'achèvement d'un processus.

Examinons de plus près en utilisant un flux d'inscription hypothétique :

Tout d'abord, l'utilisateur clique sur le Ici, l'événement effectué peut être suivi soit comme un clic sur un bouton (bouton d'inscription sur la page d'accueil), soit comme une vue de page (page d'inscription).

Ensuite , l'utilisateur remplit le formulaire d'inscription, clique sur le Si tout se passe bien, la soumission atteint la base de données et une nouvelle ligne est créée.

Ici, l'événement effectué peut être suivi sous la forme d'un clic sur un bouton (bouton Soumettre), d'une page vue (page de remerciement) ou d'un achèvement de processus (nouvelle ligne dans la base de données).

Par conséquent, la façon dont vous choisissez de suivre les événements dépend entièrement de vos cas d'utilisation, et parfois, il peut même être judicieux de suivre un clic sur un bouton ainsi qu'une vue de page ou l'achèvement d'un processus en même temps.

and sign up Cela dit, si votre objectif est de comprendre le comportement des utilisateurs, vous devez éviter la redondance des événements en vous assurant qu'une action de l'utilisateur n'est pas suivie plusieurs fois ( bouton d'inscription cliqué et Page consultée

. Pour suivre les pages vues, vous pouvez spécifier un événement unique pour chaque page, tel que . Cependant, cela rendra votre liste d'événements ridiculement longue lorsque vous souhaitez suivre les pages vues pour chaque page unique.

Au lieu de définir un événement distinct pour chaque page, vous pouvez spécifier un événement générique appelé Page vue avec les propriétés d'événement comme suit :

Bouton cliqué

Comme les pages vues, les clics sur les boutons doivent également être suivis via un événement générique tel que Button Clicked avec les propriétés associées comme ci-dessous :

Processus terminé

Les processus se déroulent à la suite d'une interaction avec une base de données où les données sont soit écrites (dans une table spécifique) soit récupérées (à partir d'une table) - si l'interaction échoue, le processus échoue.

Par conséquent, le suivi de l'achèvement d'un processus est le moyen le plus fiable de suivre les événements qui dépendent de l'achèvement d'une interaction avec la base de données.

Voici un scénario bien trop courant :

Un utilisateur clique sur le bouton d'envoi après avoir rempli le formulaire d'inscription uniquement pour se voir présenter une erreur de validation telle que "le mot de passe doit contenir un caractère spécial". Ici, l'utilisateur a exécuté l'événement Bouton cliqué mais n'a pas terminé le processus d'inscription.

De même, si l'utilisateur clique sur le bouton d'envoi mais qu'une erreur côté serveur se produit, le processus échoue et les données de l'utilisateur ne parviennent pas à la base de données. Ainsi, même si l'utilisateur a soumis le formulaire d'inscription avec succès, le processus d'inscription est resté incomplet.

Par conséquent, il est crucial de penser à l'ensemble du processus (ou à l'interaction avec la base de données) qui doit être complété lorsqu'un événement se produit.

De plus, vous devez également savoir si un utilisateur s'inscrit à votre produit mais ne vérifie pas son adresse e-mail. Une façon de procéder consiste à vérifier si les utilisateurs se connectent après s'être inscrits (ce qui ne peut se produire qu'après vérification de l'e-mail). Mais alors il pourrait y avoir des utilisateurs qui vérifient l'e-mail mais ne se connectent jamais.

Ainsi, une meilleure approche pourrait consister à suivre 2 événements distincts : Signed Up (processus d'inscription terminé) et Cela vous indiquera également combien de personnes se sont inscrites mais ne vérifient pas leur e-mail, ce qui vous permet de renvoyer l'e-mail de vérification après un jour ou deux.

Événements côté client et côté serveur

Les événements tels que les clics et les vues qui ne dépendent pas des interactions de la base de données (ou des processus principaux) sont essentiellement des événements côté client.

Les événements côté client ont lieu exclusivement sur le client (ou l'appareil de l'utilisateur) et sont également appelés événements frontaux.

D'autre part, les événements qui reposent sur des processus principaux sont appelés événements côté serveur. Comme son nom l'indique, les événements côté serveur ont lieu sur un serveur lorsqu'une interaction de base de données est terminée avec succès.

Les événements côté serveur sont également appelés événements backend.

Connaître la différence entre les événements côté client et côté serveur aide dans le processus d'instrumentation car les deux types d'événements sont généralement mis en œuvre par différentes personnes dans une organisation.

Il est toujours utile de spécifier la source de l'événement dans votre plan de suivi, même si un développeur full-stack est chargé de la mise en œuvre des deux types d'événements.

Étapes suivantes du suivi des événements

Cela nous amène à la fin de la série en cinq parties sur les données client. Pour commencer à suivre vos événements dès aujourd'hui, lancez-vous avec un compte Amplitude gratuit.