GA4 ne suffit pas : quand passer au product analytics

GA4 vous dit combien de personnes sont venues sur votre site. Il ne vous dira jamais lesquelles utilisent quelle fonctionnalité de votre produit, ni lesquelles reviennent la semaine suivante. Ce n'est pas un problème de paramétrage : c'est une limite de nature. Voici le cadre de décision pour savoir si vous devez passer au product analytics, quel outil choisir selon votre budget et votre maturité, et surtout à quel moment ce serait une erreur coûteuse.

Product analytics : définition et différence avec GA4

Commençons par la définition, parce que c'est là que la confusion se loge. Le product analytics est une catégorie d'outils qui mesure les actions réalisées par des utilisateurs identifiés à l'intérieur d'un produit : quelle fonctionnalité a été utilisée, par qui, combien de fois, et si cette personne est revenue ensuite. L'unité d'analyse est l'utilisateur, pas la visite.

GA4 fait autre chose, et le fait bien. C'est un outil d'analytics web : il mesure l'audience et l'acquisition. Sa question native, c'est « d'où viennent les gens et que consultent-ils ». Une question parfaitement légitime, mais qui cesse d'être la vôtre dès que vous vendez un logiciel, un espace client, une plateforme ou un service avec une partie connectée.

La différence de nature tient en quatre points :

• Unité d'analyse : la session et la source de trafic pour GA4, l'utilisateur identifié et le compte client pour le product analytics.
• Objet mesuré : des pages vues et des conversions pour GA4, des événements métier (projet créé, rapport exporté, coéquipier invité) pour le product analytics.
• Horizon de temps : GA4 raisonne en campagne et en semaine, le product analytics raisonne en cohorte et en cycle de vie (jour 1, jour 7, jour 30, jour 90).
• Utilisateur interne : GA4 sert le marketing d'acquisition, le product analytics sert le produit, le customer success et la rétention.

Autrement dit : GA4 est un excellent outil pour savoir si vos canaux d'acquisition fonctionnent. Il est structurellement incapable de vous dire si votre produit, lui, fonctionne.

Pourquoi GA4 ne répondra jamais à « qui utilise quoi et revient »

La tentation est légitime : vous avez déjà GA4, il est gratuit, il accepte des événements personnalisés. Pourquoi ne pas tout y mettre ? Parce que quatre plafonds vous rattraperont, quel que soit le soin apporté au paramétrage.

• Le modèle est centré session. Tout le raisonnement de l'outil part de la visite. Un utilisateur qui ouvre votre produit trois fois par semaine pendant six mois est un excellent client, mais dans une logique de sessions il ressemble surtout à du trafic récurrent, sans notion de valeur ni d'ancienneté de compte.
• L'identité utilisateur est faible. Le User-ID existe, mais il reste un ajout sur une architecture pensée pour l'audience anonyme. Rattacher proprement un utilisateur à une organisation cliente, suivre son parcours sur plusieurs mois et croiser cela avec son plan tarifaire relève du bricolage.
• La rétention par fonctionnalité n'existe pas. Vous ne pourrez pas construire en trois clics une analyse de cohortes du type « parmi les comptes qui ont utilisé la fonctionnalité X au moins deux fois le premier mois, combien sont encore actifs à 90 jours ». C'est pourtant la question qui pilote une roadmap.
• L'exploration ad hoc est bridée. Échantillonnage sur les gros volumes, cardinalité limitée sur les paramètres, latence de traitement, seuils d'anonymisation qui masquent les faibles effectifs. Sur une audience B2B de quelques milliers d'utilisateurs, ces seuils suffisent à vider un rapport de sa substance.

Le symptôme classique : vous ouvrez GA4 pour trancher une question produit, vous en ressortez avec un chiffre que personne autour de la table ne sait interpréter. C'est exactement le mécanisme décrit dans pourquoi votre dashboard ne sert à rien : de la donnée disponible, aucune décision possible.

Les 3 signaux que vous avez atteint la limite de GA4

Inutile de théoriser. Trois signaux concrets indiquent que votre instrumentation actuelle est arrivée au bout de ce qu'elle sait faire. Si vous en cochez deux sur trois, la question n'est plus « faut-il changer » mais « quand ».

1. Vous ne savez pas répondre à la question de rétention par fonctionnalité. Testez maintenant : quelle proportion des comptes ayant utilisé votre fonctionnalité phare le premier mois sont encore actifs 60 jours après ? Si la réponse demande une réunion, un export et un développeur, vous avez votre signal. Cette question est la brique de base d'un modèle de croissance basée produit.
2. Chaque question produit passe par un développeur et coûte plusieurs jours. Les équipes qui n'ont pas de product analytics finissent toujours par requêter la base de production à la main. Ça marche une fois, ça ne tient pas à l'échelle : le coût par question devient si élevé que les équipes arrêtent de poser des questions. Le vrai dégât n'est pas le délai, c'est la curiosité qui s'éteint.
3. Vos arbitrages de roadmap se prennent sur l'avis du dernier client qui a parlé fort. Le support remonte une demande, un commercial la relaie, personne ne peut dire si elle concerne une poignée de comptes ou la moitié de votre base active. Vous n'avez pas un problème de priorisation, vous avez un problème de mesure.

Un quatrième signal, plus insidieux : vous êtes incapable de nommer votre North Star Metric en une phrase mesurable. Là, changer d'outil ne réglera rien tant que la question n'est pas posée.

Le piège : installer un product analytics trop tôt

Voici l'erreur que nous voyons le plus souvent, et elle est symétrique à la précédente. Une équipe branche PostHog, Mixpanel ou Amplitude avant d'avoir assez d'usage pour en tirer le moindre signal. L'outil est installé, les événements arrivent, les graphiques s'affichent, et plus personne n'ouvre le tableau de bord au bout de quelques semaines.

La raison est mathématique. Un entonnoir en cinq étapes divise votre population à chaque marche. À titre d'ordre de grandeur, en dessous de quelques centaines d'utilisateurs actifs par semaine, les dernières étapes reposent sur une poignée de personnes : les écarts que vous observerez d'une semaine sur l'autre seront du bruit, pas de l'information. C'est le même mécanisme qui rend la plupart des tests non concluants, détaillé dans pourquoi la plupart des A/B tests ne prouvent rien.

Le coût de ce piège n'est pas seulement l'abonnement. C'est surtout : plusieurs semaines de temps de développement pour instrumenter, une dette technique d'événements mal nommés qu'il faudra reprendre, et un outil de plus dans une stack déjà chargée. Le sujet est traité de front dans arrêter de collectionner les outils.

Ce qu'il faut faire à la place, tant que le volume n'y est pas :

• Dix entretiens utilisateurs bien menés. Ils vous en apprendront plus qu'un entonnoir bâti sur une poignée d'utilisateurs.
• Un tableur mensuel avec cinq lignes : comptes actifs, comptes ayant fait l'action clé, comptes revenus, comptes perdus, revenu. Extraits de votre base, à la main s'il le faut.
• Un plan de tracking écrit, même sans outil derrière. Le jour où vous branchez la solution, elle devient utile en quelques semaines au lieu de plusieurs mois.

La règle de décision est simple : un outil de product analytics ne crée pas de signal, il le révèle. S'il n'y a pas d'usage, il n'y a rien à révéler.

Quel outil choisir : PostHog, Mixpanel ou Amplitude

Les grilles tarifaires de ces éditeurs bougent régulièrement, vérifiez toujours les conditions à jour avant d'arbitrer. En revanche, leur positionnement, lui, est stable. Voici la grille de choix que nous utilisons avec nos clients PME et scale-ups.

• Aucun outil dédié si vous avez moins de quelques centaines d'utilisateurs actifs par semaine, ou si votre produit est encore en recherche de product market fit. Tableur, requêtes SQL ponctuelles, entretiens. Coût : zéro euro, quelques heures par mois.
• PostHog si votre équipe est technique, votre budget serré et que vous voulez tout au même endroit. Modèle open source avec offre gratuite au volume, et la même plateforme couvre les événements, l'enregistrement de sessions, les feature flags et les tests. C'est notre choix par défaut pour une PME B2B dont l'équipe produit et l'équipe technique se confondent.
• Mixpanel si les utilisateurs principaux sont des profils produit ou marketing peu à l'aise avec la donnée brute. L'interface d'exploration (entonnoirs, cohortes, rapports de rétention) est faite pour être utilisée sans développeur au quotidien. Bon compromis entre prise en main et profondeur d'analyse.
• Amplitude si vous avez une équipe data constituée, plusieurs équipes produit à servir et un besoin de gouvernance (taxonomie d'événements, droits, gestion de la qualité de donnée). Positionnement entreprise, budget en conséquence.

Quatre critères à trancher avant de signer, dans cet ordre :

1. Qui va ouvrir l'outil chaque semaine ? Si vous ne pouvez pas nommer la personne, ne l'achetez pas.
2. Le modèle de facturation. La plupart facturent au volume d'événements ou d'utilisateurs suivis. Votre facture suit donc votre croissance : simulez le coût à douze mois, pas le coût du premier mois.
3. L'hébergement et le RGPD. Localisation des données, sous-traitance, durée de conservation. Un sujet devenu structurant, que nous détaillons dans migrer sa stack en Europe.
4. La capacité à envoyer les événements depuis le back. Les faits business (paiement, expiration d'essai, invitation acceptée) doivent partir du serveur, pas du navigateur. Sinon vos chiffres seront faux dès le premier bloqueur de publicités.

Point important : vous ne remplacez pas GA4, vous l'accompagnez. GA4 garde la mesure de l'acquisition et du site public. Le product analytics prend la partie connectée. Les deux cohabitent très bien.

Avant l'outil : le plan de tracking et l'aha moment

C'est l'étape que la plupart des équipes sautent, et c'est celle qui détermine si l'outil servira. Un product analytics installé sans plan de tracking produit des centaines d'événements mal nommés, non documentés, que plus personne n'ose interpréter au bout de quelques mois.

Le plan de tracking tient en un document simple : la liste des événements que vous mesurez, leur nom exact, leurs propriétés, qui les émet (front ou back), et surtout la question à laquelle chacun sert à répondre. Si un événement ne répond à aucune question, il ne rentre pas. La méthode complète est dans définir son plan de tracking.

Trois règles qui économisent des mois :

• Quinze à vingt-cinq événements maximum au départ. Une convention de nommage unique (objet puis action au passé : projet_cree, rapport_exporte). Aucun événement générique du type clic_bouton.
• Un identifiant utilisateur stable et un identifiant de compte. En B2B, la vraie unité d'analyse est souvent l'organisation cliente, pas la personne.
• Un événement dédié à votre aha moment. C'est le point où l'utilisateur perçoit la valeur, et c'est la métrique la plus prédictive de la rétention. Si vous ne l'avez pas encore identifié, commencez par là : activation et aha moment.

Une fois ces événements en place, votre dashboard growth cesse d'être une collection de courbes et devient un instrument de décision. La différence n'est pas dans l'outil : elle est dans le travail fait en amont.

Votre plan sur 30 jours pour passer au product analytics

Si les signaux sont là et que le volume d'usage est suffisant, voici la séquence. Elle tient en quatre semaines et ne demande pas d'équipe data dédiée.

1. Semaine 1 : les questions. Écrivez les cinq questions auxquelles vous devez répondre chaque mois. Pas dix, cinq. Formulez-les avec un sujet, un verbe et un horizon : « quelle part des comptes créés en janvier utilise encore le produit à 90 jours ». Identifiez votre aha moment et votre définition d'utilisateur actif.
2. Semaine 2 : le plan de tracking. Traduisez ces cinq questions en événements et propriétés. Arbitrez ce qui part du front et ce qui part du back. Faites relire le document par un développeur avant toute ligne de code.
3. Semaine 3 : l'implémentation et la recette. Instrumentez, puis vérifiez. Une recette sérieuse consiste à refaire manuellement le parcours et à comparer, événement par événement, ce qui arrive dans l'outil. C'est fastidieux et c'est non négociable : une donnée fausse coûte plus cher qu'une donnée absente.
4. Semaine 4 : les trois premières réponses. Sortez trois chiffres et un seul arbitrage de roadmap qui en découle. Si aucune décision ne change, votre plan de tracking mesurait les mauvaises choses. Reprenez à la semaine 1.

Ce séquencement paraît lent quand on a envie d'un tableau de bord tout de suite. Il est en réalité le chemin le plus court, parce qu'il évite la reprise complète de l'instrumentation quelques mois plus tard. Depuis 2012, nous avons accompagné 285 entreprises et formé 2 750 professionnels : les équipes qui tirent quelque chose de leur product analytics sont systématiquement celles qui ont écrit leurs questions avant d'ouvrir le premier compte.

GA4 n'est pas le problème. Le problème, c'est de lui demander ce qu'il n'a jamais été conçu pour faire, puis de conclure que la donnée ne sert à rien.

La règle à retenir : un outil de product analytics ne crée pas de signal, il le révèle. Sans usage réel et sans plan de tracking écrit, vous n'achetez pas de la clarté, vous achetez un tableau de bord vide et une facture qui grandit avec vos volumes. L'ordre est toujours le même : usage, questions, plan de tracking, puis outil. La croissance ne se hacke pas. Elle se construit.