Build in Public #12 : J'ai branché PostHog sur mon App. L'audit de la vérité.
300k+ vues, des centaines de téléchargements, mais une rétention catastrophique. Je pensais que Sam Tennis cartonnait, mais les données m'ont remis à ma place. Voici l'audit brut de la v1 de Sam Tennis.
TL;DR : J'ai généré 300 000+ vues organiques sur TikTok & Instagram pour mon app Sam Tennis. L'acquisition était folle, mon ego était gonflé à bloc. Mais la réalité produit m'a rattrapé : la rétention est catastrophique. J'ai utilisé le MCP de PostHog dans Cursor pour auditer ma propre base de données. Le constat fait mal : 85% de mes utilisateurs sont inexploitables à cause d'un bug de tracking, mon funnel est cassé, et j'ai 0 automatisation en place. Voici l'audit brut et sans filtre ainsi que mon plan de bataille pour trouver de la rétention.
Les 3 points clés (Key Takeaways)
- • Le "Trou Noir" analytique : 85% de ma base utilisateurs est inexploitable parce que la propriété
isPremiumn'est jamais définie pour les utilisateurs gratuits. - • Le funnel est cassé : PostHog attribue deux identités différentes au même utilisateur (avant et après inscription), rendant le tunnel de conversion inutilisable.
- • Le MCP change la donne : L'intégralité de cet audit a été réalisée depuis Cursor, sans ouvrir un seul dashboard, grâce au protocole MCP de PostHog.
Ma Stack pour cet Audit
Voir tous les outilsJ'ai réalisé 100% de cette analyse sans quitter mon IDE, grâce au protocole MCP.
Product analytics et session replay
L'IDE nouvelle génération avec IA intégrée
Certains liens sont des liens affiliés. Je ne recommande que des outils que j'utilise réellement.
Si tu as lu le chapitre précédent, tu sais que j'ai structuré la V2 de Sam Tennis avec la méthode BMAD. Le code est plus propre, l'architecture est documentée. Mais avant de coder la V2, il fallait comprendre pourquoi la V1 ne retenait personne.
C'est le piège classique du Solo Builder. On construit un MVP, on lance des campagnes marketing, on regarde les métriques de "vanité" (les vues, les clics), on célèbre, puis on retourne coder de nouvelles fonctionnalités en pensant que tout va bien.
Mais ces dernières semaines, mon tableau de bord RevenueCat de Sam Tennis (mon coach IA de poche) ne bougeait pas. 5 utilisateurs Premium au total. C'est tout.
Il fallait que j'arrête de marketer une application qui ne plaisait pas au marché. J'ai donc décidé de faire une pause dans la distribution et de faire un audit complet de mes données.
C'est à ce moment que j'étais content d'avoir installé PostHog au lancement de mon app. J'avais vu que la majorité des projets indie l'utilisent, et je comprends pourquoi : c'est le seul outil qui centralise analytics, session replays, feature flags et sondages dans un plan gratuit. Plutôt que de passer des heures dans l'interface PostHog, j'ai utilisé Cursor et le MCP (Model Context Protocol) de PostHog. J'ai littéralement demandé à mon IDE : "Connecte-toi à mon compte PostHog, extrais toutes mes données d'événements, fais-moi un audit ultra détaillé de mes utilisateurs."
Une fois le MCP branché, l'IA a accès à toute ma base de données PostHog en temps réel.
Ce que l'IA a trouvé m'a fait redescendre sur terre très vite.
Mon assistant IA génère le rapport complet sans que j'ouvre le moindre dashboard.
1. La claque des chiffres bruts
Voici la synthèse exécutive de mon audit (période de 80 jours) :
Le seul dashboard existant, pollué par des événements en double. L'IA l'a vu tout de suite.
- Utilisateurs totaux : ~479
- Utilisateurs Premium : 5 (Soit ~1% de la base)
- Utilisateurs gratuits identifiés : 66 (14%)
- Utilisateurs sans statut (
isPremium= null) : 408 (85% de la base)
Le "Trou Noir" Analytique
Oui, tu as bien lu. 85% de ma base utilisateurs est inexploitable. J'ai 408 personnes qui utilisent l'application (et qui génèrent des coûts d'API LLM), mais je suis incapable de savoir si elles sont censées être gratuites ou non.
Pourquoi ? Une erreur de débutant dans mon code d'onboarding.
Lorsqu'un utilisateur s'inscrivait, mon appel posthog.identify() n'attribuait la propriété isPremium que si l'utilisateur achetait quelque chose. Si l'utilisateur passait l'onboarding gratuitement, je ne renseignais rien. Résultat : des valeurs null partout, m'empêchant de calculer mon vrai taux de conversion "Free to Paid".
2. Le Funnel d'Acquisition Cassé
J'ai demandé au MCP de me générer mon tunnel d'acquisition principal :
Install → Onboarding → Activation (Premier message) → Achat
Le résultat renvoyé par PostHog était lunaire :
- 151 installations
- 1 seul utilisateur passé à l'étape "Onboarding Step" (0.66% de conversion).
- 0 achat finalisé selon le funnel.
Pourtant, en regardant les données brutes, j'avais eu 77 onboardings complétés et 5 achats.
Le verdict de l'IA (Diagnostic) :
Grâce au MCP, Cursor lit la taxonomie et comprend exactement pourquoi le tunnel est cassé.
Mon application envoyait l'événement "Application Installed" avant que l'utilisateur ne se crée un compte. PostHog lui assignait donc un ID Anonyme (ex: user_123).
Ensuite, quand l'utilisateur se connectait, j'utilisais l'ID de ma base de données (Supabase). PostHog ne faisait pas le lien entre l'ID Anonyme et l'ID Supabase.
Pour l'outil, l'utilisateur qui a installé l'app et l'utilisateur qui l'utilise n'étaient pas la même personne. Funnel cassé net.
3. Le Taux de Rétention : L'hémorragie
En utilisant la matrice "Growth Accounting" de PostHog (New vs Returning vs Dormant), j'ai regardé l'activité sur les 30 derniers jours :
- Nouveaux utilisateurs acquis : 98
- Utilisateurs "Returning" (qui reviennent d'une semaine sur l'autre) : 14
- Flux de "Dormants" (qui abandonnent) : Plus de 136 utilisateurs perdus.
En moyenne, presque aucun utilisateur ne revient après la première semaine. L'hémorragie.
La conclusion est sans appel : L'application perd massivement ses utilisateurs. La croissance n'était soutenue que par mes vidéos virales sur TikTok. Dès que j'arrête d'acquérir de nouveaux curieux, l'app se vide. En moyenne, seulement 2 à 3 utilisateurs reviennent par semaine de manière organique.
4. Les fonctionnalités fantômes (et l'argent gaspillé)
L'audit a également mis en lumière le code "mort". Des fonctionnalités que j'ai codées, maintenues, mais que plus personne n'utilise.
opponent_edited: 0 événement depuis 77 jours.
Mais le pire, c'est ce que je n'utilise pas dans PostHog :
- 0 Action définie : Mes événements bruts sont en vrac, pas structurés par "Intentions".
- 0 Survey (Sondage) : J'ai un taux de désinstallation massif, et je n'ai JAMAIS demandé à un utilisateur "Pourquoi quittez-vous l'app ?".
- 0 Workflow (Alerte/Email) : Quand un utilisateur bloque dans l'onboarding, je ne le relance pas.
C'est un constat honnête : j'étais concentré sur le développement, le déploiement Android, l'acquisition. La data était un sujet "pour plus tard". Sauf que "plus tard", c'est maintenant, et 80 jours de données mal exploitées, ça fait mal. Si tu veux éviter de reproduire ces erreurs sur ton propre projet, j'ai publié un Guide Complet PostHog qui couvre l'implémentation correcte dès le jour 1.
5. Le Plan de Bataille (Sprint V2)
Faire cet audit a été douloureux pour l'ego, mais c'était la meilleure chose à faire. On ne peut pas améliorer ce qu'on ne mesure pas correctement.
Plutôt que de coder des nouvelles "features" ou envoyer des utilisateurs dans un funnel percé, voici mon plan d'action immédiat pour la V2 de Sam Tennis, dicté par les datas :
Étape 1 : Corriger les fondations du Tracking (En cours)
Je dois nettoyer ma dette technique analytique.
- Mettre un
isPremium: falsesystématique à l'inscription. - Corriger le "merge d'identités" entre l'installation anonyme et le profil Supabase pour réparer mon funnel.
Étape 2 : Activer la Rétention Proactive
Si les gens partent, c'est qu'ils oublient l'app ou qu'ils ne comprennent pas la valeur ajoutée quotidienne.
- Création de Workflows PostHog : Si un user s'inscrit mais n'envoie pas de message au coach sous 48h -> Notification de relance automatique pour l'encourager à échanger.
- Rendre Sam plus proactif dans les échanges. Je veux qu'il se rapproche le plus possible d'un coach personnel qui prend des nouvelles de ses joueurs.
Étape 3 : Déployer le module de Sondages (Surveys)
Je vais arrêter de deviner.
- Un mini-sondage discret qui s'affichera au bout de 7 jours d'inactivité : "Qu'est-ce qui vous empêcherait de revenir sur Sam Tennis ?"
Étape 4 : Le Tracking LLM
Étant donné que Sam Tennis est basé sur l'IA, chaque message me coûte de l'argent. Je dois activer le dashboard "LLM Analytics" de PostHog pour tracker mon coût par utilisateur (Cost per User USD) et vérifier que mon plan Premium couvre bien les frais de serveurs.
Conclusion : Le MCP change la donne
Le plus fou dans cette histoire, ce ne sont pas les erreurs que j'ai commises. C'est la manière dont je les ai découvertes.
Il y a un an, il m'aurait fallu passer des heures dans l'interface de PostHog, exporter des CSV, et essayer de faire sens de tout ça.
Aujourd'hui, mon agent IA a lu les définitions de mes événements en direct depuis la base de données, m'a pointé du doigt l'erreur sur la variable isPremium, m'a écrit le ticket de bug, et va m'aider à corriger le code dans le même espace de travail.
C'est ça, la puissance du Vibe Coding structuré. Les données ne sont plus une corvée post-lancement, elles sont le carburant de la prochaine ligne de code.
Si tu veux comprendre PostHog en profondeur (toutes les fonctionnalités, les erreurs de coûts à éviter, le MCP), j'ai publié un Guide Complet PostHog qui couvre tout ça.
La semaine prochaine, on attaque le code de la V2. Je te montrerai les premiers résultats des correctifs de tracking et si la courbe de rétention commence enfin à s'inverser.
À très vite,
Guillaume 👋
🎯 Construis ta propre machine
Tu ne veux pas faire les mêmes erreurs que moi sur ton premier projet ? J'ai mis à jour mon simulateur gratuit pour qu'il te recommande les bons outils analytiques dès le Jour 1.
Lancer le Simulateur Solo Builder
Questions fréquentes
Pourquoi mon funnel PostHog montre 0% de conversion alors que j'ai des utilisateurs ?
C'est probablement un problème de merge d'identités. Si ton app envoie un événement (comme "Application Installed") avant que l'utilisateur ne se crée un compte, PostHog lui attribue un ID anonyme. Quand l'utilisateur s'inscrit ensuite, il reçoit un nouvel ID (Supabase, Firebase, etc.). Si le merge entre les deux n'est pas configuré via posthog.identify(), PostHog considère que ce sont deux personnes différentes. Ton funnel est cassé sans que tu le saches.
Comment auditer son application avec le MCP PostHog dans Cursor ?
Tu ajoutes le serveur MCP PostHog dans les paramètres de Cursor avec ta clé API et ton Project ID. Ensuite, tu demandes à l'IA d'interroger tes événements, tes propriétés utilisateurs et tes funnels directement depuis l'IDE. C'est ce que j'ai fait pour cet audit : l'IA a lu ma taxonomie d'événements, identifié le bug isPremium = null, et rédigé le diagnostic complet sans que j'ouvre l'interface de PostHog.
Comment éviter le "trou noir" de la propriété isPremium sur PostHog ?
La règle est simple : définis toujours isPremium: false dans ton appel posthog.identify() au moment de l'inscription. Ne définis isPremium: true que lors de l'achat. Si tu ne renseignes rien pour les utilisateurs gratuits, la propriété reste à null et tu perds toute capacité de segmentation entre tes utilisateurs free et payants.
📚 Pour aller plus loin
- Guide Complet PostHog 2026 - Toutes les fonctionnalités, les erreurs de coûts à éviter
- Build in Public #11 : La méthode BMAD - Comment j'ai structuré la V2 de Sam Tennis
- Protocol MCP : Connecter l'IA à tes outils - Le protocole qui a rendu cet audit possible
- Voir tous mes outils recommandés
Tu veux suivre la suite de cette aventure Build in Public ?
Rejoindre 2000+ Solo Builders