Comprendre ce que font les utilisateurs de l'application
Le store vous dit combien de personnes l'ont installée. Il ne vous dit rien sur le fait qu'elles l'aient ouverte deux fois.
La situation
Une application est plus difficile à mesurer qu'un site et les questions sont les mêmes : quels écrans les gens atteignent, s'ils reviennent, et si la dernière version a empiré les choses.
La difficulté propre est qu'on ne répare pas une mauvaise compilation en déployant. Elle est dehors jusqu'à ce que les gens mettent à jour, et la première alerte est d'ordinaire un avis.
Comment cela se fait
1. Ajoutez le SDK. Il y en a un pour Android, iOS, Flutter, React Native, Kotlin Multiplatform, Unity, .NET et Electron. Chacun prend l'identifiant de l'application et un appel pour démarrer.
2. Nommez vos écrans avec soin. Une application n'a pas d'URL : le nom que rapporte votre SDK est ce qui apparaît dans chaque rapport. C'est la seule décision à l'installation que vous ne pourrez pas changer à bon compte plus tard.
3. Lisez la stabilité par version. Le taux sans plantage, réparti par version de l'application. En total il ne veut rien dire pendant un déploiement progressif : une mauvaise compilation atteignant un dixième des utilisateurs se dilue au dixième.
4. Annotez la version. La différence entre « l'engagement a chuté en semaine 12 » et « l'engagement a chuté quand nous avons livré la 4.2 ».
5. Attendez-vous à ce que les vieilles compilations continuent de remonter. Le format de transmission est gelé en version 1 : une compilation publiée il y a deux ans envoie toujours des données. Filtrer par version est la façon de lire les rapports, pas une fonctionnalité avancée.
Où cela s'arrête
Il n'y a pas de données de vitesse, et il n'y en aura pas de fausses. Un SDK d'application envoie quand un écran a eu lieu, pas combien de temps quelque chose a pris. Inventer un nombre à partir de l'écart entre deux écrans mesurerait la vitesse à laquelle quelqu'un tape. S'il vous faut des temps de lancement et des fréquences d'images, c'est un outil de performance.
Pas de heatmaps, pas d'enregistrements, pas de widget de feedback. Il leur faut une page à laquelle se rattacher. Une application obtient écrans, sessions, rétention et erreurs, et c'est toute la liste.
Un taux sans plantage cache une fonctionnalité qui échoue en silence. L'application reste debout et l'écran ne fait rien. Le signal, là, c'est le nombre d'écrans par session, pas la stabilité.
Ce que cela utilise
Autres tâches
Réparer un tunnel d'inscription qui fuit
Trouvez l'étape que les gens abandonnent, puis regardez ce qui s'y est réellement passé.
Prouver quel marketing a rapporté du chiffre d'affaires
Reliez l'argent à la campagne, sans que le rapport de sources dise « Direct ».
Entendre les visiteurs avant qu'ils ne partent
Un commentaire rattaché à la page dont il parle, plutôt qu'un questionnaire que personne ne commence.
Rendre compte sans distribuer d'identifiants
Un lien en lecture seule pour un client ou un conseil, et un récapitulatif qui arrive tout seul.
Surveiller un jour de lancement
Voyez le trafic arriver en direct, et sachez dans l'heure si cela tourne mal.