Un product data analyst passe ses journées dans les données d'usage. Il écrit le plan de taggage d'une nouvelle fonctionnalité, construit les funnels et les courbes de rétention dans Amplitude ou Mixpanel, prépare et lit les tests A/B, et descend en SQL dans l'entrepôt quand l'outil ne suffit plus. Les offres des scale-ups SaaS et des éditeurs d'applications citent aussi Segment, dbt, Snowflake ou BigQuery et un outil comme Metabase.
Pour un recruteur, la difficulté tient au vocabulaire partagé. Tout le monde parle de funnel et de rétention, peu de candidats précisent ce qu'ils comptent comme un retour ou vérifient le tracking avant d'accuser l'interface. Sur l'expérimentation, la ligne de partage passe par le calcul de la durée d'un test et la réaction face à une répartition déséquilibrée entre variantes. Un PM ou un data analyst de votre équipe peut vous aider à juger les réponses, mais un premier tri reste possible sans eux.
Vous n'avez pas besoin d'être statisticien pour mener cet entretien. Demandez plutôt au candidat de raconter un test A/B qu'il a arrêté ou invalidé, et pourquoi : la réponse montre s'il lit les résultats ou s'il les subit.
La boîte à outils d'un product data analyst
Amplitude et Mixpanel
Les deux outils d'analyse produit les plus cités dans les offres. Ils construisent en quelques clics funnels, courbes de rétention et parcours utilisateurs à partir des événements envoyés par l'application. PostHog, open source, gagne du terrain dans les start-up. Un profil qui maîtrise l'un passe à l'autre en quelques jours.
Segment, RudderStack ou Snowplow
Les outils de collecte qui reçoivent les événements de l'application et les distribuent vers l'outil d'analyse, l'entrepôt et d'autres services. Snowplow est apprécié pour la validation des schémas. Le product analyst n'administre pas forcément ces outils, mais il doit savoir d'où viennent ses données.
Plan de taggage
Le document qui liste chaque événement suivi, ses propriétés et son déclenchement. Il se tient dans un tableur ou dans un outil dédié comme Avo ou Amplitude Data. C'est la base de toute analyse fiable, et l'endroit où un bon product analyst se reconnaît vite.
GA4 et son export BigQuery
Google Analytics 4 sert surtout pour le site et l'acquisition. Son export vers BigQuery donne accès aux événements bruts, à interroger en SQL avec des champs imbriqués. Demandez si la personne a déjà travaillé sur cet export plutôt que sur l'interface seule.
Entrepôt de données et dbt
Snowflake, BigQuery ou Databricks stockent l'historique complet des événements, croisé avec les données de facturation et du CRM. dbt sert à écrire les tables d'indicateurs en SQL testé. Le product analyst y descend dès qu'une question dépasse ce que l'outil d'analyse sait faire.
Plateformes d'expérimentation
Amplitude Experiment, Optimizely, AB Tasty, Statsig ou un outil interne répartissent les utilisateurs entre variantes et calculent les résultats. L'outil fait les calculs, mais c'est l'analyste qui choisit l'indicateur, fixe la durée et repère un test cassé. C'est là que les candidats se distinguent le plus en entretien.
SQL, Python et statistiques
SQL au quotidien, Python avec pandas et scipy ou statsmodels pour les analyses qui sortent du cadre : tests statistiques, calculs de puissance, régressions simples. Le niveau de statistiques attendu reste appliqué, centré sur les tests A/B et la lecture d'un intervalle de confiance.
Metabase, Looker ou Tableau
Les outils de tableaux de bord partagés avec les équipes produit et la direction. Metabase revient souvent dans les scale-ups françaises, Looker et Tableau dans les structures plus grandes. Le choix compte moins que la clarté des définitions affichées.
Le poste se rencontre surtout dans les scale-ups SaaS, les applications grand public, les places de marché et les équipes digitales des grands groupes. Rattaché à l'équipe data ou directement à une squad produit, le product data analyst travaille avec un ou plusieurs PM. Dans une jeune entreprise, il installe souvent lui-même le tracking et les premiers tableaux de bord. Dans une structure plus mûre, il hérite d'un plan de taggage existant et passe davantage de temps sur l'expérimentation. Le titre varie selon les offres (product analyst, data analyst produit, growth analyst). Ce qui le distingue du data analyst généraliste, c'est la donnée événementielle et la pratique des tests A/B.
Les savoir-faire techniques à évaluer chez un product analyst
- Plan de taggage et qualité du tracking
- Funnels et analyse de conversion
- Rétention, cohortes et métriques produit
- Conception de tests A/B
- Lecture critique des résultats d'expérimentation
- SQL sur données événementielles
Lire un funnel et un test A/B devant le recruteur
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
Une nouvelle fonctionnalité sort dans deux semaines. Comment rédigez-vous son plan de taggage ?
Une bonne réponseIl part des questions que le PM veut trancher après la sortie, puis liste les événements strictement nécessaires pour y répondre. Chaque événement suit la convention de nommage existante (objet puis action, au passé, même casse partout), avec ses propriétés, leurs valeurs possibles et le moment exact où il se déclenche. Il distingue propriétés d'événement et propriétés d'utilisateur, précise ce qui part du client et ce qui part du serveur, documente le tout dans l'outil de l'équipe (Avo, Amplitude Data, un tableur versionné) et prévoit une recette sur l'environnement de test avant la mise en production.
Signal d'alerte« On tracke tous les clics, on verra après. » Ou des noms d'événements inventés pour l'occasion, différents de ceux déjà en place.
Question 2 · confirmé
Dans le funnel d'inscription, l'étape 3 perd 60 % des utilisateurs. Que vérifiez-vous avant de conclure à un problème d'ergonomie ?
Une bonne réponseD'abord le tracking : l'événement de l'étape 3 se déclenche-t-il sur toutes les plateformes et toutes les versions, depuis quand, avec quel volume côté serveur. Ensuite la construction du funnel : ordre strict ou non, fenêtre de conversion, utilisateurs comptés une fois ou à chaque tentative. Puis la décomposition par plateforme, version, navigateur, canal d'acquisition et nouveaux ou anciens utilisateurs, et le temps passé entre les étapes. Les enregistrements de sessions ou un test utilisateur viennent confirmer, une fois les chiffres validés.
Signal d'alerteRecommander de refaire l'écran dès la lecture du graphique, sans vérifier si l'événement est bien envoyé partout.
Question 3 · junior à confirmé
Le PM vous demande « la rétention de l'application ». Quelles questions posez-vous avant de sortir un chiffre ?
Une bonne réponseQuelle action compte comme un retour : une ouverture de l'application ou l'usage de la fonction qui apporte de la valeur. Quelle cohorte : date de première utilisation ou d'inscription. Quelle forme : rétention au jour N exact, ou rétention « N jours ou plus », plus flatteuse. Quel découpage : jour, semaine ou mois, selon la fréquence d'usage normale du produit. Il regarde ensuite si la courbe se stabilise sur un plateau et compare les cohortes entre elles.
Signal d'alerteUn seul pourcentage donné sans définition, ou la rétention calculée sur l'ouverture de l'application pour un produit qu'on utilise une fois par mois.
Question 4 · confirmé
Un test A/B devait répartir les utilisateurs 50/50 et vous obtenez 52/48 sur 200 000 personnes. Que faites-vous ?
Une bonne réponseIl reconnaît un déséquilibre d'échantillon (sample ratio mismatch) et le vérifie par un test du khi-deux : sur un tel volume, l'écart n'est pas dû au hasard. Il ne lit pas les résultats, parce que les deux groupes ne sont plus comparables. Il cherche la cause : affectation, redirection plus lente dans une variante, robots, plantage d'une version, événement d'exposition qui ne part pas pareil dans les deux groupes, filtre appliqué après coup. Puis il corrige et relance le test.
Signal d'alerte« 52/48, c'est presque 50/50 », et lecture des résultats comme si de rien n'était.
Question 5 · confirmé à senior
Avant de lancer un test A/B, comment décidez-vous de sa durée ?
Une bonne réponsePar un calcul de taille d'échantillon : taux de conversion actuel, plus petit effet qui intéresse le métier (MDE), seuil de risque et puissance statistique. La taille nécessaire, rapportée au trafic exposé, donne la durée, arrondie à des semaines entières pour couvrir les jours de la semaine. Il fixe le critère de décision avant le lancement et ne s'arrête pas au premier résultat significatif, sauf méthode séquentielle prévue pour. Un senior mentionne les techniques de réduction de variance comme CUPED pour raccourcir le test.
Signal d'alerte« On le laisse tourner jusqu'à ce que ce soit significatif », ou une durée fixe d'une semaine quel que soit le trafic.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Embaucher un product data analyst : les interrogations courantes
Amplitude ou Mixpanel sur le CV : faut-il exiger le même outil que le vôtre ?
Non. Les deux outils, comme PostHog, reposent sur les mêmes notions : événements, propriétés, identification des utilisateurs, funnels et cohortes. Un profil à l'aise sur l'un devient opérationnel sur l'autre en quelques jours. Vérifiez plutôt qu'il a déjà écrit ou corrigé un plan de taggage et qu'il sait descendre en SQL dans l'entrepôt quand l'outil ne suffit plus. L'outil d'expérimentation suit la même logique.
Product analyst et data analyst généraliste : qu'est-ce qui change ?
Le product analyst travaille sur des données d'usage, événement par événement, et répond aux questions d'une équipe produit : quelle étape fait décrocher, quelle fonctionnalité retient, quel test gagne. Le data analyst généraliste couvre plus souvent les ventes, la finance ou les opérations, sur des données de gestion. Le socle SQL reste commun. Le product analyst ajoute le tracking, la rétention par cohorte et l'expérimentation.
Quel niveau de statistiques attendre d'un product data analyst ?
Un niveau appliqué. Il doit savoir calculer une taille d'échantillon, lire une p-value et un intervalle de confiance, détecter un déséquilibre entre variantes et expliquer pourquoi on ne s'arrête pas au premier résultat significatif. Les modèles avancés relèvent davantage du data scientist spécialisé en expérimentation. Pour un poste senior qui pilote le programme de tests, ajoutez la réduction de variance et les méthodes séquentielles.
Comment construire le test technique d'un product data analyst ?
Avec une table d'événements fictive d'une application : inscriptions, utilisations d'une fonctionnalité, abonnements et affectation à un test A/B. Demandez un funnel, une rétention par cohorte hebdomadaire, puis la lecture du test, en glissant un déséquilibre de répartition dans les données. Une heure en direct, commentée à voix haute, suffit. Le cas d'onboarding du PDF reprend cette logique sur un exemple complet.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
