Build in Public #12 : J'ai branché PostHog sur mon App. L'audit de la vérité.

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.

🔍 Ma Stack pour cet Audit

Voir tous les outils

J'ai réalisé 100% de cette analyse sans quitter mon IDE, grâce au protocole MCP.

PostHogPartenaire

Product analytics et session replay

Cursor

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.

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 heureux d'avoir installé PostHog au lancement de mon app. Je ne connaissais pas l'application mais en regardant de nombreuses vidéos, quasiment tous les projets l'utilisent. Et je comprends pourquoi. Plutôt que d'aller sur l'application PostHog et de passer du temps sur l'interface, j'ai utilisé Cursor et le MCP (Model Context Protocol) de PostHog. J'ai littéralement demandé à mon IDE : "Connecte-toi à mon compte PostHog, extrait toutes mes données d'événements, fais moi 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.

Bon ça peut faire un peu défaitiste. Après tout c'est un peu normal, j'étais concentré à développer l'app, la rendre dispo également sur Android, générer des nouveaux utilisateurs, etc. Maintenant, je me suis bien documenter sur PostHog parce qu'avoir de la donnée propre qu'on peut analyser, c'est la base. Si tu veux comprendre comment paramétrer ça correctement, j'ai publié un Guide Complet sur PostHog.

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: false systé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'ils se rapprochent le plus possible d'un coach personnel qui prend des nouvelles de ses clients

É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.

On se retrouve la semaine prochaine pour voir si ces correctifs ont enfin inversé la courbe.

🎯 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