Seulement 25.3% of mobile app users return on Day 1, et la rétention moyenne tombe à 5,7 % le jour 30 à travers 31 catégories d'applications mobiles dans le monde, selon les indicateurs de rétention d'applications mobiles de Business of AppsCette courbe ne vous indique pas si le problème est une mauvaise acquisition, un flux d'inscription confus ou une faible valeur produit. L'analyse de cohorte d'applications vous le dit.
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 cohorte sépare ces groupes, les suit chacun 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 réparer.
Table des matières
- Why App Cohort Analysis Reveals What Aggregate Metrics Hide
- Types de Cohorts et Quand les Utiliser Chacun
- Les Métriques Clés qui Pilotent les Décisions de Cohortes
- Calcul des Cohorts avec SQL et Outils d'Analyse
- Pièges courants et fausses interprétations des données de cohorte
- Relier les Intuitions de Cohortes aux Stratégies de Lancement et de Mise à Jour
- Au-delà de la rétention d'installation, des cohortes d'événements et de revenus
Why App Cohort Analysis Reveals What Aggregate Metrics Hide
Un nombre de rétention global est utile comme check de santé, mais il s'agit d'un mauvais outil de diagnostic. Si les publicités payantes, les recherches organiques, les références et les campagnes de partenaires alimentent un tableau de bord mélangé, le résultat décrit la mélange d'utilisateurs plus qu'il ne décrit le 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.
Le graphique ci-dessus montre pourquoi le premier mois mérite une attention particulière. Le même rapports les moyennes iOS de rapports des moyennes iOS 25,65 % le jour 1 et 4,13 % le jour 30, tandis que l'Android atteint 23,01 % le jour 1 et 2,59 % le jour 3011,3% de rétention le jour 30 dans les actualités à 2,1% dans l'éducation 11,3 % de fidélité au jour 30 dans les actualités à 2,1 % dans l'éducationLe graphique ci-dessus montre pourquoi le premier mois mérite une attention particulière. Le même
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. Lire à travers une ligne montre comment un seul groupe vieillit. Lire en descendant une colonne compare différents groupes au même stade de leur cycle de vie.
Cette distinction change la question de « Pourquoi la rétention est-elle basse ? » en :
- Qualité de l'acquisition : Un campagne a-t-il attiré des utilisateurs qui n'avaient pas l'intention d'utiliser le produit ?
- Friction de l'abonnement : Les utilisateurs ont-ils installé mais échoué à accomplir la première étape significative ?
- La livraison de valeur : Est-ce que les utilisateurs activés ont disparu après l'expérience initiale ?
- Impact de la mise à jour Est-ce que la nouvelle version a modifié la courbe pour les utilisateurs qui l'ont reçue ?
A 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 cohorte, l'amélioration est annulée par la moyenne. À l'inverse, un grand nombre global peut cacher une chaîne de paiement 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 seul. Décomposez le résultat par source d'acquisition, pays, plateforme, chemin d'abonnement et version de l'application en premier lieu.
Le cadre de rétention de l'application est utile lorsqu'on transforme ce diagnostic en une vue plus large de la durée de vie. Le point opérationnel est simple : l'analyse des cohortes vous dit où la courbe se brise, tandis que la segmentation 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énement 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.
Cohorts basées sur l'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'abonnement et l'analyse d'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 rétention précoce et les changements dans l'expérience de première utilisation.
Cohorts basées sur les événements commencez par un comportement significatif, tel que la réalisation de l'onboarding, la création d'un projet, la fin d'un entraînement, ou l'envoi d'un premier message. Ils suppriment certaines des perturbations entre l'installation et l'activation. Si les utilisateurs qui ont terminé leur premier entraînement restent actifs plus longtemps que les utilisateurs qui n'ont fait que s'installer, le problème d'onboarding est probablement en train de prévenir la découverte de la valeur plutôt que refléter une défaillance de retenue à l'échelle du produit.
cohorts basées sur les revenus ancrer les utilisateurs à leur première transaction, au début d'une souscription, au niveau de plan, ou à un autre événement de monétisation. Ces cohorts soutiennent l'analyse de la valeur à long terme, les décisions de remboursement et les comparaisons entre les modèles d'affaires. Un utilisateur abonné et un utilisateur soutenu par des publicités ne devraient pas être jugés par des attentes de retenue identiques, car leur valeur économique et leurs incitations à l'engagement diffèrent. couverture de la retenue mobile rapports sur 14% Day 30 retention for subscription apps versus roughly 5.4% for ad-supported appslaquelle rend indispensable la normalisation du modèle commercial.
guide de sélection pratique
| Type de cohorte | Meilleur pour | Question clé répondue | Exemple de déclencheur |
|---|---|---|---|
| Install-based | Croissance et onboarding | Retourne-t-ils après acquisition et première utilisation ? | Première ouverture de l'application |
| Event-based | Activation du produit | Fait-une action significative prédit-elle une utilisation continue ? | Première séance d'entraînement |
| Revenue-based | Monétisation et finances | Comment la valeur se développe-t-elle après la conversion ? | Première acquisition ou abonnement |
A un application de fitness, il est possible que les utilisateurs qui terminent leur premier entraînement dans les 24 heures retiennent mieux que la cohorte d'installation complète. Cette découverte ne prouve pas que l'entraînement cause la retenue, mais elle donne à l'équipe de produit une hypothèse d'activation testable. La prochaine étape consiste à réduire le chemin menant à cet entraînement, puis à comparer des cohortes contrôlées de manière appropriée.
Utiliser segmentation des utilisateurs par plan et par canal pour conserver les dimensions qui affectent la justice. Une définition de cohorte devrait enregistrer son événement d'ancrage, sa zone horaire, son canal, son pays, sa plateforme, son abonnement et sa version d'application. Sinon, deux lignes avec le même étiquette peuvent représenter des populations matériellement différentes.
Les Métriques Clés Qui Orientent Les Décisions De Cohorte
Rétention, dérive et LTV 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 retenue mesure la part d'une cohorte originale qui effectue 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 pourrait être une ouverture de l'application. Pour une cohorte d'événement, il pourrait s'agir d'un entraînement complet 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 au cours de 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 la révenue récurrente. Un résultat Day 1 élevé suivi d'une forte baisse Day 30 suggère que la première expérience fonctionne mieux que la valeur à long terme.
Valeur à vie mesures de revenu cumulatif généré par un groupe, divisé par la taille du groupe.
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 du groupe est plus facile à auditer. Cela empêche également une erreur courante, consistant à considérer le revenu des convertisseurs précoces comme preuve que la source d'acquisition entière est rentable.
Lisez les indicateurs ensemble
Un petit groupe de valeur élevée peut paraître exceptionnel tout en échouant à s'agrandir. Normalisez chaque groupe en fonction de sa population initiale, puis comparez la révenue et la rétention aux côtés du coût d'acquisition, du canal, du pays, de la plateforme et du modèle d'entreprise. N'évaluez pas les groupes uniquement en fonction de la plus haute valeur à vie ou de la meilleure rétention précoce.
Les plages de benchmark fournissent un contexte plutôt qu'un grade de réussite ou d'échec. Les applications de haut niveau rapportent généralement 30–40% de rétention Day 1, 10–15% de rétention Day 7 et 5–8% de rétention Day 30, while median apps sit closer to 25%, 8%, et 4% at those milestones, according to Résumé du benchmark de fidélité de SetgreetComparez votre application avec la bonne catégorie et le bon modèle d'affaires avant d'attribuer un écart à l'expérience utilisateur.
Le Guide d'analyse de la dérive des utilisateurs Propose une complément utile à la table des cohortes. Les cohortes montrent quand la dérive se produit. L'analyse de la dérive doit ensuite identifier quel comportement de l'utilisateur, quelle source d'acquisition ou quelle condition de produit a précédé cela.
Calculer les 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 une events table avec user_id, event_name, et event_at Les champs suivants créent des cohortes d'installation hebdomadaires et mesurent si chaque utilisateur a généré un événement d'activité aux âges de cycle 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, joignez les activités ultérieures à cet ancrage, calculez l'âge et divisez les utilisateurs distincts qui sont revenus par la population initiale 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 le niveau de calcul
| Dimension | SQL brut / Magasin de données | Plateforme d'analyse de produits |
|---|---|---|
| Normalisation personnalisée | Fort, prend en charge les jointures entre dépenses, CRM et facturation. | Limité par les propriétés disponibles |
| Rapid configuration | Exige des tables modélisées et des requêtes testées | Rapide pour les rapports de cohorte standard |
| Travail à la carte | Flexible dès que le modèle de données est prêt | Excellent pour les analystes et les équipes de produits |
| Reproductibilité | Contrôlé par version et auditable | Dépend des définitions et des permissions enregistrées |
| Best fit | Rapportage de qualité financière et attribution complexe | Questions de produits et exploration rapide |
Amplitude, Mixpanel et Firebase fonctionnent généralement bien pour une première approche. 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 base de données SQL devient plus précieuse lorsque vous avez besoin de joindre les dépenses publicitaires, les remboursements, l'état de souscription 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éesPuisque la table de bord de cohorte ne modifie les décisions que lorsque les équipes produit, marketing, finance et ingénierie ont confiance dans les définitions. Pour les événements de cycle de vie personnalisés, Capgo’s plugin de suivi d’événements peut être considéré en parallèle de l'instrumentation d'analytique déjà présente dans l'application.
Common Pitfalls and How Teams Misread Cohort Data
Une équipe peut créer une table de cohorte correcte sur le plan technique et encore 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 un nouveau écran d'inscription 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.
- Activation de l'événement de noyau.
- Répétition de l'événement de valeur.
- Comportement de revenu ou d'abonnement.
A late-stage cohort is conditional. It answers how activated users behave, not how efficiently the product creates activated users.
Les canaux mixtes créent des moyennes trompeuses
Le paradoxe de Simpson est un risque réel lorsque les utilisateurs payants et les utilisateurs organiques partagent une même ligne. Une courbe combinée peut augmenter après que le mélange de canaux se déplace vers une source plus forte, même si la rétention diminue dans les deux canaux. Le tableau enregistre le changement de composition, et non une amélioration du produit.
Contrôlez la source d'acquisition avant d'évaluer une mise à jour ou un changement de prise en charge. Gardez les campagnes, les pays, les plateformes, les versions de l'application et les modèles de monétisation disponibles en tant que dimensions. Le modèle commercial compte également. Le fossé de rétention entre les applications sous abonnement et les applications avec publicité rapportées dans la source de référence précédente 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 causent 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 rapportation 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 retenue basée sur l'installation présente une limitation supplémentaire. Elle compte à partir de la population d'installation ou de première ouverture, mais elle ne précise 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 l'ingénierie ne réécrit le produit.
Connexion des Cohort Insights aux stratégies de Lancement et de Mise à Jour
Gestion de lancement crée des cohortes naturelles. Les utilisateurs qui reçoivent la version A, la version B, un déploiement étalé ou un correctif chaud peuvent être suivis séparément, à condition que l'application enregistre la version et le canal de lancement pertinent au moment de l'exposition.
Cela fait de la retenue un signal de lancement plutôt qu'un rapport rétrospectif. Une chute soudaine du jour 1 dans 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 avertir l'ingénierie 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.
- Inspectez la courbe : Examinez la rétention des jours 1, 7 et 30, ainsi que les crashes, 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 a été publié pour un petit public et montre peut-être une meilleure rétention précoce car le public provenait 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 héritent pas d'un effet marketing.
Analyse de la mise à jour de hotfix 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 la correction et les utilisateurs qui sont restés sur la version précédente. Si le groupe de cohorte post-correction récupère sa trajectoire d'activation tandis que le groupe non réparé continue à 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.
Équipes gérant les mises à jour mobiles peuvent utiliser des stratégies d'actualisation d'applications mobiles pour relier les choix de déploiement à la mesure. Les cohortes basées sur la version deviennent plus utiles lorsque les canaux de mise à jour, les événements d'adoption et les états de failure font partie du même modèle d'événement.
Au-delà de la rétention d'installation, des cohortes d'événements et de revenus
L'installation répond à une question étroite : les utilisateurs sont-ils revenus après l'installation ? Elle ne vous dit pas si ils ont complété l'action qui crée de la valeur, si ils ont élargi l'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 première commande, début de souscription, niveau de plan ou événement de facturation, puis suivez les revenus et l'utilisation 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.
Rapportez 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 | Rétention au jour 1 | Rétention au jour 7 | Rétention au jour 30 | Insight principal |
|---|---|---|---|---|---|
| Installation | Utilisateurs regroupés par première application ouverte | 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 | Les utilisateurs activés continuent-ils à 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 TTV |
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 Discussion de référence de retenue de UXCam Résume les fenêtres courantes de jour 1, jour 7 et jour 30, 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 de 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 se rapproche le plus 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 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, le timing de la barrière de paiement, le bon ajustement du plan ou l'expérience de facturation mérite l'attention. Cette séparation garde 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, CSS, de configuration et d'actifs tout en suivant l'adoption, les échecs, les signaux de retrait et la diffusion de versions. Capgo évaluer si son flux de déploiement correspond à votre processus de mesure de la mise en production.
