PostHog

Notre point de vue sur PostHog

Le product analytics moderne demande plusieurs outils empilés : Mixpanel pour les events, Hotjar pour les heatmaps, VWO pour l'A/B test, FullStory pour le replay. Chaque outil coûte, chacun a son interface, chacun trace de son côté. PostHog résout ce stack splitting en proposant tout dans une plateforme unique, gratuite jusqu'à un certain volume et open source.

Le tradeoff : PostHog est plus dense à apprendre que des outils spécialisés. Pour un client qui veut juste savoir ses pages vues, GA4 suffit. PostHog brille quand l'enjeu devient comprendre un parcours utilisateur ou itérer sur la conversion.

Quand on choisit PostHog

• Site avec funnel de conversion sérieux. Signup, onboarding, achat. Comprendre où les utilisateurs décrochent et tester des variantes.
• Équipe data-driven. Quand le client a un PM ou un growth qui va vraiment exploiter les données. Sans utilisateur final, l'outil ne sert à rien.
• Besoin de session replay. Voir concrètement ce que font les utilisateurs sur le site, par-dessus les chiffres bruts.
• Volume modéré. Le free tier de PostHog est généreux (millions d'events). Au-delà, le pricing reste raisonnable comparé à Mixpanel + Hotjar + VWO empilés.

Quand on déconseille PostHog

• GA4 suffit largement. Si le besoin se limite à pages vues, sources de trafic, audience démographique. Ne pas surcharger.
• Données ultra-sensibles côté replay. Le session replay peut capturer des informations sensibles. Sur des sites avec données médicales ou financières, on désactive ou on filtre rigoureusement.
• Contrainte souveraineté stricte. PostHog Cloud est hébergé US ou UE. Pour une souveraineté française stricte, il faut self-host (possible mais pluslourd).
• Pas de PM pour exploiter. Sans utilisateur qui regarde les dashboards et prend des décisions, l'outil collecte des données dans le vide.

Comment on l'utilise concrètement chez Justa

1. Installation via Google Tag Manager

On déploie le script PostHog via GTM plutôt qu'en custom code direct dans Webflow. Permet aux équipes marketing de garder la main sur l'activation et les conditions de chargement.

2. Events custom sur les actions clés

Au-delà des pages vues automatiques, on instrumente les events qui comptent : clic CTA principal, soumission de form, ouverture de pricing, ajout au panier. Nommage standardisé pour simplifier l'analyse.

3. Heatmaps sur les pages clés

Heatmaps activées sur la home, les landing pages stratégiques et les pages de pricing. On regarde les données mensuelles plutôt qu'en temps réel pour avoir des volumes représentatifs.

4. A/B tests sur les hypothèses fortes

Quand le client a une hypothèse claire (changement de hero, nouveau wording de CTA, nouvelle structure de pricing), on déploie un A/B test PostHog avec un objectif de conversion mesurable. Pas d'A/B test sans hypothèse claire.

Les limites qu'on gère

• Courbe d'apprentissage. PostHog est dense : Insights, Funnels, Cohorts, Feature Flags, Experiments. Demande une vraie formation pour exploiter.
• Performance si mal configuré. Tracker tous les events automatiquement peut alourdir la page. On configure le sampling et on désactive les autocaptures inutiles.
• Privacy par défaut à durcir. Le replay capture par défaut beaucoup. On masque toujours les inputs sensibles, les zones avec données utilisateur, et on respecte le consentement RGPD.
• Coûts qui peuvent monter. Au-delà du free tier, les volumes de replay et d'events facturent. À provisionner si le site génère beaucoup de trafic.

Alternatives qu'on connaît aussi

• GA4. Notre minimum sur tous les projets. Suffit pour 60 % des besoins analytics standards.
• Mixpanel. Plus polished, plus cher, focalisé events. Pertinent si l'équipe le connaît déjà.
• Plausible. Privacy-first, simple, hébergé UE. Notre choix quand le client veut éviter le cookie consent et que les besoins analytics restent simples.
• Hotjar. Spécialiste heatmaps et replay, simple à déployer. Pertinent si on n'a pas besoin du reste de PostHog.