1. Définir ce que signifie « terminer »
Un taux de complétion n’est interprétable que si les événements de départ et de fin sont explicites. Choisissez un point d’entrée observable, comme le premier écran réellement affiché, et une arrivée précise, comme le premier écran utilisable du produit. Télécharger une configuration ne prouve pas qu’elle a été vue.
Écrivez la définition avant de modifier le parcours : application, version du flow, audience éligible, unité d’identité, fuseau horaire et délai autorisé. Séparez les premières installations des personnes qui rouvrent un écran de configuration. La mesure répond alors à une question précise : combien de participants éligibles ont atteint l’arrivée définie ?
- Départ : le premier écran d’onboarding devient visible.
- Fin : l’application atteint la destination prévue.
- Fenêtre : par exemple 24 heures après le premier départ.
- Unité : une installation unique ; une réinstallation peut créer une nouvelle identité.
2. Garder le numérateur dans le dénominateur
Prenons une cohorte fictive de 1 000 installations ayant commencé lundi. Dans les 24 heures, 800 atteignent les préférences, 650 la dernière étape et 600 terminent. Le taux global est de 60 %. Ces chiffres illustrent le calcul ; ils ne décrivent ni des clients Aplyna ni une référence de marché.
Dans un entonnoir fermé et ordonné, chaque étape appartient à la cohorte initiale et respecte les étapes précédentes. Une personne arrivant directement au dernier écran ne doit pas rejoindre discrètement le dénominateur des nouveaux utilisateurs. Google Analytics distingue pour cette raison les entonnoirs ouverts et fermés. Documentez votre propre règle.
Une cohorte, une fenêtre de complétion
Entonnoir fictif de 1 000 installations observées pendant 24 heures.
3. Distinguer taux global et conversion entre étapes
Dans cet exemple, la dernière étape convertit 600 installations sur 650, soit environ 92,3 %. Ce résultat diffère du taux global de 60 %. Les deux sont utiles, mais une courbe nommée simplement « conversion » ne dit pas quelle question elle traite.
Examinez la perte absolue en plus du pourcentage. La première transition perd 200 installations, la dernière 50. Cela aide à choisir où enquêter, sans démontrer qu’un écran cause l’abandon. Un chargement lent, un crash, une règle d’éligibilité ou un événement absent peuvent produire un profil similaire.
- La conversion entre étapes décrit une transition précise.
- La complétion globale décrit le trajet du départ à l’arrivée.
- Vérifiez le produit et la télémétrie avant d’attribuer une baisse au design.
4. Dédupliquer et laisser mûrir les cohortes
Comptez des identités d’installation distinctes, pas des lignes d’événements. Les retries et les visites répétées ne doivent pas gonfler les résultats. Réutilisez les identifiants d’événements lors des tentatives de livraison et comptez une installation une seule fois pour le résultat choisi. Appliquez toujours les filtres d’organisation et d’application.
Ne divisez pas toutes les fins reçues aujourd’hui par tous les départs reçus aujourd’hui si le parcours peut finir demain. Regroupez par cohorte de départ et appliquez sa fenêtre. Signalez les cohortes encore incomplètes ; les événements hors ligne peuvent nécessiter une période de rapprochement documentée.
Pour une semaine, recalculez les installations uniques sur toute la période. Additionner les uniques quotidiens compte plusieurs fois les installations présentes plusieurs jours. Faire la moyenne des taux quotidiens donne aussi le même poids aux petites et grandes cohortes : recalculez plutôt numérateur et dénominateur.
5. Mesurer l’activation après la complétion
Terminer la configuration ne signifie pas avoir obtenu de la valeur. Un lecteur peut atteindre l’accueil sans ouvrir de livre ; une personne peut finir un questionnaire sans accomplir une habitude. Définissez une action d’activation liée au produit et sa propre fenêtre d’observation.
Utilisez la complétion comme diagnostic, avec l’activation et la fiabilité comme garde-fous. Supprimer toutes les étapes peut accélérer la fin tout en dégradant la personnalisation. Une expérience contrôlée doit examiner le résultat en aval avant de considérer un parcours plus court comme meilleur.
Avec Aplyna, partez des événements SDK explicites et des définitions documentées. Un signal de début d’essai ne constitue pas un achat vérifié ni du revenu d’abonnement. Consultez les disponibilités réelles avant de construire une analyse autour d’une métrique non prise en charge.
Sources et lectures utiles
Les références techniques peuvent être en anglais. Les exemples sont pédagogiques ; le comportement du produit suit les SDK source actuels et les capacités documentées. Aucun résultat client n’est revendiqué.
Publié par Aplyna. Les illustrations éditoriales ont été générées par IA ; ce ne sont pas des captures du produit. Les graphiques présentent des exemples pédagogiques ou des schémas explicitement identifiés.
