Une notification de création de compte fait plaisir. Elle ne prouve pourtant pas grand-chose sur l’usage du produit.
Pour un produit d’analyse, quelqu’un peut créer un compte, ajouter un site Web, copier un script et ne jamais voir de visite depuis son propre site. Considérer la première étape comme un succès cache tout le travail entre l’inscription et l’obtention de quelque chose d’utile.
Notre audit d’activation de juillet a commencé avec cet écart. Les notes de travail suggèrent qu’environ la moitié des comptes gratuits nominaux n’ont pas créé de site Web. Ces notes précisaient toutefois que certaines données de départ étaient des estimations et mélangeaient comptes internes, comptes de test et comptes externes. Cela suffit pour commencer une enquête. Il ne suffit pas de publier un taux de conversion précis.
Cette analyse concerne ce que nous pouvons établir : les étapes que nous devons séparer, les vérifications d’installation effectuées par le code actuel et les preuves nécessaires avant de qualifier une modification d’intégration d’amélioration.
Trois étapes qui ne devraient jamais partager la même étiquette
La création de compte nous indique que quelqu’un a terminé son inscription. La création du site Web nous indique qu’ils ont configuré un objet dans le produit. Un premier événement enregistré nous indique que les données ont atteint le pipeline d’analyse de ce site Web.
Ce sont des étapes différentes. Aucun de ces jalons, à lui seul, ne prouve que la personne a compris le rapport ou qu’elle reviendra la semaine prochaine.
Pour cet audit, le premier point de contrôle technique utile est un événement réel enregistré pour le site Internet visé. C’est plus précis que l’activation du produit, mais beaucoup plus facile à vérifier qu’une étiquette vague telle que « configuration terminée ».
Une personne sans site Web a besoin d’aide pour prendre la décision de configuration. Une personne possédant un site Web et aucun événement n’a besoin d’un diagnostic d’installation. Une personne qui reçoit des événements mais ne revient jamais peut avoir un problème différent : le rapport n’a pas répondu à une question qui valait la peine de revenir. Envoyer le même rappel aux trois personnes suppose le diagnostic avant de le poser.
Lisez l’implémentation, pas seulement la score
La fonction de notation d’activation actuelle de Zenovay évalue quatre étapes : un indicateur d’installation de script, un premier événement dans les 24 heures suivant la création du site Web, une connexion Stripe dans les sept jours suivant la création de l’équipe et une connexion de retour après le premier jour et dans les quatorze jours suivant la création de l’équipe. Chaque étape franchie rapporte 25 points.
La fonction compte indépendamment les jalons atteints. Il n’est pas nécessaire que quelqu’un termine une séquence stricte avant que les étapes ultérieures puissent compter. Ce détail est important dans l’interprétation d’un score : deux comptes peuvent atteindre le même total grâce à des comportements différents.
Un premier événement arrivant après 24 heures échoue également au jalon limité dans le temps, même si le suivi fonctionne désormais. « La fenêtre d’activation a été manquée » et « l’installation est interrompue » nécessitent des réponses différentes.
Nous avons déjà parlé d’un indicateur d’installation qui ne reflétait pas l’activité sous-jacente. La leçon plus large s’applique toujours : une score résume ses entrées. Il ne peut pas vous dire si ces entrées sont dignes de confiance.
Un graphique vide a plusieurs causes possibles
Le point de collecte actuel vérifie l’origine de la demande par rapport aux domaines autorisés du site Web. Si aucune liste explicite n’existe, elle revient au domaine enregistré. Une origine incompatible peut être rejetée en production lorsque la vérification du domaine est activée.
Il existe également une exception localhost explicite contrôlée par le paramètre allow_localhost du site Web. Cette exception appartient à la vérification de domaine. Ce n’est pas une promesse que chaque test local produira un événement stocké : d’autres contrôles s’appliquent toujours.
C’est pourquoi « J’ai collé le script » est le début de la vérification, pas la fin. Vérifiez le nom d’hôte réel de la page, le site Web configuré, la réponse réseau du navigateur et si un événement a été enregistré. Utilisez une véritable visite de navigateur pour le parcours utilisateur que vous testez.
N’affaiblissez pas un contrôle de sécurité simplement pour faire passer un indicateur de configuration au vert. Recherchez d’abord la demande rejetée et comprenez pourquoi elle a été rejetée. La réparation utile peut être la configuration, les instructions d’installation ou le message d’erreur.
Compter les personnes et les sites Web séparément
Soustraire le nombre de sites Web du nombre d’inscriptions ne donne pas le nombre de personnes qui ont abandonné l’intégration. Une personne peut créer plusieurs sites Web. Un collègue peut rejoindre une équipe existante sans en créer. Les comptes tests peuvent fausser un petit échantillon.
Un rapport de cohorte utile commence par un ensemble défini de comptes ou d’équipes éligibles et suit ce même ensemble à travers les étapes. Choisissez l’unité, les exclusions et la fenêtre d’observation avant de calculer le pourcentage.
Par exemple, un rapport sur les nouveaux propriétaires d’équipes pourrait demander si chaque propriétaire a créé au moins un site Web et si l’un de ces sites Web a reçu un premier événement de qualification dans une fenêtre fixe. Comptez chaque propriétaire une fois. Déclarez les décomptes sous-jacents ainsi que le pourcentage. Séparez les invitations et les tests internes.
Il s’agit d’une proposition de contrat de mesure, et non d’une affirmation selon laquelle l’estimation historique de juillet l’a déjà suivi.
Qu’est-ce qui serait considéré comme une amélioration ?
Avant de comparer deux versions d’intégration, accordez aux deux cohortes le même temps pour atteindre le point de contrôle. Une cohorte d’hier ne peut pas être comparée équitablement à une cohorte qui a eu deux semaines pour terminer sa configuration.
Suivez l’étape manquante, pas seulement le total final. Est-ce que davantage de propriétaires éligibles ont créé un site Web ? Est-ce que davantage de ces sites Web ont reçu un événement ? Les gens sont-ils revenus après avoir obtenu des données ? Enregistrez les modifications transmises entre les cohortes et gardez les sources d’acquisition à l’œil.
Cette analyse ne démontre pas une amélioration mesurée du taux d’activation. Un examen des sources peut montrer comment fonctionne un contrôle et identifier un obstacle plausible. Il ne peut pas établir pourquoi chaque personne est partie, ni prouver que la suppression d’une étape a poussé davantage de personnes à rester.
La prochaine fois qu’une notification d’inscription arrive, le suivi utile est simple : cette personne a-t-elle obtenu des données de son propre site Web et cela l’a-t-il aidée à faire quelque chose ? En attendant que nous puissions répondre à cette question, le décompte des comptes n’est que le début de l’histoire.
