KPIs
Produit
Les KPIs produit mesurent si le produit tient sa promesse. Pas si les utilisateurs sont nombreux — si la valeur est réelle.
L'ICI (Identity Completeness Index) est la métrique maîtresse de BeYourself. Elle mesure la maturité du profil d'identité de chaque utilisateur. Formule : (items_analysés/50 × 0.4) + (logs_tenues/20 × 0.35) + (jours_actifs/14 × 0.25). Un utilisateur avec ICI > 0.7 est 5× moins susceptible de churner. Un ICI moyen D30 > 0.5 indique que le produit crée de la vraie valeur identitaire — pas juste de l'engagement. C'est le seul KPI dont la croissance seule justifie une décision d'investissement.
% d'utilisateurs qui complètent les 5 questions et voient leur premier profil. En dessous de 60% → le questionnaire est trop long ou mal posititionné.
% d'utilisateurs activés qui uploadent 10+ items dans les 7 premiers jours. Seuil critique : en dessous de 10 items, le moteur de suggestion ne peut pas produire de valeur réelle.
% d'utilisateurs qui acceptent (portent) au moins une suggestion dans leurs 7 premiers jours. C'est l'aha moment réel — l'app a prouvé qu'elle comprend l'utilisateur.
| KPI | Cible | Alarme | Interprétation |
|---|---|---|---|
| Suggestion Acceptance Rate (SAR) | >55% | <30% | % des suggestions matinales acceptées. C'est le pouls quotidien de la qualité du moteur. SAR < 30% = profil immature OU moteur défaillant. SAR > 80% = monotonie (suggère toujours les mêmes combos). |
| Outfit Log Rate (OLR) | >60% des jours actifs | <25% | % de jours actifs avec au moins un outfit loggé. Un utilisateur qui ouvre l'app sans logger ne nourrit pas le profil. L'habitude de log est différente de l'habitude d'ouverture. |
| Purchase Check Utilization | >1.2/mois (premium) | <0.4/mois | Nombre moyen de purchase checks par utilisateur premium par mois. Trop faible = la feature n'est pas découverte. Trop élevé (>5) = peut indiquer un usage anxieux à surveiller. |
| Journal Consultation Rate | >35% des MAU/semaine | <15% | % des utilisateurs actifs mensuel qui consultent leur journal au moins une fois par semaine. Signal de rétention émotionnelle longue durée. |
| Profile View Frequency | >2× / semaine | <0.5× / semaine | Fréquence moyenne de consultation du profil d'identité. Le profil est le miroir — les utilisateurs engagés s'y regardent régulièrement. Trop rare = le profil n'est pas assez compelling. |
| Feature Breadth Score (FBS) | >3 features utilisées | <2 features | Nombre moyen de features distinctes utilisées par MAU. Les utilisateurs avec FBS < 2 churner 3× plus vite que ceux avec FBS > 3. Corrélé directement à la LTV. |
Le time-to-value est le temps entre l'installation et le premier moment où l'utilisateur pense "cette app me comprend". Il ne se mesure pas directement — il se mesure par proxy.
| Proxy | Cible | Méthode |
|---|---|---|
| Temps installation → profil_v0 vu | <6 minutes | Firebase event timestamp : install → profile_v0.viewed |
| Temps profil_v0 → première suggestion | <25 minutes | Timestamp profil_v0.viewed → suggestion.first_viewed |
| Temps installation → première suggestion acceptée | <40 minutes | Timestamp install → suggestion.accepted (first occurrence) |
| Score ICI > 0.3 atteint | <D5 | Calculé quotidiennement par le ProfileService, loggé dans analytics |
KPIs
Business
Les KPIs business traduisent la viabilité économique. Ils répondent à une seule question : est-ce que ce produit peut survivre et scaler ?
Segmenté en 3 flux : B2C premium (€8.99/mois), B2B Pro stylistes (€49-79/mois), et annuel (€74.99). Suivre le MRR net (nouveaux − churns − downgrades). Le MRR brut sans le churn masque des problèmes de rétention critiques.
LTV B2C cible : €8.99 × 18 mois = ~€162. CAC acceptable : <€54. En dessous de 3:1, le modèle n'est pas viable à l'échelle. En dessus de 8:1, on sous-investit en acquisition.
% d'utilisateurs actifs mensuels convertis en payants. Benchmark SaaS consumer : 2-5%. BeYourself cible 15-20% car la valeur perçue est forte et le prix est bas. En dessous de 10% → le paywall est mal timé.
| KPI | Cible M12 | Cible M24 | Signal d'alarme |
|---|---|---|---|
| MRR Total | €50-80K | €300K+ | Croissance < 10%/mois consécutif |
| LTV B2C Premium | €140-180 | €160-200 | LTV < €80 = rétention insuffisante |
| LTV B2B Pro | €900-1200 | €1200-1800 | Churn Pro > 8%/mois |
| CAC blended | <€40 | <€35 | CAC > €60 = canaux payants non viables |
| ARPU (tous utilisateurs) | €1.5-2.5/mois | €3-5/mois | ARPU < €1 = taux de conversion structurellement faible |
| Gross Margin | >65% | >75% | < 50% = coûts IA non maîtrisés |
| Churn MRR mensuel | <5% | <3% | >8%/mois = problème rétention structurel |
| Payback period (CAC) | <6 mois | <4 mois | >12 mois = modèle en danger sans capitaux externes |
Tous les triggers du paywall ne convertissent pas de la même façon. Il est essentiel de segmenter les conversions par trigger pour optimiser le timing de l'upsell.
| Trigger | Taux conversion attendu | LTV post-conversion |
|---|---|---|
| Score Clarity > 60% ("profil complet") | 28-35% | Haute — utilisateur engagé |
| Limite 50 items atteinte | 22-28% | Haute — utilisateur actif |
| 3ème purchase check du mois | 15-20% | Moyenne-haute |
| Suggestion refusée 2 fois ("plus d'options") | 8-12% | Moyenne — frustation possible |
| Paywall proactif sans trigger précis | <4% | Basse — mauvais timing |
KPIs
Techniques
Les KPIs techniques ne sont pas des métriques d'ingénierie abstraites. Chacun a un impact direct mesurable sur la rétention ou la conversion.
| KPI | Cible | Impact UX si dégradé | Source |
|---|---|---|---|
| Crash Rate | <0.3% sessions | +1% crash rate = -3% D7 retention (correlation mesurée sur apps lifestyle). Un crash pendant l'onboarding = abandon définitif dans 70% des cas. | Firebase Crashlytics |
| AI Analysis Latency (p95) | <18 secondes | Au-delà de 20s p95, le taux d'abandon pendant l'upload grimpe à 35%. L'animation de progression masque la perception jusqu'à 15s — au-delà, même l'animation ne suffit pas. | Cloud Monitoring + custom event |
| Suggestion Load Time (après notification) | <500ms p95 | La suggestion matinale doit être instantanée — l'habitude se forme sur la fluidité. Chaque seconde de délai réduit le taux d'ouverture de la notification suivante de ~8%. | Firebase Performance + custom trace |
| Push Delivery Rate | >95% | Si le push ne se délivre pas, l'habitude matinale ne se forme pas. Surveiller séparément iOS (APNs) et Android (FCM) — les taux divergent souvent. | FCM delivery reports |
| Firestore Read Cost / User / Day | <€0.05 | Pas d'impact UX direct mais impact business critique à l'échelle. À 100K users × €0.08/jour = €8K/mois rien qu'en lectures Firestore. À surveiller dès 10K users. | GCP Billing + cost allocation labels |
| AI Cost per Item Analyzed | <€0.08 (cible €0.04 avec cache) | Le coût AI est le principal driver de la marge brute. Au-delà de €0.12/item, la marge tombe sous 50% sur les utilisateurs très actifs. | OpenAI dashboard + GCP cost labels |
| App Cold Start (iOS) | <2.0 secondes | Un cold start > 3s est perçu comme un crash par les utilisateurs. Sur la routine matinale, un cold start lent = frustration immédiate avant même de voir la suggestion. | Firebase Performance · app_start trace |
| Offline Core Functionality | >80% des actions disponibles offline | Le wardrobe browse et le journal doivent fonctionner sans connexion. Un utilisateur en avion ne doit pas voir une app vide. | Firestore offline cache + test scenarios |
// alerte_critique : si crash_rate > 1% sur une version en production → rollback immédiat via Firebase App Distribution. Si AI analysis latency p95 > 30s → désactiver les appels OpenAI Vision en temps réel et passer en mode queue avec notification "analyse en cours". Ces deux seuils sont non-négociables.
KPIs
Acquisition
Tous les canaux ne se valent pas. La règle absolue : aucun canal dont le CAC dépasse LTV/3 ne peut être scalé.
Le K-factor mesure la croissance organique engendrée par chaque utilisateur : K = (invitations_envoyées × conversion_invitation). Un K > 1 signifie une croissance exponentielle autonome (rare). Un K de 0.3-0.5 est un objectif réaliste et déjà très efficace pour réduire la dépendance à la publicité payante.
| Vecteur viral | K cible | Mesure |
|---|---|---|
| Wrapped partagé → install depuis le share | 0.12-0.18 | UTM tracking sur toutes les cards partagées → Firebase event referral.converted |
| Invitation directe (referral program) | 0.08-0.14 | Referral code usage + conversion dans les 7 jours |
| Profil public partagé par styliste | 0.05-0.10 | Link sharing + conversion depuis la page profil publique |
| K-factor total (tous vecteurs) | >0.30 | Calculé mensuellement — si K trend > 0.4 à M6, scale organique possible sans paid |
KPIs
Rétention
La rétention est la vérité du produit. On peut acheter l'acquisition. On ne peut pas acheter la rétention.
Barre large = cible BeYourself · Barre fine sous-jacente = benchmark industrie apps mode
L'analyse de cohorte brute (D30 global) masque les dynamiques importantes. Segmenter par les variables qui prédisent réellement la rétention :
Améliorer le taux d'opt-in push à J1 est le levier de rétention le plus direct
Re-demander la permission à J7 avec contexte clair. Widget iOS comme fallback
Obsession onboarding : bulk import, gamification upload, progress bars
Déclencher flow de réactivation à J3 si items < 8 : "3 pièces de plus changent tout"
Meilleur segment de rétention. Prioriser le scale du canal Pro Stylistes
Confirme l'inutilité des paid social pour BeYourself — arrêter ce canal immédiatement
| Signal | Habitude installée | Usage superficiel |
|---|---|---|
| Ouverture via push | >60% des sessions | <20% des sessions (ouvre de lui-même sans trigger) |
| Outfit logs en semaine | >3 logs/semaine | <1 log/semaine |
| Items uploadés | >25 items total | <12 items (seuil minimal) |
| Consultation profil | >2×/semaine | <1×/2 semaines |
| Score ICI | >0.65 | <0.3 |
| Features utilisées | >3 features distinctes | 1 seule feature (suggestion seule) |
Tracking
Événements
Les événements sont la grammaire de l'analytics. Un événement manqué est une décision aveugle. Un événement superflu est du bruit.
Propriétés obligatoires sur TOUS les events : user_id (hashed), platform (ios/android), app_version, subscription_status (free/premium/pro), items_count (taille du dressing actuel), ici_score (Identity Completeness Index actuel). Ces 6 propriétés permettent de segmenter n'importe quel event par l'état de l'utilisateur — indispensable pour les décisions produit.
Dashboards
4 dashboards. Chacun répond à une question différente pour une audience différente. Pas de dashboard fourre-tout.
- DAU / MAU ratio (cible >35%)
- Suggestion Acceptance Rate 7j glissant
- ICI moyen des nouveaux utilisateurs D7
- D1 / D7 retention dernière cohorte
- Nouvelles activations cette semaine
- Push delivery rate (iOS + Android)
- Crash rate dernières 24h
- Nouveaux installs par canal (semaine)
- Funnel complet install → activé par cohorte
- K-factor viral (trend 4 semaines)
- CAC par canal (semaine glissante)
- Taux conversion landing → install
- Pro accounts nouvelles inscriptions
- App Store ratings (évolution)
- MRR total (+ trend 4 semaines)
- MRR par flux (B2C / Pro / Annuel)
- Freemium → Premium conversion rate
- Churn MRR mensuel
- Paywall trigger performance comparée
- LTV / CAC ratio (par canal)
- Gross Margin (AI costs vs revenue)
- Crash rate iOS + Android (séparé)
- AI analysis latency p50/p95/p99
- Firebase costs / jour (trend)
- AI cost / item analyzed (avec cache %)
- Cloud Functions error rate par service
- Notification delivery rate iOS / Android
- Firestore reads / user / day
// outils_recommandés : PostHog (product + growth dashboards) auto-hébergé EU pour la conformité RGPD. Firebase Analytics pour les events mobiles natifs. GCP Billing Budgets pour les alertes de coût. Stripe Dashboard pour le revenue. Ne pas créer de dashboard personnalisé en V1 — utiliser les outils existants jusqu'à 100K users.
Reporting
Le reporting ne sert à rien s'il ne génère pas de décision. Chaque rapport doit terminer par une action concrète ou une question ouverte, jamais par un récapitulatif des métriques.
| Trigger | Condition | Destinataire | Sévérité | Action |
|---|---|---|---|---|
| Crash Rate Spike | Crash rate > 1% en moins de 1h | CTO + PM | Critical | Rollback immédiat de la dernière version. Incident post-mortem dans 24h. |
| AI Pipeline Failure | Error rate Cloud Tasks > 15% sur 30 min | Engineering lead | Critical | Basculer en mode dégradé : items uploadés sans analyse. Alerter les utilisateurs affectés. |
| Firebase Cost Spike | Coût journalier GCP > 150% du budget prévu | CTO + CEO | High | Identifier la source (Firestore reads / AI calls) et corriger dans les 4h. |
| SAR Chute Prolongée | SAR 7j glissant < 30% pendant 3 jours | PM | High | Investigation : bug dans le moteur de suggestion ou changement de profil utilisateur. A/B test d'urgence. |
| Churn MRR Spike | Churn MRR semaine > 2× la moyenne des 4 dernières semaines | CEO + PM | High | Survey de churn automatique envoyé aux utilisateurs annulés. Analyse cohorte d'urgence. |
| Push Delivery Failure | FCM delivery rate < 85% sur une heure | Engineering | Medium | Vérifier status FCM / APNs. Si problème Firebase, activer fallback email pour la suggestion matinale. |
5 métriques : DAU, SAR, crash rate, AI latency p95, coût Firebase du jour. Format Slack automatisé (PostHog integration). Pas de narration — chiffres + flèche de tendance. Si tout est vert, 30 secondes de lecture suffisent.
Rétention dernière cohorte, funnel acquisition par canal, SAR trend, conversion premium, ICI moyen. Format : 1 slide par sujet + 1 décision ou question actionnée par sujet. Pas de narration descriptive — chaque section termine par "décision prise" ou "hypothèse à tester".
MRR, LTV/CAC, churn, cohort D30 du mois, unit economics par canal, coûts infrastructure vs revenus. Ce rapport est la seule fois par mois où toutes les métriques business sont vues ensemble. Format : 8-10 slides maximum. Conclusion : "le produit est en bonne / mauvaise / alertante santé — voici pourquoi."
Contexte marché + nos métriques vs objectifs du trimestre + apprentissages clés + plan Q suivant. Format court (1 page ou 10 slides). Inclure les mauvaises nouvelles avec leur explication — un investisseur qui découvre un problème dans un reporting qu'il ne savait pas existait est bien plus dangereux qu'un investisseur informé des mêmes problèmes.
La règle du reporting BeYourself : aucun rapport sans "et donc ?" La fin de chaque section — hebdo, mensuel, investisseur — doit explicitement nommer la décision prise ou la question ouverte générée par les données. Un rapport qui se termine sur des données sans action est du bruit documenté.