Vos utilisateurs se plaignent de « crash » sur vos apps !

Le "crash" sur vos apps n'est pas une fatalité... Selon une étude, 61% des utilisateurs s'attendent à ce que les applications mobiles démarrent dans un délai de quatre secondes,

Le « crash » sur vos apps n’est pas une fatalité… Selon une étude en 2015, 61% des utilisateurs s’attendent à ce que les applications mobiles démarrent dans un délai de quatre secondes, tandis que 49% souhaitent une réponse aux intrants en deux secondes. Si une application se bloque,  ou comporte des erreurs, 53% des utilisateurs la désinstallent. En 2016, à la veille de la frénésie des ventes du Black Friday aux États-Unis, une entreprise a publié un rapport estimant combien d’argent les entreprises pourraient perdre si leurs applications s’effondraient le jour j. Ce qui est toujours très important , c’est d’anticiper et prévenir ces pannes extrêmement dommageables pour l’expérience utilisateur !

Vos utilisateurs se plaignent de « crash ». Les vraies raisons pour lesquelles vos utilisateurs sont frustrés et ne reviennent pas, les connaissez vous ? À quelle fréquence votre application plante-t-elle ?

C’e sont d’excellente questions car elle comporte plusieurs nuances. Tout d’abord, la question est mieux formulée comme suit: À quelle fréquence vos utilisateurs ont-ils une mauvaise expérience ?, car les véritables «plantages» (les cas où l’application se ferme soudainement) ne représentent qu’un petit fraction des cas que l’utilisateur qualifierait comme un crash. Les MOO (mémoire insuffisante), qui sont des cas où l’application se ferme soudainement sans laisser de trace de pile, affectent les utilisateurs 5 à 10 fois plus fréquemment en cas de blocage et frustrent l’utilisateur tout autant qu’un problème technique » crash. » Tout composant d’application, même les composants tels que les Broadcast Receiver ou les fournisseurs de contenu qui s’exécutent en arrière-plan, peut entraîner le blocage d’une application. Ces blocages sont souvent source de confusion pour les utilisateurs car ils ne participaient pas activement à votre application.

De plus, la question est encore plus compliquée quand on prend en compte les situations dans lesquelles l’utilisateur force la fermeture d’une application, qui ne sont pas des accidents, mais dans de nombreux cas, elles pourraient tout aussi bien l’être. Si l’utilisateur est bloqué sur une page d’achat et force la fermeture de l’application, ils n’ont pas vraiment rencontré un crash. Mais, comment ont-ils vécu le fait de devoir quitter l’application et le sentiment de frustration qui en découle est-il meilleurs ?

MOO

Les terminaisons d’utilisateur sont de loin le type le plus fréquent de session d’utilisateur non normale. La plateforme Embrace a constaté que, sur iOS, les accidents réels représentaient en moyenne < 0,1% des sessions, et que les MOO représentaient environ 0,25% des sessions et les terminaisons volontaire d’utilisateur, environ 4% des sessions. Un grand nombre de ces terminaisons d’utilisateur sont des terminaisons « bienveillantes », les cas où l’utilisateur veut simplement effacer toutes les applications exécutées en arrière-plan sur son téléphone.

Il arrive que le taux de base soit de 10% d’exclusions, car les utilisateurs les soupçonnent de vider la batterie en arrière-plan. N’oubliez pas de commencer à penser en dehors des « accidents » généraux et de vous concentrer davantage sur les raisons possibles pour lesquelles les utilisateurs ont une mauvaise expérience de votre application. Étudiez la multitude d’erreurs et d’échecs pouvant survenir pour identifier les véritables problèmes. Une fois que vous avez une carte claire des problèmes, vous pouvez commencer à les résoudre, ce qui se traduira par de meilleures expériences pour les utilisateurs, pouvant éventuellement mener à des actions complètes, des sessions plus longues, ainsi qu’un engagement et une rétention plus importants à long terme.

Android

Le crash de vos apps se produit généralement lorsque vous mettez à jour le logiciel de votre appareil sans oublier de télécharger les mises à jour des applications à partir du Play Store. De plus, lorsque votre WiFi ou vos données cellulaires sont lents ou instables, les applications ont tendance à mal fonctionner. Le manque d’espace de stockage sur votre appareil est également à l’origine du problème de blocage des applications Android.

Pensez aussi à une situation dans laquelle vous téléchargez un fichier volumineux dans votre application et que, tout à coup, la batterie devient trop basse, vous ne voulez pas que le téléchargement s’arrête brusquement et souhaitez montrer à l’utilisateur une notification/une boîte de dialogue afin qu’il puisse suspendre le téléchargement. Créer un service juste pour continuer à vérifier l’alimentation de la batterie serait trop de travail pour une simple notification. Que se passe-t-il si le système Android vous informe d’un événement du système tel que batterie faible ou mode avion avec un crash ?

Devinez quoi ? Cela existe! Et vous pouvez gérer ces événements très efficacement. Ces événements sont appelés émissions et vous devez les gérer dans le Broadcast Receiver. Source et suite Ici

iOS

Pour iOS, vous pouvez télécharger (XCODE,)  Network Link Coordinator. Il va simuler diverses conditions de réseau, notamment une bande passante réduite, une latence élevée, des délais DNS, la perte de paquets, etc. Sur un iPhone vous trouverez ensuite NLC dans iPhone Settings > Developer > Network Link Conditioner.

Les outils

– https://bugfender.com/
– https://embrace.io/
– https://firebase.google.com/
– https://raygun.com/