PostHog peut remplacer plusieurs outils analytics si votre priorité est de relier mesure produit, replays, feature flags, tests A/B et données utilisateurs. Le point clé n’est pas l’installation du snippet, mais la qualité du plan de tracking.
À quoi sert vraiment PostHog ?
PostHog sert à comprendre ce que font les utilisateurs dans un produit, puis à agir directement sur cette compréhension. Il ne se limite pas à compter des pages vues. Il regroupe product analytics, web analytics, session replay, feature flags, A/B testing, enquêtes in-app, CDP et synchronisation vers data warehouse autour d’un même flux d’événements.
Le problème classique, je le vois souvent dans les équipes produit. Google Analytics mesure le trafic. Hotjar enregistre les sessions. LaunchDarkly gère les feature flags. Typeform collecte du feedback. Un autre outil lance les expérimentations. Des exports SQL finissent dans un entrepôt de données. Chaque outil a sa propre logique d’identification, ses propres événements, ses propres filtres. Résultat : les données se croisent mal, ou trop tard.
PostHog part d’une idée plus simple : un événement correspond à une action utilisateur horodatée, par exemple une inscription, un clic, une recherche ou un paiement. À partir de ces événements, la documentation officielle PostHog décrit plusieurs briques natives : funnels pour mesurer les étapes d’un parcours, tendances pour suivre l’évolution d’un indicateur, rétention pour savoir si les utilisateurs reviennent, chemins pour comprendre les parcours réels, dashboards pour suivre les métriques clés.
Comme on dit à Brive, un bon plan de marquage vaut mieux qu’un bon reporting ! Si besoin, consultez moi - faites appel à un super consultant en tracking client et server side.
Les termes méritent d’être posés clairement. Le product analytics sert à analyser les actions dans un produit, pas seulement les visites sur un site. Le session replay permet de revoir une session utilisateur, avec les logs console et les requêtes réseau pour comprendre les erreurs techniques. Un feature flag permet d’activer une fonctionnalité pour une partie des utilisateurs. L’A/B testing compare deux variantes pour mesurer laquelle performe le mieux. Une CDP, pour Customer Data Platform, centralise et redistribue les données clients vers d’autres outils.
PostHog ajoute aussi les enquêtes in-app, dont le NPS pour mesurer la recommandation et le CSAT pour mesurer la satisfaction. Ses pipelines envoient les données vers plus de 60 destinations. Son entrepôt SQL permet d’interroger les événements directement avec SQL, le langage standard pour questionner des bases de données.
| Besoin équipe produit | Fonctionnalité PostHog | Décision rendue possible |
| Comprendre où les utilisateurs abandonnent | Funnels, chemins, tendances | Prioriser les frictions produit à corriger |
| Diagnostiquer un bug ou une incompréhension | Session replay, logs console, requêtes réseau | Reproduire le problème et réduire le temps d’analyse |
| Lancer une fonctionnalité sans risque | Feature flags, A/B testing | Tester sur un segment avant généralisation |
| Collecter du feedback utilisateur | Enquêtes in-app, NPS, CSAT | Relier satisfaction et comportement réel |
| Exploiter les données ailleurs | CDP, pipelines, entrepôt SQL | Synchroniser les données avec le reste de la stack |
Comment son modèle de données fonctionne-t-il ?
PostHog n’est fiable que si son modèle de données est compris avant de créer des dashboards, des flags ou des expériences. Je le vois comme une pyramide simple : plus la base est propre, plus les analyses au-dessus tiennent debout.
Les propriétés décrivent le contexte. Une propriété répond à une question comme “sur quelle page ?”, “avec quel plan ?”, “depuis quelle campagne ?”. Par exemple, l’événement cta_viewed peut contenir les propriétés page_url, cta_text ou utm_source.
Les événements représentent les actions suivies. Un événement doit décrire quelque chose qui s’est réellement passé : cta_viewed, workshop_registered, lead_generated. Si ces noms changent toutes les deux semaines, vos funnels deviennent vite inutilisables, car PostHog ne peut plus comparer proprement les étapes dans le temps.
Les personnes agrègent les actions d’un même utilisateur. Un visiteur anonyme peut voir un CTA, puis s’inscrire à un atelier, puis devenir lead. Quand il est identifié, PostHog rattache ces événements au même profil. Sans identification correcte, une cohorte ou un parcours utilisateur peut être fragmenté entre plusieurs visiteurs “fantômes”.
Les cohortes regroupent des utilisateurs selon des attributs ou des comportements. Une cohorte peut contenir “les leads générés après inscription à un atelier” ou “les utilisateurs actifs sur les 30 derniers jours”. Elle devient utile pour cibler un flag, analyser une rétention ou comparer un segment dans un dashboard.
Les groups servent surtout en B2B, quand l’unité d’analyse n’est pas seulement la personne, mais l’entreprise, le compte ou l’organisation. Un lead peut appartenir à une entreprise, et plusieurs personnes peuvent appartenir au même compte. Cela permet de mesurer l’activation d’un compte plutôt que l’activité isolée d’un utilisateur.
Le lien avec les usages est direct. Un funnel dépend d’événements propres. Une cohorte dépend de profils bien identifiés. Un test A/B dépend souvent d’un flag, c’est-à-dire une règle qui active une variante pour certains utilisateurs, et d’un objectif mesurable comme lead_generated. Un dashboard devient fiable seulement si les événements restent stables.
| Couche | Rôle | Erreur fréquente à éviter |
| Propriétés | Ajouter le contexte d’un événement. | Stocker une action comme propriété au lieu d’en faire un événement. |
| Événements | Mesurer les actions importantes comme cta_viewed, workshop_registered ou lead_generated. | Changer les noms sans convention stable. |
| Personnes | Relier plusieurs actions au même utilisateur. | Oublier l’identification après inscription ou connexion. |
| Cohortes | Créer des segments d’utilisateurs selon leurs comportements ou attributs. | Construire des cohortes sur des données incomplètes. |
| Groups | Analyser une entreprise, un compte ou une organisation en contexte B2B. | Tout mesurer au niveau utilisateur alors que la décision se prend au niveau compte. |
Comment installer PostHog proprement ?
Installer PostHog proprement ne se limite pas à copier un snippet JavaScript dans votre site. Le vrai sujet, c’est de rendre les données exploitables : savoir quels événements suivre, avec quelles propriétés, et à quel moment relier un visiteur anonyme à un utilisateur identifié.
La mise en place repose sur trois étapes. La première consiste à installer le snippet JavaScript PostHog sur les pages concernées. C’est souvent la partie la plus simple. La deuxième consiste à décider quels événements capturer : inscription, clic sur un appel à l’action, activation d’une fonctionnalité, fin d’onboarding, achat, désabonnement. La troisième consiste à identifier les utilisateurs au bon moment, par exemple après une connexion ou une inscription.
Beaucoup d’équipes réussissent la première étape, puis dégradent la qualité des données avec des événements trop vagues, dupliqués ou jamais documentés. Un événement doit décrire une action claire. Une propriété doit préciser le contexte.
posthog.capture('cta_viewed', { cta_name: 'posthog_audit' })Dans cet exemple, l’événement cta_viewed indique qu’un appel à l’action a été vu. La propriété cta_name précise lequel. Cette distinction évite de créer dix événements différents pour dix boutons similaires.
L’identification utilisateur mérite une attention particulière. Elle permet de relier une session anonyme à un compte connu, donc de suivre un parcours complet avant et après inscription. Sans cela, vous analysez souvent deux demi-parcours au lieu d’un parcours utilisateur cohérent. Cette identification doit rester compatible avec vos contraintes de confidentialité : ne collectez pas de données inutiles, évitez les informations sensibles, et appliquez le principe de minimisation prévu par le RGPD, c’est-à-dire collecter uniquement ce qui est nécessaire.
Google Tag Manager peut aider à déclencher certains événements sans demander un déploiement développeur à chaque modification. C’est utile pour des clics marketing, des vues de formulaires ou des tests rapides. Mais GTM ne remplace pas un plan de tracking, ni une convention de nommage partagée. Sans règles claires, il accélère surtout la création de dette analytics.
- Snippet PostHog posé sur les pages concernées.
- Événements validés avec les équipes produit, marketing et data.
- Propriétés documentées avec leur signification et leur format.
- Identification utilisateur testée avant et après connexion.
- Environnement de recette vérifié avant passage en production.
Quels événements faut-il vraiment suivre ?
Je garde une règle simple avec PostHog : suivre les événements qui éclairent une décision produit, marketing ou business, pas tout ce qui bouge dans l’interface. Un bon événement doit aider à répondre à une question précise : Où les utilisateurs bloquent-ils ? Quel canal génère des leads ? Quelle action annonce une activation ?
PostHog propose l’autocapture, c’est-à-dire l’enregistrement automatique des clics, des soumissions de formulaires et des pages vues. C’est pratique pour démarrer vite, surtout quand le plan de tracking n’est pas encore stabilisé. Mais le risque arrive rapidement : trop de volume, des événements difficiles à lire, des coûts qui montent et des dashboards moins exploitables. Si votre site dépasse environ 2 000 sessions par mois, je recommande de désactiver l’autocapture et de passer sur des événements définis à la main. Même logique pour les Web Vitals, les métriques techniques de performance perçue par l’utilisateur : si personne ne les analyse, mieux vaut les désactiver.
Un plan de tracking simple tient en quelques étapes. Il faut partir des questions métier, lister les moments clés du parcours, nommer les événements avec un schéma clair, documenter les propriétés attendues, puis vérifier la donnée en recette avant mise en production.
Le format objet_action fonctionne bien : cta_viewed, workshop_registered, lead_generated. Il est plus robuste que click_button ou submit_form, car il décrit le sens métier de l’action, pas seulement le geste technique. Un clic peut vouloir dire dix choses. Un lead généré, non.
| Événement | Moment du parcours | Propriétés utiles | Question à laquelle il répond |
| cta_viewed | Affichage d’un appel à l’action | page, cta_id, position, variant | Quels CTA sont réellement exposés aux visiteurs ? |
| workshop_registered | Inscription à un atelier ou webinaire | workshop_id, source, user_type | Quels sujets transforment le mieux ? |
| lead_generated | Soumission qualifiée d’un formulaire | form_id, offer, company_size, acquisition_channel | Quels canaux produisent des leads utiles ? |
| trial_started | Démarrage d’un essai produit | plan, source, role, company_size | Quels profils passent à l’essai ? |
Moins d’événements, mais mieux nommés, donnent une analyse plus fiable. PostHog devient alors un outil de décision, pas une décharge de données impossible à interpréter.
Quand utiliser flags, tests et replays ?
Les flags, les tests et les replays deviennent vraiment utiles quand une équipe ne veut pas seulement savoir ce qui se passe, mais comprendre pourquoi cela se passe et décider quoi changer sans prendre un risque inutile.
Les feature flags servent à activer ou désactiver une fonctionnalité sans redéployer tout le produit. Concrètement, vous pouvez ouvrir une nouvelle page d’inscription à 5 % des utilisateurs, uniquement aux clients d’un plan donné, ou à une cohorte précise comme “utilisateurs créés cette semaine”. L’intérêt est simple : limiter l’impact si quelque chose casse, tout en observant le comportement réel.
L’A/B testing basé sur les flags ajoute une logique de mesure. Une partie des utilisateurs voit la variante A, une autre voit la variante B, puis PostHog compare les résultats sur un objectif clair : inscription terminée, clic sur un bouton, activation, achat, rétention. Sans objectif mesurable, un test A/B devient vite une opinion déguisée en expérimentation.
Les session replays montrent ce qu’un utilisateur a réellement vécu dans l’interface. Selon la configuration, ils peuvent aussi inclure les logs console et les requêtes réseau, ce qui aide à repérer une erreur JavaScript, un bouton qui ne répond pas ou une API trop lente. Le replay ne remplace pas les métriques. Il sert à comprendre le “pourquoi” derrière un signal analytics détecté dans un funnel, une courbe de conversion ou un événement anormal.
Les enquêtes in-app complètent ce diagnostic avec du déclaratif. Le NPS, pour Net Promoter Score, mesure la probabilité qu’un utilisateur recommande le produit. Le CSAT, pour Customer Satisfaction Score, mesure la satisfaction juste après une interaction, par exemple après un onboarding ou une réponse du support. Une question personnalisée peut aussi demander : “Qu’est-ce qui vous bloque dans cette étape ?”.
Exemple concret : Un funnel montre une chute de 38 % entre “compte créé” et “email confirmé”. Les replays révèlent que plusieurs utilisateurs cherchent le mail de confirmation puis reviennent sans terminer. Une enquête in-app confirme que le message arrive parfois dans les spams. Un feature flag permet de tester une nouvelle version avec un écran plus clair et un bouton “Renvoyer l’email”. L’A/B test mesure ensuite si cette variante augmente le taux de confirmation.
| Signal détecté | Outil PostHog à utiliser | Action recommandée |
| Chute dans un funnel | Session replays | Observer les sessions concernées pour identifier la friction. |
| Hypothèse d’amélioration produit | Feature flag | Déployer la nouvelle version sur une cohorte limitée. |
| Besoin de preuve chiffrée | A/B test | Comparer deux variantes sur un objectif mesurable. |
| Incompréhension utilisateur | Enquête in-app | Demander directement ce qui bloque ou déçoit. |
| Bug difficile à reproduire | Replay avec logs et réseau | Analyser le contexte technique de la session. |
Alors, faut-il adopter PostHog maintenant ?
PostHog devient intéressant quand vous voulez arrêter de disperser vos données produit entre plusieurs outils. Sa force vient du même socle d’événements utilisé pour les dashboards, les replays, les flags, les tests A/B, les enquêtes et les exports. Mais la valeur ne vient pas du snippet : elle vient d’un plan de tracking clair, d’événements bien nommés et d’une identification utilisateur propre. Si vous maîtrisez cette base, PostHog peut aider votre équipe à décider plus vite, tester avec moins de risque et mieux comprendre les parcours réels. Le bénéfice pour vous : une donnée plus actionnable, donc de meilleures décisions produit.
FAQ
- PostHog sert-il seulement à faire de l’analytics produit ?
Non. PostHog couvre l’analytics produit, le web analytics, les replays de session, les feature flags, les tests A/B, les enquêtes in-app, les pipelines CDP et l’interrogation SQL des événements. Son intérêt principal est de relier ces usages au même modèle de données. - Faut-il garder l’autocapture activée dans PostHog ?
L’autocapture peut aider au démarrage, car elle enregistre automatiquement des clics, formulaires et pages vues. Mais elle peut aussi augmenter fortement le volume d’événements et créer du bruit. Au-delà d’environ 2 000 sessions par mois, mieux vaut souvent suivre des événements personnalisés et maîtrisés. - Quelle convention de nommage utiliser pour les événements ?
Une convention simple et robuste consiste à utiliser le format objet-action, par exemple cta_viewed, workshop_registered ou lead_generated. Le nom décrit l’action, tandis que les propriétés ajoutent le contexte, comme le nom du CTA, la page ou le type d’offre. - Quelle est la différence entre personnes, cohortes et groups ?
Une personne correspond à un profil utilisateur qui agrège ses événements. Une cohorte regroupe plusieurs personnes selon des actions ou caractéristiques communes. Un group représente une entité plus large, par exemple un compte, une organisation ou une entreprise, ce qui est utile en B2B. - PostHog peut-il remplacer plusieurs outils marketing et produit ?
Oui, dans beaucoup de cas, car il réunit plusieurs fonctions souvent séparées : analytics, replays, flags, expérimentation, enquêtes et synchronisation de données. La limite dépend surtout de votre maturité tracking, de vos exigences de gouvernance et de la qualité de votre plan d’événements.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’analytics engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé pour des acteurs comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser votre tracking produit, structurer vos événements ou connecter vos données analytics à votre stack business, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.