Comment auditer le tracking de votre app mobile (et repérer les erreurs invisibles)

Vous avez intégré Firebase, Mixpanel, Amplitude ou Adjust dans votre app mobile. Vos dashboards affichent des données. Des events remontent. Des funnels se dessinent. Tout semble fonctionner. Et pourtant… vous avez cette intuition que quelque chose cloche. Des taux de conversion étranges. Des parcours incomplets. Des décisions produit prises sur des chiffres discutables.

Bienvenue dans le monde du tracking mobile bancal mais silencieux.

La plupart des erreurs de tracking ne provoquent pas d’erreur visible. Elles ne cassent pas l’app, ne déclenchent pas d’alerte. Et c’est justement ce qui les rend dangereuses : elles faussent vos décisions sans que vous vous en rendiez compte. Vous croyez que 40 % des utilisateurs abandonnent un formulaire, alors qu’en réalité, l’événement de soumission n’a jamais été déclenché. Vous pensez que Facebook Ads ne convertit pas, mais le paramètre UTM est mal transmis. Vous construisez des A/B tests sur des events doublonnés.

C’est pour ça qu’un audit de tracking régulier est vital — même si “tout a l’air OK”.

Dans cet article, je vais vous guider à travers une méthode simple, actionnable et non technique (promis) pour auditer le tracking de votre app mobile. Vous n’avez pas besoin d’être développeur ni data analyst pour suivre ces étapes. Que vous soyez PM, marketer, ou tech, vous apprendrez à :

• Repérer les événements mal nommés, doublés ou absents

• Vérifier que le déclenchement des events se fait au bon moment

• Analyser les trous dans vos funnels et parcours utilisateur

• Reconnecter vos dashboards à la réalité du business

• Détecter les erreurs silencieuses qui plombent vos données

🎯 Objectif : que vous soyez capable de vous fier à vos données et de construire vos décisions sur du concret, pas sur des hypothèses floues.

Étape 1 : Faire l’inventaire de vos événements

Avant de corriger quoi que ce soit, il faut faire le point sur l’existant. Trop souvent, les équipes pensent avoir une vue claire de leur tracking, mais lorsqu’on creuse, on découvre des dizaines d’événements jamais utilisés, des doublons, des noms incohérents ou des événements importants totalement absents.

Un bon audit commence donc par un inventaire complet et structuré des événements actuellement envoyés par votre app mobile.

📋 1. Lister les événements envoyés en production

La première étape consiste à extraire la liste exhaustive des événements qui sont réellement trackés aujourd’hui.

Pour cela, utilisez :

• Firebase : via DebugView ou Explorateur d’événements

• Mixpanel / Amplitude : onglet Live View ou Explore

• Adjust / AppsFlyer : onglet des événements in-app définis dans le dashboard

• Et idéalement : les logs réseau (via Charles Proxy, Proxyman ou un backend logger)

Créez un tableau dans Google Sheets avec :

• Nom de l’événement

• Fréquence d’apparition (nombre/jour)

• Dernière apparition

• Plateforme concernée (iOS, Android)

• Est-ce un événement personnalisé ou natif ?

💡 Ce tableau est votre source de vérité. Il va vous permettre de comparer la réalité au plan de tracking prévu.

🔍 2. Comparer avec votre plan de tracking (si vous en avez un)

Si vous avez un plan de taggage existant (bravo !), c’est le moment de le ressortir et de le comparer à votre liste réelle. Sinon, cette étape est l’occasion de le (re)créer.

Comparez :

• Les événements attendus vs existants : est-ce que signup_started est tracké comme prévu ? Avez-vous oublié onboarding_skipped ?

• Les noms d’événements : sont-ils cohérents ? ex : add_to_cart vs AjoutPanier

• La logique de déclenchement : certains événements apparaissent-ils plus ou moins souvent que prévu ? ex : 500 checkout_started pour 10 purchase_completed, c’est louche.

Souvent, cette simple comparaison met en évidence :

• Des événements non déclenchés (oubli de code)

• Des faux positifs (event déclenché même sans action réelle)

• Des événements obsolètes (plus utilisés dans les dashboards)

• Des événements doublons (même action, deux noms différents)

⚠️ 3. Identifier les événements inutiles ou polluants

Il est très courant qu’une app mobile envoie trop d’événements :

• button_clicked, modal_opened, scroll_20_percent… qui n’apportent aucune valeur business

• Événements de test ou legacy laissés par d’anciens devs

• Events jamais utilisés dans les rapports, mais qui surchargent les outils (et parfois les factures)

Ces événements “bruit” ont deux effets pervers :

• Ils noyent les insights utiles

• Ils biaisent les KPIs (ex : sessions trop longues à cause de scrolls trackés en boucle)

🎯 Objectif : repérer et documenter les événements à supprimer ou à regrouper pour clarifier votre tracking.

Étape 2 : Vérifier le déclenchement des événements en conditions réelles

Avoir une belle liste d’événements, c’est bien. Mais sont-ils vraiment déclenchés quand il faut ? Trop souvent, on découvre qu’un signup_completed est envoyé avant que l’inscription ne soit validée, qu’un purchase est déclenché même si le paiement échoue, ou qu’un onboarding_skipped est tout simplement… jamais envoyé.

Cette étape consiste à revivre les parcours utilisateurs réels, à la place de vos utilisateurs, et à observer ce qui se passe vraiment dans vos outils de tracking.

👀 1. Utiliser les outils de visualisation en temps réel

Tous les outils de tracking proposent des interfaces pour voir les événements en direct. Utilisez-les systématiquement pour tester les parcours critiques.

• Firebase → DebugView (via un device connecté avec un build debug)

• Mixpanel → Live View (identifiant un user ou un device en temps réel)

• Amplitude → User Lookup > Stream View

• Adjust / AppsFlyer → Onglet “Test Devices” ou “Raw Data Logs”

💡 Activez un device de test avec un user_id ou un device_id reconnaissable (test_audit_0424) pour bien filtrer les logs.

Faites les actions suivantes en réel sur l’app mobile :

• Créer un compte

• Naviguer sur plusieurs écrans

• Ajouter un produit au panier

• Tenter un achat

• Fermer et rouvrir l’app

À chaque étape, vérifiez que l’événement attendu apparaît bien :

• Dans le bon ordre

• Sans doublons

• Avec les bons paramètres

🧪 2. Utiliser un proxy réseau pour voir les requêtes réelles

Pour aller plus loin, utilisez un proxy réseau comme Charles Proxy, Proxyman ou mitmproxy. Ces outils vous permettent d’inspecter les requêtes HTTP envoyées depuis votre app vers Firebase, Adjust, AppsFlyer, etc.

Vous verrez :

• Les URL des SDK (ex : https://app.adjust.com/...)

• Le payload exact envoyé (événement, paramètres, device ID…)

• Les erreurs silencieuses (403, 500, etc.)

Cela vous aide à identifier :

• Des événements bloqués par une mauvaise configuration

• Des erreurs d’identifiants (event_token manquant, app_token invalide)

• Des événements doublés (même requête envoyée deux fois)

• Des événements envoyés… sans avoir été déclenchés par l’utilisateur

💡 Si vous avez un doute sur le comportement d’un SDK, Charles Proxy est souvent le juge de paix.

🔁 3. Tester les parcours critiques (et pas que les happy paths)

Quand on vérifie un tracking, on teste souvent les parcours “qui marchent” :

• Créer un compte avec succès

• Valider un paiement

• Aller au bout d’un funnel

Mais les erreurs les plus dangereuses sont souvent dans les parcours abandonnés ou échoués :

• Que se passe-t-il si je ferme l’app avant de valider mon panier ?

• Que voit le tracking si je perds ma connexion après un clic sur “Payer” ?

• Est-ce que je tracke un checkout_started sans avoir un checkout_abandoned ou un purchase_completed ensuite ?

🎯 Ces tests permettent d’identifier les “faux positifs” ou les événements manquants qui faussent vos taux de conversion et vos analyses d’abandon.

Étape 3 : Contrôler la structure et les paramètres des événements

Un événement mal structuré, c’est comme une boîte vide : elle a un nom, mais aucune donnée utile à l’intérieur. Trop souvent, on trouve des purchase_completed… sans montant, ou des signup_success… sans méthode d’inscription. Et parfois, c’est l’inverse : des événements surchargés de paramètres inutiles, non standardisés, ou pire : contenant des données personnelles en clair.

Cette étape de l’audit consiste donc à vérifier en profondeur la qualité et la conformité de chaque événement tracké.

🧱 1. Cohérence des noms d’événements

Commencez par l’essentiel : les noms de vos événements sont-ils cohérents et lisibles ?

• Respectent-ils une convention de nommage claire (snake_case, en anglais, verbe + complément) ?

  • ✅ signup_completed

  • ❌ SignUpSuccess, CréationCompte, valid-inscr

• Sont-ils faciles à comprendre sans contexte ?

• Sont-ils dédupliqués (pas d’événements différents pour la même action) ?

💡 Conseil : si deux personnes de votre équipe ne comprennent pas un nom d’event de la même façon, c’est qu’il faut le renommer.

🎯 Objectif : avoir un glossaire d’événements unifié, compréhensible et exploitable dans tous vos outils analytics, même dans 6 mois.

📦 2. Qualité des paramètres envoyés

Les événements sans paramètres sont presque toujours inutiles.

Exemples de bons paramètres :

• signup_method: "email", "google", "facebook"

• af_revenue: 59.99

• utm_source, utm_medium, utm_campaign

• plan_type: "freemium", "pro"

• product_id: "abc_1234"

Vérifiez que chaque événement important contient :

• Au moins 2 ou 3 paramètres exploitables

• Des valeurs standardisées (évitez les valeurs dynamiques du type PromoHiver2025_facebook_79)

• Des types cohérents (ex : revenue en nombre, pas en string)

⚠️ Vérifiez aussi que les paramètres sont présents et remplis ! Il est courant d’avoir des event_name avec un champ revenue vide ou undefined.

🔐 3. Respect des règles RGPD et confidentialité

Le tracking d’app mobile est désormais très encadré :

• RGPD (Europe)

• ATT (iOS 14.5+)

• CCPA (Californie)

Vous devez vous assurer que vos événements :

• Ne contiennent pas de données personnelles non anonymisées

  • ❌ email: "jane.doe@gmail.com"

  • ✅ email_hash: "a63f1b08e3..."

• Sont envoyés uniquement après consentement

  • via CMP mobile, ou logique interne conditionnant l’envoi

• Ne collectent pas de device ID sans base légale (ex : IDFA sans autorisation ATT)

💡 Utilisez des outils de proxy (Charles, Proxyman) pour inspecter les payloads et détecter toute fuite accidentelle de données privées.

🎯 Bonus : vous gagnez en confiance, en conformité… et vous évitez les sanctions.

Étape 4 : Identifier les trous dans les parcours utilisateurs

Un bon tracking, ce n’est pas juste une liste d’événements qui “remontent” : c’est un fil rouge logique qui permet de suivre ce que fait un utilisateur du début à la fin de son expérience. Si une étape manque, est mal nommée ou mal placée, c’est tout le funnel qui devient bancal.

Cette étape de l’audit consiste à retracer les parcours utilisateurs clés et repérer les ruptures de logique qui empêchent de bien comprendre — ou de bien mesurer — ce qu’ils font vraiment.

📉 1. Funnels incomplets ou incohérents

Exemple : vous avez un funnel “Inscription > Onboarding > Achat”, mais vous ne trackez que signup_completed et purchase_completed. Entre les deux : le vide.

Sans l’événement onboarding_completed ou plan_selected, vous ne pouvez pas :

• Savoir où les utilisateurs décrochent

• Segmenter par étape atteinte

• Identifier les parcours “longs” ou “rapides”

💡 Conseil : pour chaque funnel clé, tracez une séquence idéale d’événements, puis vérifiez si elle est reflétée dans vos outils analytics.

🕳 2. Taux de conversion anormalement bas ou hauts

Si votre taux de conversion entre deux étapes est :

• Trop bas (ex : 2 % entre add_to_cart et purchase) → il manque peut-être un événement

• Trop haut (ex : 95 % entre signup_start et signup_completed) → vous déclenchez peut-être trop tôt

🎯 Ces “ratios étranges” sont souvent le signal faible d’un événement mal placé.

Test : prenez 100 utilisateurs qui ont fait event_1 et vérifiez combien ont fait event_2 dans les 10 minutes. S’il y a un écart flagrant avec la réalité métier, c’est qu’un problème de tracking se cache derrière.

🧩 3. Abandons invisibles : on tracke la fin mais pas le début (ou l’inverse)

Un grand classique du tracking raté :

• On tracke payment_success mais pas payment_started

• On tracke form_completed mais pas form_opened

• On tracke onboarding_completed mais pas onboarding_skipped

Résultat :

• Aucun abandon visible

• Impossibilité de construire un funnel ou de détecter les freins

• Des ratios faussement “bons” (puisqu’on ne compte que ceux qui finissent)

💡 Astuce : pour chaque fin d’action trackée (_completed), assurez-vous d’avoir l’événement de début associé (_started, _opened, _initiated).

🎯 Objectif : pour chaque parcours utilisateur clé (signup, achat, onboarding, feature activation), vous devez pouvoir répondre à cette question :

“Si un utilisateur n’est pas allé jusqu’au bout, à quelle étape a-t-il décroché ?”

Si vous n’en êtes pas capable aujourd’hui : il y a un trou à combler.

Étape 5 : Comparer les données analytics avec la réalité

Vous avez vérifié que vos événements sont bien nommés, correctement déclenchés, et que vos funnels sont complets. Parfait. Mais il reste une étape souvent négligée : vérifier que ce que vous voyez dans vos dashboards correspond à la réalité business.

Car parfois, tout semble bien configuré dans l’outil analytics… mais les chiffres sont faux. Et ce n’est visible que lorsqu’on les compare à une source “vérifiable” : votre back-end, Stripe, votre CRM ou vos exports comptables.

🧾 1. Comparer les événements de conversion à vos données métier

Prenez un exemple simple :

• Firebase indique 324 purchase_completed ce mois-ci.

• Stripe indique 403 paiements valides.

➡️ 20 % d’écart. C’est énorme.

Dans ce cas :

• Soit vous n’envoyez pas tous les events de conversion (ex : oubli d’un chemin de paiement alternatif, comme Apple Pay)

• Soit vous les envoyez trop tôt (ex : avant validation serveur)

• Soit vous avez des doublons filtrés par Stripe, mais pas par Firebase

💡 Ce type de comparaison peut se faire aussi pour :

• signup_completed vs nouveaux comptes en base de données

• booking_validated vs réservations dans votre ERP

• form_submitted vs leads reçus par email

📊 2. Vérifier les taux de conversion globaux

Un bon indicateur de tracking fiable, c’est un taux de conversion cohérent avec votre business.

Exemples :

• Vous avez 10 000 visiteurs → 600 achats dans GA4 = 6 % → logique

• Vous avez 150 000 users Firebase → mais seulement 27 achats → 🤯

Dans ce cas, soit :

• Les visiteurs ne sont pas bien trackés (perte d’events)

• Le nombre d’achats est sous-évalué

• Le funnel n’est pas complet (et vous surestimez le haut du funnel)

🎯 L’objectif n’est pas d’avoir des chiffres identiques, mais des ordres de grandeur comparables.

🔍 3. Vérifier la cohérence entre plateformes (GA4, Adjust, CRM…)

Autre cas classique : vous utilisez plusieurs outils en parallèle :

• GA4 pour le trafic

• Adjust pour l’attribution

• Firebase ou Amplitude pour les funnels

• Un CRM comme Hubspot ou Salesforce

Vous devez faire en sorte que :

• Un purchase dans Adjust ≈ un purchase_completed dans Firebase ≈ une commande dans votre back-office

• Le même user_id ou email circule d’un outil à l’autre

• Le même canal d’acquisition est reconnu dans Adjust et dans GA4

💡 Utilisez des tests croisés sur des users test nommés (test_user_202504) pour rejouer un parcours complet et vérifier la remontée dans chaque outil.

En résumé :

Si vos dashboards disent que tout va bien, mais que vos revenus ont chuté… c’est peut-être le tracking qui ment.

Faites le lien entre la data et le réel, et vous saurez si vous pouvez vous fier à vos chiffres.

Conclusion : Un audit de tracking, c’est comme une révision technique

Le tracking, c’est un peu comme une voiture. Tant que ça roule, on ne se pose pas de questions. Mais si les freins ne marchent plus, si les pneus sont sous-gonflés ou si le moteur fume… on le remarque souvent trop tard.

Un audit de tracking, ce n’est pas juste un “check” de plus. C’est une vérification de la base sur laquelle vous prenez vos décisions. Si vos événements sont mal définis, déclenchés au mauvais moment, ou manquent dans vos funnels, alors vos données vous mentent. Et vos décisions produit, marketing ou growth sont biaisées.

L’audit n’a pas besoin d’être long ni compliqué. Avec les 5 étapes présentées dans cet article, vous pouvez :

• Retrouver la maîtrise de votre plan de tracking

• Gagner en confiance dans vos chiffres

• Identifier des quick wins à très fort impact

• Et poser les bases d’une data gouvernée et scalable

✅ Ce que vous pouvez faire dès maintenant

• Créez une checklist d’audit de vos événements clés : nom, moment, paramètres, fréquence

• Rejouez les parcours critiques avec les outils de debug natifs

• Comparez vos chiffres analytics avec la réalité du terrain

• Planifiez un audit complet 2x par an (minimum)

👋 Besoin d’un regard extérieur ?

Je peux vous aider à :

• Faire un audit complet et documenté de votre tracking mobile

• Corriger les erreurs détectées (en collaboration avec vos équipes dev)

• Mettre en place un plan de taggage clair, scalable et compatible RGPD