Seulement 25,3 % des utilisateurs d'applications mobiles reviennent le jour 1, et la rétention moyenne tombe à 5,7 % le jour 30 selon les indicateurs de fidélité des applications mobiles de Business of Apps ce graphique ne vous dit pas si le problème est une mauvaise acquisition, un flux de démarrage confus ou une faible valeur produit.L'analyse des cohortes d'applications le fait. Les moyennes combinent les utilisateurs qui sont arrivés à travers différentes campagnes, pays, appareils, versions d'applications et modèles de monétisation. Un tableau de bord de cohortes sépare ces groupes, suit chaque un d'eux tout au long du même cycle de vie et donne aux équipes de produits, de marketing et d'ingénierie une base défendable pour décider ce qu'il faut corriger.
Table des matières
Pourquoi l'analyse des cohortes d'applications révèle ce que les indicateurs agrégés cachent
- La valeur diagnostique d'une ligne de cohorte
- Guide de sélection pratique
- 5.7% by Day 30
- Calcul des cohortes avec SQL et outils d'analyse
- Pièges courants et comment les équipes mal interprètent les données de cohortes
- Relier les intuitions de cohortes aux stratégies de mise à jour et de lancement
- Allez au-delà de la rétention d'installation et des cohortes d'événements et de revenus
Pourquoi l'analyse de cohortes d'applications révèle ce que les métriques agrégées cachent
Un nombre de rétention global est utile comme un contrôle de santé, mais il s'agit d'un outil diagnostique défectueux. Si les publicités payantes, les recherches organiques, les références et les campagnes de partenaires se nourrissent d'une seule table de bord, le résultat décrit la mélange d'utilisateurs plutôt que la description du produit. Le même problème apparaît lorsque les utilisateurs iOS et Android, les nouveaux et les clients de retour, ou les différentes expériences de mise en route partagent une courbe.
La barre de référence ci-dessus montre pourquoi le premier mois mérite une attention particulière. Le même Analyse de la rétention des applications rapports des moyennes iOS de 25,65% le jour 1 et 4,13% le jour 30moyennes Android de 23,01% le jour 1 et 2,59% le jour 30. La performance des catégories varie fortement, avec un référentiel de 2026 qui s'étend de 11,3% de rétention le jour 30 dans les actualités à 2,1% dans l'éducation. Une moyenne mondiale peut donc faire paraître une catégorie forte comme faible ou un canal faible comme acceptable.
La valeur diagnostique d'une ligne de cohorte
Une cohorte d'installation groupe les utilisateurs en fonction de la première fois qu'ils ont ouvert l'application, puis mesure le comportement de retour à des âges cohérents comme le jour 1, le jour 7 et le jour 30. La lecture d'une ligne montre comment un seul groupe vieillit. La lecture d'une colonne compare différents groupes au même stade de leur cycle de vie.
La distinction change la question de « Pourquoi la rétention est-elle basse ? » en :
- Qualité d'acquisition : S'agissait-il d'une campagne qui a attiré des utilisateurs qui n'avaient jamais l'intention d'utiliser le produit ?
- Friction d'abordage : S'agissait-il d'utilisateurs qui ont installé mais ont échoué à compléter la première étape significative ?
- Remise de valeur : S'agissait-il d'utilisateurs activés qui ont disparu après l'expérience initiale ?
- Impact de la mise à jour : S'agissait-il d'une nouvelle version qui a modifié la courbe pour les utilisateurs qui l'ont reçue ?
Une équipe peut voir une rétention globale plate tandis que les cohortes hebdomadaires récentes s'améliorent et que les cohortes plus anciennes vieillissent naturellement. Sans limites de cohortes, l'amélioration est annulée. À l'inverse, un grand nombre global peut cacher une canal payant en déclin si le trafic organique a suffisamment augmenté pour le compenser.
Règle pratique : Ne jamais approuver une modification de produit liée à la rétention à partir d'un tableau de bord global. Décomposez le résultat par source d'acquisition, pays, plateforme, chemin d'abordage et version de l'application en premier lieu.
La cadre de retenue des utilisateurs de l'application est utile lorsqu'on transforme ce diagnostic en une vue plus large du cycle de vie. Le point opérationnel est simple : l'analyse de cohortes vous indique où la courbe se brise, tandis que la segmentation vous aide à identifier quel input contrôlable a produit cette rupture.
Types de Cohorts et Quand les Utiliser Chacun
La bonne cohorte commence par la question que vous essayez de répondre. Les cohortes d'installation, les cohortes d'événements et les cohortes de revenus peuvent toutes décrire les mêmes utilisateurs, mais elles ancrent l'analyse à des moments différents et soutiennent des décisions différentes.
Cohortes d'installation groupent les utilisateurs par date de première installation ou première ouverture de l'application. Ce sont les cohortes par défaut pour l'analyse de l'onboarding et de l'acquisition car chaque utilisateur entre par le même événement de démarrage. Les équipes de croissance les utilisent pour comparer la qualité des campagnes, la retenue précoce et les changements dans l'expérience de première utilisation.
Cohortes basées sur des événements commencent par un comportement significatif, tel que la fin de l'onboarding, la création d'un projet, la fin d'un entraînement ou l'envoi d'un premier message. Elles suppriment un peu de bruit entre l'installation et l'activation. Si les utilisateurs qui ont terminé un premier entraînement restent actifs plus longtemps que les utilisateurs qui n'ont fait que s'installer, le problème d'onboarding est probablement responsable de la découverte de la valeur plutôt que refléter une faiblesse de retenue du produit.
Cohortes basées sur des revenus ancrer les utilisateurs à une première transaction, au démarrage d'abonnement, au niveau de plan ou à un autre événement de monétisation. Ces cohortes soutiennent l'analyse du LTV, les décisions de remboursement et les comparaisons entre les modèles d'affaires. Un utilisateur d'abonnement et un utilisateur soutenu par des publicités ne devraient pas être jugés par des attentes de rétention identiques, car leur valeur économique et leurs incitations à l'engagement diffèrent. Récent couverture de rétention mobile rapports sur 14 % de rétention au jour 30 pour les applications d'abonnement par rapport à environ 5,4 % pour les applications soutenues par des publicités, ce qui rend la normalisation des modèles d'affaires essentielle.
guide de sélection pratique
| Type de cohorte | Meilleur pour | Question clé répondue | Exemple de déclencheur |
|---|---|---|---|
| basé sur l'installation | croissance et onboarding | Les utilisateurs reviennent-ils après l'acquisition et la première utilisation ? | Première ouverture de l'application |
| Contexte : Page/zone : Capgo Builder / page de produit de build cloud natif. Rôle : Étiquette de navigation ou élément de menu court. Clé de message `native_build_builder_credit_first` (Crédit du constructeur de build natif Premier). | Basé sur des événements | Activation du produit | Un acte significatif prédit-il une utilisation continue ? |
| Premier entraînement terminé | Contexte : Page/zone : Capgo Builder / page de produit de build cloud natif. Rôle : Étiquette de navigation ou élément de menu court. Clé de message `native_build_builder_credit_first` (Crédit du constructeur de build natif Premier). | Basé sur les revenus | Monétisation et finances |
Comment se développe la valeur après la conversion ?
Première vente ou début de l'abonnement segmentation des utilisateurs par plan et canal pour conserver les dimensions qui affectent l'équité. Une définition de cohorte devrait enregistrer son événement d'ancrage, sa zone horaire, son canal, son pays, son plateforme, son plan et sa version d'application. Sinon, deux lignes avec le même libellé peuvent représenter des populations matériellement différentes.
Les Métriques Clés Qui Orientent Les Décisions De Cohorte
La rétention, le taux de dérive et la valeur à vie répondent à des questions différentes. Les équipes se retrouvent en difficulté lorsqu'elles traitent l'un comme un substitut des autres.
Le taux de rétention mesure la part d'une cohorte originale qui réalise l'action de retour définie pendant une période :
Retention Rate = Active Users in Cohort in Period / Total Users in Cohort × 100
Pour une cohorte d'installation, l'action de retour peut être une ouverture de l'application. Pour une cohorte d'événement, il peut s'agir d'une séance de travail complétée ou d'un document créé. Définissez cette action avant de regarder les résultats. Si l'événement de retour change entre les rapports, la courbe ne fournit plus une comparaison fiable.
Le taux de dérive descrit les utilisateurs perdus sur la même période :
Churn Rate = 1 - Retention Rate
Cette inverse est particulièrement utile pour les produits de souscription, où les clients perdus affectent le revenu récurrent. Un résultat de jour 1 élevé suivi d'une déclinaison abrupte de jour 30 suggère que l'expérience initiale fonctionne mieux que la proposition de valeur à long terme. Une courbe qui se stabilise indique que un groupe de base a trouvé une raison répétitive de revenir.
La valeur à vie mesure la valeur cumulative générée par une cohorte, divisée par la taille de la cohorte :
LTV = Total Cohort Revenue / Cohort Size
Certains équipes utilisent une forme modélisée, comme le revenu moyen par utilisateur multiplié par la durée moyenne de vie, mais le calcul au niveau de la cohorte est plus facile à auditer. Cela empêche également une erreur commune, traiter le revenu des premiers convertis comme preuve que la source d'acquisition entière est rentable.
Lisez les indicateurs ensemble.
Une petite cohorte de haute valeur peut paraître exceptionnelle tout en échouant à s'agrandir. Normalisez chaque cohorte par rapport à sa population de départ, puis comparez le revenu et la rétention aux côtés du coût d'acquisition, du canal, du pays, de la plateforme et du modèle commercial. N'attribuez pas la priorité aux cohortes uniquement en fonction de la plus haute Valeur de Vie ou de la plus haute rétention initiale.
Les plages de référence fournissent un contexte plutôt qu'un grade de passage ou d'échec. Les applications fortes rapportent généralement entre 30–40% de rétention au jour 1, 10–15% de rétention au jour 7 et 5–8% de rétention au jour 30. tandis que les applications médianes se situent plus près de 25%, 8%, et 4% à ces étapes, selon le résumé de référence de rétention mobile de Setgreet. Comparez votre application avec la bonne catégorie et le modèle commercial avant d'attribuer un écart à l'expérience utilisateur.Le
The guide d'analyse de la détérioration de l'utilisateur fournit une complément utile à la table des cohortes. Les cohortes montrent quand survient la détérioration. L'analyse de la détérioration devrait ensuite identifier quel comportement de l'utilisateur, quelle source d'acquisition ou quelle condition de produit a précédé cela.
Calcul des cohortes avec SQL et outils d'analytique
Un workflow SQL fiable commence par une ligne par utilisateur contenant l'ancrage de la cohorte. N'effectuez pas le calcul de l'ancrage à partir de chaque ligne d'activité, car les événements ultérieurs peuvent déplacer les utilisateurs dans la mauvaise période de début.
Supposons un events tableau avec user_id, event_name, et event_at champs. Le modèle suivant crée des cohortes d'installation hebdomadaires et mesure si chaque utilisateur a généré un événement d'activité aux âges de cycle de vie sélectionnés :
WITH first_open AS (
SELECT
user_id,
MIN(event_at) AS cohort_at
FROM events
WHERE event_name = 'app_open'
GROUP BY user_id
),
activity AS (
SELECT DISTINCT
f.user_id,
DATE_TRUNC('week', f.cohort_at) AS cohort_week,
DATE_DIFF('day', CAST(f.cohort_at AS DATE), CAST(e.event_at AS DATE)) AS age_day
FROM first_open f
JOIN events e
ON e.user_id = f.user_id
AND e.event_name = 'app_open'
AND e.event_at >= f.cohort_at
)
SELECT
cohort_week,
COUNT(DISTINCT CASE WHEN age_day = 1 THEN user_id END) * 1.0
/ COUNT(DISTINCT user_id) AS day_1_retention,
COUNT(DISTINCT CASE WHEN age_day = 7 THEN user_id END) * 1.0
/ COUNT(DISTINCT user_id) AS day_7_retention,
COUNT(DISTINCT CASE WHEN age_day = 30 THEN user_id END) * 1.0
/ COUNT(DISTINCT user_id) AS day_30_retention
FROM activity
GROUP BY cohort_week
ORDER BY cohort_week;La syntaxe SQL varie en fonction du magasin, surtout pour les fonctions de différence de date. La structure importante reste la même : établissez le premier événement, jointez les activités ultérieures à cet ancre, calculez l'âge et divisez les utilisateurs distincts qui sont revenus par la population d'origine de la cohorte.
Pour une cohorte d'activation, remplacez l'événement d'ancrage plutôt que d'ajouter un filtre superficiel :
WITH onboarding_complete AS (
SELECT
user_id,
MIN(event_at) AS cohort_at
FROM events
WHERE event_name = 'onboarding_complete'
GROUP BY user_id
)
SELECT
DATE_TRUNC('week', cohort_at) AS cohort_week,
COUNT(DISTINCT CASE
WHEN e.event_name = 'app_open'
AND DATE_DIFF('day', CAST(o.cohort_at AS DATE), CAST(e.event_at AS DATE)) = 7
THEN o.user_id END) * 1.0 / COUNT(DISTINCT o.user_id) AS day_7_retention
FROM onboarding_complete o
LEFT JOIN events e
ON e.user_id = o.user_id
AND e.event_at >= o.cohort_at
GROUP BY cohort_week;Choisir la couche de calcul
| Dimension | SQL brut / Magasin de données | Plateforme d'analyse de produits |
|---|---|---|
| Normalisation personnalisée | Fort, prend en charge les jointures à travers les dépenses, CRM et facturation | Limité par les propriétés disponibles |
| Vitesse de mise en place | Exige des tables modélisées et des requêtes testées | Rapide pour les rapports de cohorte standard |
| Coupe ad-hoc | Flexible une fois que le modèle de données est prêt | Excellent pour les analystes et les équipes de produits |
| Réproducibilité | Contrôlé par version et auditable | Dépend des définitions et des permissions enregistrées |
| Meilleure correspondance | Rapports de niveau financier et attribution complexe | Questions de produit et exploration rapide |
Amplitude, Mixpanel et Firebase fonctionnent généralement bien pour une première passée. Sélectionnez l'événement d'ancrage, choisissez l'événement de retour, définissez la granularité temporelle, ajoutez des filtres pour le canal ou la version, et vérifiez la taille de la cohorte avant d'interpréter le graphique. La requête SQL du magasin devient plus précieuse lorsque vous avez besoin de joindre les dépenses publicitaires, les remboursements, l'état de l'abonnement et l'attribution sécurisée par rapport à la vie privée dans une seule calcul.
Les équipes construisant cette base devraient également créer une culture fondée sur les donnéescar un tableau de bord de cohorte ne modifie les décisions que lorsque le produit, la marketing, la finance et l'ingénierie ont confiance dans les définitions. Pour les événements de cycle de vie personnalisés le plugin de suivi d'événements de Capgo peut être considéré en parallèle de l'instrumentation d'analytique déjà présente dans l'application.
Pièges courants et la façon dont les équipes mal interprètent les données de cohorte
A une équipe peut construire une table de cohorte correcte sur le plan technique et arriver à une conclusion erronée. Les erreurs les plus dommageables se produisent avant l'interprétation, lorsque les analystes combinent des populations qui ne devraient pas être comparées ou attribuent un crédit causal à un changement simultané.
La biais de survie cache la première défaillance.
Supposons que la rétention tardive s'améliore pour les utilisateurs qui ont atteint une fonctionnalité particulière. L'équipe célèbre, mais la rétention précoce a décliné car une nouvelle page de démarrage bloque plus d'utilisateurs de parvenir à cette fonctionnalité. En regardant uniquement les survivants, le produit semble plus en bonne santé tandis que le haut du funnel se dégrade.
Suivez la séquence complète, pas seulement les utilisateurs qui restent :
- Installation ou première ouverture.
- Création de compte ou complétion de permission.
- Événement d'activation de base.
- Événement de valeur répétitif.
- Comportement de revenu ou d'abonnement.
Une cohorte tardive est conditionnelle. Elle répond à la question de savoir comment les utilisateurs activés se comportent, et non de savoir comment le produit crée efficacement des utilisateurs activés.
Les canaux mixtes créent des moyennes trompeuses.
Simpson’s Paradoxe est un risque réel lorsque les utilisateurs payants et les utilisateurs organiques partagent la même ligne. Une courbe combinée peut augmenter après que le mélange de canal se déplace vers une source plus forte, même si la rétention décline dans les deux canaux. Le tableau de bord enregistre le changement de composition, pas une amélioration du produit.
Contrôlez la source d'acquisition avant d'évaluer une mise à jour ou une modification de l'abonnement. Gardez la campagne, le pays, la plateforme, la version de l'application et le modèle de monétisation disponibles en tant que dimensions. Le modèle commercial compte également. Le fossé de rétention entre les applications avec abonnement et les applications avec publicité rapportées dans le source de benchmark précédent signifie que la courbe combinée peut pénaliser un produit pour changer sa mix de revenus.
Une cohorte n'est comparable que lorsque ses conditions d'entrée sont comparables.
Les erreurs de timestamp entraînent une forme plus discrète de corruption. Enregistrez les timestamps des événements de manière cohérente, définissez explicitement le jour 0 et décidez si l'analyse utilise la date locale de l'utilisateur ou une zone horaire de rapportage canonique. Une application mondiale peut autrement compter une installation tardive et une ouverture le lendemain matin comme des jours de cycle de vie différents pour un comportement similaire.
La rétention basée sur l'installation a une limitation supplémentaire. Elle compte à partir de la population d'installation ou d'ouverture initiale, mais elle ne dit pas si les utilisateurs qui n'ont jamais atteint l'expérience centrale de l'application ont été acquis sous des attentes trompeuses. Si une campagne promet une fonctionnalité que l'application ne livre pas immédiatement, les données de cohorte au niveau du canal devraient guider l'enquête avant que les ingénieurs ne réécrivent le produit.
Intégrer les informations de cohorte à la stratégie de publication et de mise à jour
La gestion de publication crée des cohortes naturelles. Les utilisateurs qui reçoivent la version A, la version B, un déploiement étalé ou une mise à jour de maintenance peuvent être suivis séparément, à condition que l'application enregistre la version et le canal de publication pertinent au moment de l'exposition.
Cela fait de la rétention un signal de publication plutôt qu'un rapport rétrospectif. Une chute soudaine le jour 1 d'une nouvelle version peut indiquer un plantage, une erreur d'authentification, une migration brisée ou une régression d'inscription. La courbe de cohorte ne peut pas identifier la cause racine par elle-même, mais elle peut indiquer aux ingénieurs que la nouvelle population se comporte différemment et mérite une enquête immédiate.
Utilisez des limites fixes pour les comparaisons de déploiement
Un workflow de déploiement utile ressemble à ceci :
- Définir l'exposition : Enregistrer la version de l'application, le canal de déploiement, la plateforme de périphérique, le pays et l'heure de l'exposition.
- Créer des cohortes correspondantes : Comparer les utilisateurs exposés à la nouvelle version avec les utilisateurs du référentiel de base précédent sous les mêmes conditions calendaires et d'acquisition.
- Inspecter la courbe : Examiner la rétention le jour 1, le jour 7 et le jour 30, ainsi que les plantages, les événements échoués et l'activation de base.
- Choisissez une action : Promouvez, mettez en pause, itérez ou revenez en arrière en fonction des preuves combinées.
Un nouveau flux de démarrage déployé à un petit public peut montrer une meilleure retenue précoce car le public venait d'une campagne différente. Ce résultat n'est pas suffisant pour étendre le déploiement. Conservez les sources d'acquisition et les limites de cohorte constantes, ou utilisez une affectation randomisée, afin que les effets de version ne transmettent pas un effet marketing.
Analyse des correctifs nécessite la même discipline. Taguez les utilisateurs qui ont rencontré un bug pour la première fois, les utilisateurs qui ont reçu le correctif et les utilisateurs qui sont restés sur la version précédente. Si la cohorte post-correctif retrouve son chemin d'activation tandis que la cohorte non réparée continue de s'éloigner, les preuves soutiennent une intervention de mise à jour. Si les deux groupes se comportent de la même manière, le bug peut ne pas expliquer la chute initiale.
Les équipes gérant les mises à jour de mobiles peuvent utiliser des stratégies de mise à jour d'applications mobiles pour relier les choix de déploiement aux mesures. Les cohortes basées sur les versions deviennent plus utiles lorsque les canaux de mise à jour, les événements d'adoption et les états de panne font partie du même modèle d'événement.
Au-delà des cohortes d'installation, d'événement et de revenu
La retenue d'installation répond à une question étroite : les utilisateurs sont-ils revenus après l'installation ? Elle ne vous dit pas si les utilisateurs ont complété l'action qui crée de la valeur, si ils ont élargi leur utilisation ou si ils ont généré des revenus. Un produit peut maintenir une courbe d'installation respectable tout en échouant à faire progresser les utilisateurs à travers son flux de travail principal.
Les cohortes d'événements rendent cette progression visible. Définissez un événement d'activation qui représente une valeur réelle, et non un proxy tel que l'ouverture d'une page. Pour une application de fitness, cela pourrait être la réalisation d'un premier entraînement. Pour une application financière, cela pourrait être la réalisation d'une transaction de base autorisée. Pour une application de collaboration, cela pourrait être la création et la partage d'un projet.
Les cohortes de revenus ajoutent la couche économique. Groupez les utilisateurs par premier achat, début de souscription, niveau de plan ou événement de facturation, puis suivez les revenus et les utilisations ultérieurs. Normalisez les comparaisons entre les niveaux de souscription et les lots de ventes en ligne pour éviter de confondre une cohorte à haut revenu avec une expérience de produit universellement meilleure.
Affichez la progression aux côtés du comportement de retour
Une table de revue de sprint utile doit garder les définitions de cohorte visibles :
| Type de cohorte | Définition | Retenue du jour 1 | Retenue du jour 7 | Retenue du jour 30 | Insight principal |
|---|---|---|---|---|---|
| Installation | Utilisateurs regroupés par première ouverture de l'application | Mesuré à partir de l'installation | Mesuré à partir de l'installation | Mesuré à partir de l'installation | Qualité d'acquisition et d'incorporation |
| Événement | Utilisateurs regroupés par première activation significative | Mesuré à partir de l'activation | Mesuré à partir de l'activation | Mesuré à partir de l'activation | Si les utilisateurs activés continuent à trouver de la valeur |
| Revenu | Utilisateurs regroupés par première transaction ou abonnement | Mesuré à partir de la conversion | Mesuré à partir de la conversion | Mesuré à partir de la conversion | Durabilité de la monétisation et TCV |
Les cellules doivent contenir vos valeurs mesurées, et non des cibles génériques. Les benchmarks varient par catégorie et modèle, et La discussion des benchmarks de retenue de UXCam résume les fenêtres couramment utilisées de jour 1, jour 7 et jour 30 tout en mettant en avant le rôle de la dérive du mois un et du mois trois dans l'analyse du cycle de vie.
Les contraintes de confidentialité rendent cette définition plus large de plus en plus importante. Lorsque l'attribution est incomplète, les équipes doivent se fier davantage aux événements de première partie, aux jalons du cycle de vie et aux enregistrements de revenus plutôt que de considérer la source d'installation comme une explication complète du comportement. La définition de cohorte la plus utile est celle qui est la plus proche de la valeur du produit que vous essayez d'améliorer.
Affichez la retenue d'installation aux côtés de la retenue d'activation et de la retenue de revenus. Si la retenue d'installation reste plate mais les utilisateurs activés s'améliorent, l'onboarding peut être le levier principal. Si la retenue d'activation reste forte mais la retenue de revenus se dégrade, le prix, l'heure de mise en paywall, le bon fit du plan ou l'expérience de facturation mérite l'attention. Cette séparation tient les équipes d'acquisition, de produit et de monétisation responsables de la partie du cycle de vie qu'elles peuvent influencer.
Capgo fournit des mises à jour en temps réel pour les applications CapacitorJS et Electron, permettant aux équipes de livrer des modifications ciblées de JavaScript, de CSS, de configuration et de biens, tout en suivant l'adoption, les échecs, les signaux de retrait et la diffusion de versions. Capgo Évaluez si son flux de déploiement convient à votre processus de mesure de version.
