Métriques & funnels

Cette page définit ce que veulent dire nos chiffres et comment on les regarde. Sans définitions partagées, deux personnes lisent le même mot différemment.

Métriques clés (définitions)

Métrique	Définition
Inscrit	A terminé l’onboarding. C’est le chiffre qu’on communique et celui de la data-room. À ne pas confondre avec un compte créé : depuis le 10/8/26 la base crée la ligne de profil dès l’authentification, donc quelqu’un qui abandonne l’onboarding existe en base sans être un inscrit. Le cockpit HARU expose les deux séparément (« inscrits » d’un côté, « comptes créés » de l’autre).
Utilisateur activé	A terminé l’onboarding et a une date d’arrêt au passé ou aujourd’hui. C’est le vrai compteur d’utilisateurs, pas le nombre d’inscrits.
Conversion (abonnement)	Part des personnes ayant fini l’onboarding une semaine donnée qui ont payé dans les 7 jours (J7). On lit la dernière cohorte hebdomadaire entièrement mûre (chaque jour a eu ses 7 jours) — jamais une fenêtre glissante qui mélangerait des cohortes mûres et des cohortes récentes pas encore converties. Calculée depuis PostHog : onboarding_completed (trafic test exclu) → rc_initial_purchase_event. RevenueCat reste la source de vérité du revenu. Depuis le 16/8/26, HARU affiche trois fenêtres côte à côte — voir « Trois conversions » ci-dessous.
Acheteur de 1re session vs tardif	Achat dans les ~30 min suivant l’inscription = 1re session ; au-delà = acheteur tardif. Une part importante des achats sont tardifs.
Rétention D1 / D7 / D30	Part des utilisateurs encore actifs (ouverture d’app) 1, 7, 30 jours après leur inscription, par cohorte hebdo.

La conversion ne dit rien du churn

La conversion mesure l’acquisition seule : parmi les gens arrivés récemment, combien ont sorti la carte bleue. Quelqu’un qui s’abonne puis se désabonne reste un converti — il a converti. Si le nombre d’abonnés baisse, ça se voit dans le churn et dans les abos actifs, jamais dans la conversion.

C’est pour ça que la conversion se lit sur une cohorte (les onboardés d’une même semaine) et pas sur toute la base depuis le début. Une conversion « abonnés actuels ÷ tous les inscrits depuis toujours » mélangerait deux questions différentes (est-ce qu’on convertit ? est-ce qu’on retient ?) et baisserait toute seule à mesure que la base grandit — même avec une app en parfaite santé.

Pourquoi J7 et pourquoi seulement les semaines mûres. L’horizon est fixé à 7 jours : c’est au-delà du délai d’achat médian et ça capte l’essentiel des conversions, tout en restant lisible une semaine après la cohorte. Et on n’affiche qu’une cohorte entièrement mûre : une cohorte récente n’a pas fini de convertir, donc l’inclure ferait « baisser » le chiffre artificiellement (c’est le piège d’une fenêtre glissante non bornée — elle sous-estime en permanence ses jours les plus récents). Le prix à payer est un retard d’environ deux semaines : le chiffre est volontairement en retard et honnête plutôt que frais et faux.

Trois conversions, trois usages (depuis le 16/8/26)

La règle de maturité ci-dessus a un effet mécanique qu’il faut connaître : une semaine devient affichable quand son lundi + 13 jours est passé, donc la tuile J7 change de semaine tous les dimanches à 00:00 UTC. Concrètement, un changement livré dans l’app ne se voit dans ce chiffre que deux semaines plus tard. C’est trop lent pour piloter, et pas comparable à ce que publient les autres. HARU a donc une zone Conversion dédiée, avec trois fenêtres qui ne se lisent pas l’une contre l’autre :

Tuile	Fenêtre	Dénominateur	Retard	Sert à
Conversion J1	payé dans les 24 h, cumulé sur les 7 dernières cohortes journalières mûres	onboardés (PostHog)	~2 jours	juger un changement d’app dans la semaine où il est livré
Conversion J7	payé dans les 7 jours, dernière semaine mûre	onboardés (PostHog)	~13 jours	la référence interne, la seule des trois qui déclenche une alerte
Conversion J30	payé dans les 30 jours, dernier mois complet	nouveaux clients RevenueCat	~1 mois	la comparaison externe (benchmark Santé & Fitness, docs investisseurs)

Ne jamais comparer J1, J7 et J30 entre elles

Les deux premières comptent les onboardés ; la J30 compte les nouveaux clients RevenueCat, c’est-à-dire toute première ouverture de l’app, y compris les gens qui n’ont jamais fini l’inscription. Le dénominateur de la J30 est donc bien plus large, et son taux mécaniquement plus bas à performance égale. Un écart entre les trois tuiles ne veut rien dire — chacune se compare à elle-même dans le temps.

« J1 » et « 7 jours » ne parlent pas de la même chose

Dans la tuile J1, deux durées cohabitent. J1, c’est la fenêtre de conversion : on compte les gens qui ont payé dans les 24 h suivant la fin de leur onboarding. Les 7 jours, c’est la période d’agrégation : on additionne 7 cohortes journalières pour avoir assez de volume — un seul jour, c’est environ 110 inscrits et 5 achats, le taux sauterait de 0 à 8 % sans que rien n’ait changé.

La sous-note de la tuile dit donc « cohortes du 8 au 14/8 », et non « 7 j » : lu à côté de « J1 », un « 7 j » se confond avec la fenêtre de la tuile J7 juste en dessous.

Ce que la J1 rate. Mesuré sur cohortes mûres : la fenêtre 24 h ne capte que 77 % (Android) à 86 % (iOS) des achats que la fenêtre J7 finit par voir. Son niveau est donc structurellement bas, et c’est assumé — on y lit un mouvement, jamais un niveau. Pour la même raison, la J1 et la J30 sont sans seuil : elles n’allument pas le bandeau et ne réveillent personne sur Slack. La J7 reste la seule tuile de conversion qui alerte.

Note

Les chiffres financiers (MRR, essais, renouvellements) se lisent dans RevenueCat, pas dans PostHog. PostHog reçoit les events rc_* pour pouvoir croiser revenu et comportement, mais RevenueCat fait foi.

Propriétés utilisateur (segmentation)

Posées sur le profil PostHog pour pouvoir filtrer tous les events.

Propriété	Posée quand	Mise à jour
auth_method	Inscription (setOnce)	Jamais
signup_date	Inscription (setOnce)	Jamais
initial_platform / initial_language	Inscription (setOnce)	Jamais
cigarettes_per_day	Onboarding	Profil
years_smoking, quit_timeline, previous_attempts, why_quit_reasons	Onboarding	Selon
motivation_level	Plus posée — l’étape motivation a quitté l’onboarding en 1.6.1 (27/7/26)	Ré-émise à l’ouverture depuis le profil enregistré, donc présente uniquement sur les comptes créés avant cette date
quit_date	Onboarding / profil	À chaque changement
onboarding_completed	Onboarding	Jamais
is_premium	Inscription (false)	Auto via RevenueCat
notification_permission_status	À chaque ouverture d’app	À chaque ouverture
att_status (iOS)	Résolution ATT	À la résolution

Propriétés « super » (rattachées à chaque event) : is_premium, notification_permission_status, days_since_quit. notification_permission_status et days_since_quit sont ré-enregistrées à chaque passage au premier plan ; is_premium suit désormais l’abonnement en continu — elle est posée dès l’ouverture (sans attendre le profil) et re-posée à chaque changement d’entitlement.

is_premium avant la 1.8.0 : deux pièges

1. Elle pouvait être en retard. Enregistrée une seule fois par passage au premier plan, après un appel réseau, elle ratait l’Application Opened autocapturé, était absente avant la connexion (aucune valeur sur ~la moitié des paywall_viewed) et ne bougeait pas si l’abonnement changeait en cours de session. Une révocation survenue app en arrière-plan laissait donc is_premium: true sur toute la session suivante.
2. Le nom voulait dire deux choses. Sur lesson_started il désignait la leçon (contenu payant), pas l’utilisateur. Renommé key_is_premium en 1.8.0. Les données antérieures gardent l’ancien nom : toute analyse à cheval sur la 1.8.0 doit lire les deux.

Funnels

Funnel	Étapes	Décision qu’il éclaire
F1 — Drop-off onboarding	onboarding_started → onboarding_step_completed (de first_name à signup) → onboarding_completed	Quel step simplifier/supprimer s’il dépasse 15 % de perte. Filtrer social_signup ≠ true (les revenants via login social faussent le funnel).
F2 — Inscription → 1er engagement	onboarding_completed → quit_date_updated → lesson_started (clé 0)	La clé 0 gratuite sert-elle de hook d’activation ?
F3 — Gratuit → payant	paywall_viewed → rc_initial_purchase_event	Quel point d’entrée du paywall optimiser. Breakdown par source.
F4 — Aide à l’envie	craving_help_started → craving_trigger_submitted → craving_activity_started → craving_activity_completed	Quelles activités mettre en avant vs retirer.
F5 — Progression programme	key_completed (clé 0) → … → key_completed (clé 7)	Où les gens décrochent dans le programme.
F6 — Date d’arrêt → 30 jours	quit_date_updated → health_milestone_reached (24h → 30j)	À quel moment les gens rechutent → caler les notifications locales de soutien sur cette fenêtre.
F7 — Quiz pré-arrêt (Suivi)	tracking_empty_state_viewed → quiz_started → onboarding_quiz_completed	Chez les gens sans date d’arrêt : combien voient l’état vide de Suivi, ouvrent un quiz, le terminent. Breakdown par quiz_type. Les deux premières étapes ne se peupleront qu’après la prochaine mise en production.
F8 — Relance quiz par notif	notification_opened (category quiz) → quiz_started (source=quiz_reminder) → onboarding_quiz_completed	Efficacité de la notification de relance quiz à faire revenir les gens sans date d’arrêt : taux de tap, puis complétion. Breakdown par quiz_type. Se peuple après la prochaine mise en production. Sans dénominateur d’envoi depuis le retrait de notification_scheduled (5/8/26) : on mesure ce que le tap produit, pas le taux de tap sur les notifs programmées.

F3 donne un taux, pas une contribution

F3 répond à « quel écran convertit le mieux », jamais à « quel écran rapporte le plus », parce qu’il ne montre pas combien de gens voient chaque écran. Deux tuiles SQL sur le dashboard Revenue complètent F3 sans le remplacer (créées le 18/8/26) :

• « Paywall — contribution par surface (90 j) » — par surface : exposés, visibilité (part de la base active qui la voit), abonnements, conversion, part des abonnements.
• « Paywall — conversion vs exposition (90 j) » — le même contenu en nuage de points, un point par surface, exposition en échelle log.

Mesure du 18/8/26 sur 90 j : profile convertit à 15,5 % pour 43 abonnements, quand onboarding_end convertit à 4,7 % pour 259, soit 51 % du total. Le taux et l’argent ne classent pas les surfaces dans le même ordre.

Quatre précautions inscrites dans les requêtes :

• Attribution last-touch, un achat rattaché au dernier paywall vu dans les 24 h. Le reste tombe dans « (non attribué) » : 12 achats au 18/8/26, dont 10 orphelins RevenueCat de juin 2026 — le bug d’identité RC→PostHog corrigé le 10/6, leur session d’achat n’a jamais été rattachée au compte, 9 d’entre eux n’ont aucun event client et le 10ᵉ voit son historique commencer par l’achat lui-même — et 2 achats tardifs (59 h et 49 j après le dernier paywall vu). Ce n’est donc pas un trou d’instrumentation du paywall.
• Fenêtre fixe de 90 j, indépendante du filtre de date du dashboard — une tuile de contribution a besoin de volume.
• onboarding_end est vu par construction, pas par intention : son 4,7 % est un plancher. À l’inverse profile est auto-sélectionné (on y va pour s’abonner) : son taux ne survivrait pas à une exposition de masse.
• La colonne « Plafond théorique » applique la conversion observée à tous les non-acheteurs actifs. C’est une borne haute, pas une prévision : elle ignore l’auto-sélection ci-dessus. Masquée sous 100 exposés / 5 abonnements, où le taux ne veut rien dire.

Le réglage « internal & test users » du projet ne s’applique pas au SQL brut : les filtres sont recopiés à la main dans les deux requêtes (cohorte 111468, app Kaiho Dev, émulateur, TestFlight). Si le réglage du projet change, il faut les remettre à jour ici.

La comparaison qui compte le plus : poser une date d’arrêt prévue

Ce n’est pas un funnel mais une comparaison de deux groupes, donc une tuile SQL : « Poser une date d’arrêt prévue → arrêter vraiment », sur le dashboard Health Outcomes (créée le 5/8/26).

Parmi les gens inscrits en fumant encore (quit_timeline = today ou later), le taux d’arrêt réel selon qu’ils ont posé une date prévue ou non. Mesure du 5/8/26 sur 90 j : 45,8 % contre 7,8 %, soit 5,9×. C’est le prédicteur le plus fort qu’on ait sur la transformation réelle — et planned_quit_date_set n’avait jusque-là aucune tuile.

Deux précautions inscrites dans la requête :

• Les gens qui arrivent déjà arrêtés (alreadyQuit, ~86 % des « libres ») sont exclus : ils n’ont aucune transformation à faire dans l’app, et les garder gonflait le taux sans rien dire de ce que l’app produit.
• Le pourcentage est un taux d’arrêt, pas de rétention : quit_date_updated dit qu’une date a été posée, pas que la personne a tenu.

Attention au sens de lecture : c’est une corrélation. Poser une date prévue est aussi un signe qu’on est déjà décidé. Ça reste le levier le plus prometteur à pousser, mais ça ne prouve pas à soi seul la causalité.

Pas de funnel « essai → payant »

Kaiho ne propose pas d’essai gratuit (choix de Vincent, pas d’intro offer). Les events rc_trial_* n’existent donc pas dans les données : on n’en compte qu’un seul de chaque, daté du 23/4/26, laissés par le branchement initial de l’intégration RevenueCat — ce ne sont pas de vrais essais. Un funnel d’essai serait vide, et l’insight « Trial Conversion » qui traînait sur le dashboard Revenue a été supprimé le 31/7/26 : ne pas le recréer. La conversion se mesure directement paywall_viewed → rc_initial_purchase_event (funnel F3).

Cohortes

Cohorte	Définition	Usage
Activés	onboarding_completed + date d’arrêt passée/aujourd’hui	Le vrai nombre d’utilisateurs
Power users	5+ ouvertures d’app en 7j + 3+ lesson_completed en 7j	Le noyau dur
Combattants de l’envie	3+ craving_activity_completed (à vie)	Utilisent activement les outils
À risque	Pas d’ouverture depuis 3j et days_since_quit < 30	Cible de ré-engagement
En difficulté	relapse_video_started ou quit_date_updated avec source=profile	Soutien renforcé
Acheteur impulsif / tardif	rc_initial_purchase dans / au-delà des 24h après onboarding_completed	Comprendre ce qui déclenche l’achat
Gros fumeurs	cigarettes_per_day ≥ 20	Rétention et besoins différents

Reconstruit depuis le code

Les funnels et cohortes ci-dessus s’appuient sur les events réellement émis (voir le catalogue). Les dashboards et funnels concrets dans PostHog se créent au fil de l’eau ; cette page décrit l’intention, pas l’état exact de l’instance PostHog à un instant T.