Nettoyer ou migrer son tracking mobile : la méthode pour reprendre le contrôle sur vos événements

Tu as mis en place Firebase, Mixpanel, ou Amplitude il y a quelques mois — voire quelques années. Tu pensais avoir un tracking solide. Mais aujourd’hui, tu ouvres ton dashboard, et c’est le chaos.

Des événements en double, des noms incohérents (AddToCart, add_to_cart, ajout_panier…), des paramètres manquants, des funnels incomplets, et surtout… des tonnes d’événements que personne n’utilise. Résultat : les analytics sont flous, les décisions basées sur des données fragiles, et chaque nouvelle feature complexifie un peu plus la situation.

Tu n’es pas seul : 90 % des apps mobiles finissent avec un plan de tracking désorganisé au bout de 6 mois. Voir notre guide sur tracking mobile.

Pourquoi ? Parce que :

• le plan de taggage initial est rarement documenté,

• plusieurs personnes modifient les events sans gouvernance,

• les outils changent (migration Firebase → Amplitude),

• et surtout, personne ne “possède” vraiment le tracking.

Bonne nouvelle : il est possible de reprendre le contrôle, sans tout casser ni repartir de zéro.
Dans cet article, je te guide à travers une méthode claire et progressive pour :

• Auditer ton tracking existant

• Supprimer les événements inutiles ou redondants

• Réorganiser ton plan de taggage

• Et migrer proprement vers un nouvel outil si besoin

🎯 Objectif : repartir sur une base saine, cohérente, évolutive — et enfin retrouver confiance dans tes dashboards.

Étape 1 : Faire un audit complet de votre tracking existant

Avant de migrer ou de nettoyer, il faut savoir exactement ce que vous trackez aujourd’hui, comment, où, et pourquoi. L’objectif de cette étape est de transformer un tracking flou et dispersé en une cartographie claire des événements actifs dans votre app mobile. Voir notre guide sur Tracking server-side pour app mobile.

Un bon audit permet de :

• Révéler les incohérences (noms d’event, déclencheurs, paramètres)

• Identifier les doublons, les événements obsolètes ou inutiles

• Reconnecter les événements à des parcours utilisateurs réels

• Préparer le terrain pour un plan de taggage propre et actionnable

🔍 1. Extraire tous les événements trackés dans vos outils

La première étape est purement technique : il s’agit de lister tous les événements actuellement collectés dans vos outils analytics ou d’attribution.

Selon vos outils, utilisez :

• Firebase Analytics : Explorer > Explorateur d’événements

• Mixpanel : Analyse > Événements → export complet

• Amplitude : Govern > Events → export CSV

• Adjust / AppsFlyer : liste des événements post-install visibles dans l’interface

• Proxyman / Charles Proxy : pour observer les requêtes actives sur l’app

Créez un tableau de travail (Google Sheets ou Notion) avec :

💡 Bonus : si vous avez un taggage côté backend, listez aussi les événements envoyés via vos APIs ou via GTM Server-Side.

🎯 Objectif de cette étape : poser un état des lieux factuel, avant d’interpréter quoi que ce soit.

🧩 2. Identifier les doublons, incohérences et événements orphelins

Une fois tous les événements listés, analysez-les à la loupe pour détecter :

Les doublons :

• Même action, noms différents : add_to_cart, AddToCart, ajoutPanier

• Mêmes événements envoyés deux fois par erreur (via SDK + backend)

Les événements mal nommés :

• Pas de logique de nomenclature

• Trop techniques ou trop flous (event1, click_ok, custom_42)

• Non standardisés entre plateformes (iOS vs Android)

Les événements “orphelins” :

• Jamais utilisés dans un dashboard

• Non liés à une décision produit ou marketing

• Résidus d’anciennes versions de l’app

💡 Conseil : triez tous vos events en 3 catégories :

1. 🟢 À conserver (utiles, bien nommés, cohérents)

2. 🟡 À revoir (utiles mais mal définis, à renommer ou compléter)

3. 🔴 À supprimer (inutiles, obsolètes, jamais utilisés)

🔁 3. Reconnecter les événements aux parcours utilisateurs

Un bon tracking doit raconter une histoire utilisateur. Votre job ici : recréer cette histoire à partir des événements trackés.

Exemples :

• Funnel Onboarding → signup_started > plan_selected > onboarding_completed

• Funnel Achat → product_viewed > add_to_cart > checkout_started > purchase_completed

🧠 Demandez-vous :

• Est-ce que toutes les étapes sont bien couvertes ?

• Est-ce que le nom et les paramètres des events permettent d’expliquer ce qui s’est passé ?

• Est-ce que certains parcours sont surtrackés… ou sous-trackés ?

🎯 Résultat attendu de l’audit : Un document lisible qui vous dit ce qui fonctionne, ce qui dysfonctionne, et ce qu’il faut supprimer ou restructurer.

Étape 2 : Nettoyer les événements inutiles ou redondants

Une fois l’audit réalisé, vous avez sans doute identifié des événements qui ne servent à rien, ou qui polluent vos dashboards avec du bruit. C’est maintenant qu’il faut faire le tri. Un bon plan de taggage n’est pas celui qui capture tout, mais celui qui capture uniquement ce qui sert une analyse ou une action.

Cette étape consiste à désactiver, regrouper ou supprimer les événements non pertinents… sans casser vos dashboards ou vos exports de données.

🧹 1. Définir des critères objectifs pour supprimer un événement

Supprimer un event n’est jamais une décision légère. Voici des critères concrets pour vous aider à trancher :

• Volume quasi nul depuis plus de 3 mois

• Jamais utilisé dans un dashboard ou une analyse

• Événement obsolète (lié à une fonctionnalité supprimée ou désactivée)

• Événement redondant avec un autre (ex : btn_add_to_cart + add_to_cart)

• Événement impossible à interpréter (pas de paramètres utiles, nom incompréhensible)

• Événement jamais documenté (pas dans le plan de taggage, personne ne sait à quoi il correspond)

💡 Conseil : créez une colonne “Suppression validée ? (O/N)” dans votre tableau d’audit, pour acter la décision.

🎯 Résultat attendu : une shortlist claire des événements à supprimer ou à merger.

🧰 2. Supprimer ou désactiver un événement proprement

Dans Firebase :

• Il n’est pas possible de supprimer un événement rétroactivement

• Mais vous pouvez le désactiver côté code, et masquer son affichage dans les rapports personnalisés

• Ajoutez un filtre d’exclusion dans vos dashboards pour ne plus l’afficher

Dans Mixpanel ou Amplitude :

• Utilisez la fonction “Hide Event” pour le masquer dans les analyses (mais les données restent)

• Supprimez-le du code source pour arrêter sa collecte future

• Si vous utilisez un proxy (comme GTM server-side), vous pouvez intercepter l’événement et le bloquer

En backend :

• Supprimez la logique d’envoi (ex : endpoint ou appel API)

• Nettoyez les scripts ou règles GTM associés

💡 Pro tip : pour ne rien casser, ne supprimez jamais un event d’un SDK sans avoir vérifié s’il est utilisé dans un dashboard Looker Studio, Data Studio ou BigQuery. Sinon, vous cassez des reporting sans vous en rendre compte.

🔁 3. Regrouper ou renommer les événements équivalents

Autre cas fréquent : plusieurs événements qui mesurent la même chose, mais avec des noms ou des structures différentes. Exemple :

• btn_add_to_cart, add_cart_click, add_to_cart_button → tous pour un clic sur “Ajouter au panier”.

🎯 Objectif : regrouper ces événements en un seul événement unifié, bien nommé, bien paramétré, puis migrer les anciennes références vers le nouveau.

Comment faire :

• Choisissez un nouveau nom propre (ex : add_to_cart)

• Déployez-le côté code ou GTM avec les bons paramètres

• Créez un mapping temporaire dans vos dashboards pour fusionner les données si besoin

• Planifiez la suppression des anciens events dans 30-60 jours une fois la migration stabilisée

💡 Astuce : dans Mixpanel ou Amplitude, vous pouvez créer des “Custom Events” qui agrègent plusieurs anciens noms en un seul — très utile pendant une phase de transition.

Étape 3 : Migrer vers un outil plus adapté

Tu utilises Firebase mais tu veux plus de flexibilité. Tu es limité par les quotas d’Amplitude gratuit. Tu veux passer sur un outil mieux adapté à ton stack data, plus moderne ou plus compatible avec ton entrepôt de données. Bref, tu veux migrer.

Mais attention : migrer son plan de tracking, ce n’est pas juste répliquer les mêmes événements dans un autre outil. C’est une opportunité rare pour :

• Nettoyer ce qui ne sert plus

• Redéfinir les événements clés

• Adopter une nomenclature solide

• Et poser des fondations durables pour les 2 ou 3 années à venir

Voici comment réussir ta migration analytics sans tout casser.

🧭 1. Savoir quand migrer (et pourquoi)

Changer d’outil analytics prend du temps. Il faut donc être sûr que c’est le bon moment. Voici quelques signaux que tu as atteint la limite de ton outil actuel :

• Tu ne peux pas construire les analyses dont tu as besoin (ex : funnels avancés, cohortes, split AB)

• Ton outil ne permet pas une gouvernance propre (noms d’événements en vrac, pas de versioning, pas de droits granulaire)

• Tu veux un outil orienté produit, pas marketing (ex : tu veux suivre les activations, pas juste les visites)

• Tu veux brancher tes événements dans ton entrepôt de données (BigQuery, Snowflake)

• Tu as une app mobile + web et tu veux unifier le tracking cross-device Voir notre guide sur Utiliser Google Analytics for Firebase.

💡 Exemple : tu passes de Firebase à Amplitude pour avoir une meilleure visibilité sur la rétention, les funnels et les cohortes par segment.

🎯 Conseil : ne migre pas pour migrer. Migrer est pertinent si tu gagnes en puissance d’analyse ET en gouvernance.

🧱 2. Préparer une nouvelle structure d’événements (et ne pas migrer les erreurs)

Erreur classique : vouloir tout “copier-coller” depuis l’ancien outil vers le nouveau. Mauvais réflexe. Tu vas juste répéter les erreurs du passé.

Voici comment faire proprement :

• Repars d’un plan de taggage neuf, avec :

  • Les vrais événements utilisés pour la prise de décision

  • Une nomenclature cohérente (snake_case, verbe + complément)

  • Des paramètres normalisés (plan_type, utm_source, revenue, etc.)

• Utilise l’audit réalisé à l’étape 1 pour faire le tri

• Crée un tableau de correspondance (ancien nom → nouveau nom) pour migrer tes dashboards

💡 Outils utiles :

• Figma ou Miro pour cartographier visuellement le plan

• Google Sheets ou Notion pour versionner

• event_migrated_from comme paramètre temporaire pour faire le lien

🎯 Résultat : un plan de taggage aligné avec ta stratégie produit, simple à maintenir, et enfin exploitable sans stress.

🔁 3. Mettre en place une phase de double tracking (si nécessaire)

Pendant la migration, il est courant de tracker en parallèle dans les deux outils (ancien et nouveau) pour valider la cohérence.

Comment faire :

• Dans GTM mobile ou dans ton code, envoie chaque événement vers les 2 SDKs avec la même structure

• Sur une période de 2 à 4 semaines, compare les volumes et les paramètres

• Vérifie que les dashboards du nouvel outil remontent les mêmes insights

• Une fois validé → supprime le SDK obsolète

💡 Attention aux impacts sur le poids de l’app et la performance. Ne garde pas les deux SDKs plus de 1 mois sans raison.

Étape 4 : Maintenir un plan de taggage propre dans le temps

Tu as nettoyé ton tracking, fait un audit, peut-être même migré vers un outil plus adapté. Bravo ! Mais sans entretien régulier, ton plan de taggage risque de redevenir un champ de bataille en moins de 6 mois. La clé, c’est la gouvernance continue.

Voici comment structurer une organisation et une culture produit/data qui permettent à ton tracking de rester fiable, clair, et exploitable sur le long terme.

👤 1. Désigner un ou plusieurs “event owners”

Chaque événement devrait avoir un responsable clair. Ce rôle est souvent oublié : on crée un event, et… plus personne ne sait qui l’a défini, à quoi il sert, ni s’il est encore utile. Résultat : des événements fantômes s’accumulent.

Comment faire :

• Assigne un “event owner” à chaque événement dans ton plan de taggage

• Ce peut être un(e) PM, dev ou analyst qui connaît bien la feature liée

• L’owner est responsable de :

  • La documentation de l’événement

  • Son maintien en cohérence

  • Son retrait quand la feature disparaît

💡 Bonus : ajoute une colonne “Owner” dans ton tableau Notion ou Google Sheets de tracking.

🎯 Objectif : que chaque événement ait une personne clairement identifiée en cas de question ou d'évolution produit.

🔁 2. Mettre en place une revue tracking à chaque sprint

Ton produit évolue en continu : ton tracking doit suivre. Mais pas en roue libre. Pour ça, adopte un rituel d’équipe simple :

• À chaque sprint ou nouvelle feature :

  • On pose la question : quels événements devons-nous créer/modifier/supprimer ?

  • On met à jour le plan de taggage (même avant de coder)

  • On valide dans le ticket de dev que le tracking est intégré

💡 Ajoute un champ obligatoire “Impact tracking ?” dans tes templates de specs produit.

🎯 Avantage : ça évite les oublis, et ça force à anticiper le tracking dès la conception produit.

🗃️ 3. Versionner et documenter le plan de taggage

Un bon plan de taggage, c’est un document :

• Centralisé (Notion, Google Sheets, Airtable…)

• Lisible par tous (tech, produit, marketing)

• Versionné (historique des changements)

• Lié aux fonctionnalités (une feature = une ou plusieurs lignes d’event)

Outils recommandés :

• Notion → parfait pour créer un wiki produit + data

• Google Sheets + Git → si vous voulez suivre les évolutions dans le temps

• Amplitude Govern / Mixpanel Lexicon → pour documenter dans l’outil lui-même

💡 Astuce : ajoute une colonne “Date de dernière vérification” pour chaque événement → et impose une relecture tous les 3 mois.

🎯 Résultat : tu passes d’un tracking flou à un système gouverné, vivant et fiable, que même un nouveau venu dans l’équipe peut comprendre en 5 minutes.

Conclusion : Reprendre le contrôle sur son tracking, c’est reprendre le contrôle sur son produit

Tu n’as pas besoin de repartir de zéro pour retrouver des données fiables. Mais tu ne peux plus te permettre de continuer avec un plan de taggage :

• flou,

• non documenté,

• rempli d’événements obsolètes ou jamais utilisés.

En auditant ton plan actuel, en supprimant les événements inutiles, en migrant intelligemment (si besoin), et surtout en mettant en place une vraie gouvernance, tu transformes ton tracking :

• d’un frein à l’analyse… en levier de croissance,

• d’un casse-tête… en atout stratégique,

• d’une boîte noire… en langage commun entre produit, data, dev et marketing.

✅ Récap des étapes :

• 1. Auditer tous les événements existants et les reconnecter aux parcours réels

• 2. Nettoyer les événements inutiles, doublons et erreurs

• 3. Migrer si nécessaire vers un outil plus adapté à tes enjeux

• 4. Maintenir ton tracking propre avec une vraie gouvernance (owner, sprint review, versioning)

👋 Besoin d’un accompagnement pour assainir ton tracking ?

Je peux t’aider à :

• Réaliser un audit complet de ton plan existant (Firebase, Amplitude, Mixpanel…)

• Recommander une migration (ou pas) en fonction de ton besoin produit

• Construire un plan de taggage versionné, documenté et maintenable

• Travailler avec tes équipes produit, data et dev pour remettre le tracking au service de ton business

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.