L'installation était la partie chère. Vous avez payé la publicité, gagné la fiche du store, survécu au téléchargement. Puis la plupart de ces gens ont ouvert l'app une fois, ne sont pas revenus, et l'ont supprimée dans la semaine.
Ce schéma est normal dans toute l'industrie — et c'est précisément pour ça qu'il vaut la peine de l'attaquer : tout le monde perd les mêmes utilisateurs, et les correctifs sont assez ingrats pour que la plupart des équipes les sautent.
La première session décide de presque tout
Les courbes de rétention sont les plus raides tout au début. La chute entre l'installation et la deuxième ouverture écrase tout ce qui suit — tout le problème se concentre donc dans une session de deux minutes.
Cela recadre où va l'effort. Une équipe qui peaufine les fonctionnalités d'engagement de la semaine quatre optimise pour un public déjà parti. Le levier est dans les quatre-vingt-dix premières secondes — et presque personne ne les instrumente correctement.
Posez une question simple à vos propres analytics : de tous ceux qui ont installé le mois dernier, quel pourcentage a atteint le point où l'app est devenue utile ? Pas inscrits — utile. Vu leurs données, accompli ce pour quoi ils étaient venus, reçu la valeur promise par la pub. Ce chiffre est généralement bien plus bas que prévu — et c'est celui qui compte.
Les quatre tueurs de première session
Un mur avant toute valeur. Écrans d'inscription, demandes de permissions et carrousels de visite empilés devant le produit. Chacun est une exigence avant que rien n'ait été donné. Les utilisateurs qui n'ont pas encore vu de valeur n'ont aucune raison de payer un coût — et chaque écran en fait tomber une part.
Des permissions sans contexte. Une demande de localisation au lancement, avant que l'utilisateur sache pourquoi, se fait refuser — et sur les deux plateformes, un refus colle et se renverse difficilement. Demandez au moment où la fonctionnalité en a besoin, après avoir expliqué ce qu'elle fait.
Un état vide qui a l'air cassé. Un nouveau compte n'a pas de données, donc l'écran conçu autour du contenu n'affiche rien. L'utilisateur ne peut pas dire si l'app est vide ou en panne. Les états vides sont les écrans les plus fréquentés de votre app — et généralement les moins travaillés.
Un démarrage à froid lent. Le premier lancement travaille le plus — téléchargements, initialisation, migrations. C'est aussi celui où l'utilisateur a le moins investi. Quelques secondes d'écran vide se lisent comme un logiciel cassé.
Fig. — Chaque barrière avant le point de valeur perd des utilisateurs qui n'ont jamais vu pourquoi ils avaient installé.
Ce qui fait vraiment bouger le chiffre
Retardez le compte. Laissez les gens utiliser l'app d'abord et s'inscrire quand ils ont besoin de quelque chose qui exige un compte — sauvegarder, synchroniser, payer. Ce seul changement surpasse de façon fiable toute amélioration du formulaire d'inscription lui-même — parce que le meilleur formulaire est celui que personne n'a encore eu à remplir.
Amorcez l'état vide. Des données d'exemple, un modèle, un exemple prérempli qu'on peut modifier. Un utilisateur devant un écran blanc doit s'inventer une tâche ; un utilisateur devant un exemple rempli n'a qu'à le changer. C'est une première action bien plus facile.
Rendez la première action minuscule. Pas « configurez votre espace de travail », mais un tap qui produit un résultat visible. L'élan d'une première session se construit sur de petits accomplissements — et l'app qui demande cinq minutes de configuration est abandonnée à la deuxième.
Méritez les permissions. Expliquez dans votre propre écran ce qu'une permission débloque, puis déclenchez la demande système quand l'utilisateur accepte. Le dialogue système est une ressource à un coup ; le dépenser à froid est du gaspillage.
Et instrumentez l'entonnoir correctement. Installation, première ouverture, chaque barrière franchie, première valeur, deuxième ouverture. La plupart des équipes mesurent les installations et les actifs quotidiens sans pouvoir dire où, entre les deux, les gens partent — ce qui fait de chaque correctif un pari.
Le décalage d'acquisition que personne ne vérifie
Une part du churn de première semaine n'est pas du tout un échec d'onboarding. C'est un problème de promesse — et il apparaît comme un chiffre de rétention.
Si votre pub promet un accès illimité gratuit et que l'app demande une carte au troisième écran, ces utilisateurs n'allaient jamais rester. Ils partent vite, laissent de mauvais avis, et tirent vers le bas toutes les métriques de rétention avec lesquelles vous jugez vos changements d'onboarding — vous optimisez donc un entonnoir nourri des mauvaises personnes.
Segmentez par source d'acquisition avant de conclure. Les installations de recherche organique et de social payant se comportent de façon complètement différente, et la moyenne cache les deux. Il est courant de trouver un canal qui retient plusieurs fois mieux qu'un autre — auquel cas l'action utile est une décision de budget, pas de design.
Même chose pour les captures d'écran du store. Elles sont une promesse implicite — et un écart entre elles et le premier écran est une petite trahison qui vous coûte la session.
La question de la réactivation
Les notifications push sont le levier évident et celui qui se retourne le plus volontiers. Une notification envoyée avant que l'utilisateur comprenne l'app est du bruit, et le bruit fait désactiver les notifications pour de bon — après quoi votre seul canal de réactivation a disparu pour la vie de l'installation.
Le séquencement qui marche : livrer la valeur, puis demander la permission de notifier avec une raison précise, puis envoyer des messages qui font référence à quelque chose que l'utilisateur a réellement fait. Les rafales génériques de réactivation performent mal et vous coûtent le canal.
L'e-mail reste sous-estimé pour cela — surtout parce qu'il survit à une désinstallation. Quelqu'un qui a supprimé votre app peut encore revenir grâce à un message qu'il voit ; quelqu'un qui a coupé les notifications, non.
Par où commencer cette semaine
Installez votre propre app sur un téléphone où vous ne l'avez jamais utilisée — depuis le store, pas depuis un build — et regardez quelqu'un d'autre faire pareil. Pas un collègue : quelqu'un qui ne l'a jamais vue.
Comptez les taps avant qu'il voie quelque chose d'utile. Comptez les secondes. Notez chaque écran qui demande quelque chose avant de donner quoi que ce soit. Cette liste, dans l'ordre, est votre backlog de rétention — et elle est généralement plus courte et plus embarrassante que ne le suggérerait n'importe quelle analyse.
Supprimer des taps du premier parcours est un travail ingrat — et une partie standard de notre façon de construire et de sauver des apps mobiles. Si votre rétention au jour un vous gêne, envoyez-nous le funnel : nous avons vu pire.
