Analyse des données dans les applications - Guide complet avec des cas réels

Les données sont le nouveau pétrole, disent-ils. Mais le pétrole brut n’est pas bon à mettre dans votre voiture ; il faut le peaufiner. C'est la même chose avec les données d'application : disposer de téraoctets de journaux d'utilisateurs est inutile si vous ne savez pas comment les transformer en insights exploitables.

L'analyse des données d'application (App Analytics) est la science qui permet de comprendre qui sont vos utilisateurs, ce qu'ils font et pourquoi ils restent (ou partent).

Dans ce guide, nous nous éloignerons de la théorie et analyserons des cas réels (anonymes ou publics) de la manière dont l'analyse des données a permis de sauver ou d'exploiter des produits numériques.

Les 4 piliers de l'analyse des applications

Avant les cas, il faut aligner les fondamentaux. Chaque analyse s’articule autour de quatre questions :

Acquisition : d'où viennent les utilisateurs ? (Organique, publicités, influenceurs ?)
Activation : utilisent-ils la fonction principale de l'application ?
Rétention : reviennent-ils ?
Monétisation : génèrent-ils de la valeur (de l'argent) ?

Cas réel 1 : le « entonnoir de la mort » dans l'enregistrement (Fintech)

Le scénario : Une fintech brésilienne a lancé son application. Ils ont investi des millions dans le marketing. Le nombre de téléchargements (installations) était très élevé. Toutefois, le nombre de comptes ouverts était faible.

L'analyse : L'équipe de données s'est plongée dans l'entonnoir Onboarding.

Étape 1 (Téléchargement) : 100 %
Étape 2 (ouvrir l'application) : 90 %
Étape 3 (Entrez CPF) : 85 %
Étape 4 (Photo d'identité) : 80 %
Étape 5 (Selfie) : 20 % 📉
Étape 6 (Compte créé) : 18 %

L'entonnoir a saigné de 60 points de pourcentage au cours de l'étape Selfie.

La Découverte : En recoupant les données d'erreur de l'API avec le modèle de téléphone portable des utilisateurs, ils ont découvert que la bibliothèque de caméras utilisée tombait en panne sur des modèles Android plus anciens et moins chers (Samsung J5, Moto G4), qui étaient précisément le public cible de la fintech. Pour ceux qui possédaient un iPhone, cela fonctionnait bien. Pour le grand public, l’application s’est fermée (crash).

La solution : ils ont remplacé la bibliothèque de capture d'images par une bibliothèque plus légère et plus compatible. Résultat : La conversion dans l'étape Selfie est passée à 75 %. Le coût d’acquisition client (CAC) a diminué de moitié.

Cas réel 2 : La notification « Magique » (Delivery App)

Le scénario : Une application de livraison de nourriture souhaitait augmenter la récurrence. Les utilisateurs ont commandé une fois et ont mis 30 jours pour commander à nouveau.

L'analyse : Ils ont analysé le comportement d’une « cohorte ». Ils ont séparé les utilisateurs en groupes :

Groupe A : Déjeuner commandé.
Groupe B : Dîner commandé.
Groupe C : J'ai commandé une collation l'après-midi.

Ils ont constaté que le Groupe B (Dîner) était 3 fois plus susceptible de commander à nouveau au cours de la même semaine. Le dîner était « l’habitude clé ».

L'Action : Au lieu d'envoyer des notifications aléatoires toute la journée, ils ont concentré le budget des notifications push et des coupons sur 18h00, encourageant ainsi la première commande à être un dîner. "Tu ne veux pas cuisiner aujourd'hui ? Commande X."

Résultat : Ils ont créé l'habitude de dîner. Une fois que l’utilisateur est devenu fidèle au dîner, il a naturellement commencé à commander également le déjeuner. LTV (Lifetime Value) a augmenté de 40%.

Cas réel 3 : Le bouton que personne n'a vu (commerce électronique de mode)

Le scénario : Un e-commerce de mode avait beaucoup de trafic sur la page produit, mais peu d'ajouts au panier.

L'analyse : Ils ont utilisé des cartes thermiques (Heatmaps) et des enregistrements de session (Session Replay). Ils ont remarqué que, sur les téléphones portables dotés d'écrans plus petits (iPhone SE, petits androïdes), le bouton « Ajouter au panier » se trouvait en dessous du « pli » (défilement obligatoire). L’utilisateur a vu la photo, a vu le prix, mais n’a pas vu le bouton. Il a dû faire défiler vers le bas pour acheter.

La solution : Ils ont créé un "Sticky Button" en bas de l'écran. Même si l'utilisateur faisait défiler la page pour voir les photos, le bouton « Acheter » était toujours visible, flottant en bas.

Résultat : Augmentation immédiate de 15 % du taux d'ajout au panier.

Outils essentiels pour y parvenir

N'essayez pas ceci avec "select * from database". Utilisez les outils d'analyse de produits :

Amplitude / Mixpanel : Le meilleur pour l'analyse de l'entonnoir et de la rétention. Ils répondent « Qu'est-ce que l'utilisateur a fait ? ».
Google Analytics 4 (GA4) : norme du secteur, idéale pour les sources de trafic et les données démographiques.
AppsFlyer / Adjust : Indispensable pour l'attribution (savoir si l'utilisateur est issu d'une publicité Facebook ou Google).
Crashlytics (Firebase) : Pour découvrir les bugs techniques qui tuent la conversion (comme dans le cas 1).

Le danger des « Vanity Metrics »

Faites attention à ne pas vous tromper.

Téléchargements : Pas de facture. Si l'utilisateur télécharge et désinstalle, c'est une perte.
Utilisateurs enregistrés : s'ils n'utilisent pas l'application, c'est un poids mort dans la base de données.

Concentrez-vous sur de véritables mesures d’engagement :

DAU/MAU (utilisateurs actifs quotidiens/mensuels).
Taux de rétention (Jour 1, Jour 7, Jour 30).
Heure de la session.

Conclusion

L'analyse des données ne consiste pas à générer de jolis graphiques pour le tableau. Il s'agit d'enquête. Vous êtes un détective. Le crime est que l'utilisateur quitte votre application. Les indices sont dans les journaux.

Des cas réels montrent que, souvent, la réponse n'est pas de « changer de modèle économique », mais plutôt de corriger un bug de la caméra, d'ajuster l'heure d'une notification ou de déplacer un bouton 50 pixels plus haut sur l'écran.

Commencez à mesurer dès aujourd'hui. Le prochain aperçu d'un million de dollars pourrait être caché dans votre tableau d'événements.