Un tag dans une application mobile recouvre deux réalités techniques distinctes que la plupart des articles confondent. Le premier sens désigne une étiquette visible attachée à un contenu pour le classer et le retrouver. Le second, plus opérationnel, désigne un événement de mesure déclenché par une action utilisateur et transmis à un outil d’analytics. Les deux mécanismes coexistent dans une même application, mais répondent à des logiques de conception radicalement différentes.
Tag de tracking mobile : événement, déclencheur et paramètres
Dans le contexte du tracking mobile, un tag est un bloc de code (ou une configuration dans un gestionnaire de balises) qui s’exécute lorsqu’une condition précise est remplie. Cette condition s’appelle un déclencheur. Le tag collecte alors des données et les envoie à un outil tiers : Firebase, Google Tag Manager, une solution d’attribution ou un serveur propriétaire.
Un tag de tracking se compose de trois éléments : le type de balise (Google Analytics, pixel publicitaire, SDK tiers), le déclencheur qui conditionne son activation, et les paramètres qui précisent le contexte de l’événement. Ces paramètres sont ce qui donne de la valeur aux données collectées.
Google Tag Manager gère les balises en mode natif pour Android et iOS, ce qui évite d’intégrer ces segments de code directement dans le projet. Les configurations se publient depuis l’interface sans déploiement applicatif.
Différence entre un événement recommandé et un événement personnalisé
Firebase, par exemple, distingue trois catégories d’événements. Les événements collectés automatiquement ne nécessitent aucune configuration supplémentaire après l’intégration du SDK. Les événements recommandés couvrent les actions courantes et facilitent les rapports standards. Les événements personnalisés servent aux actions propres à l’application, celles que les outils ne peuvent pas anticiper.
Définir un événement selon l’action et le résultat attendu vaut mieux qu’enregistrer mécaniquement chaque écran ou clic. Ouvrir un formulaire et le soumettre avec succès sont deux événements distincts, même s’ils concernent le même écran. Cette granularité conditionne la qualité des analyses qui suivront.
Chaque événement personnalisé doit avoir un nom non ambigu et des paramètres qui précisent le contexte : identifiant de l’écran, valeur transmise, statut de l’utilisateur. Sans ces paramètres, l’événement confirme qu’une action a eu lieu, mais n’explique pas dans quelles conditions.
Tag comme étiquette de contenu : logique de classification dans l’app
Dans une application éditoriale, un agrégateur ou une marketplace, le tag désigne une étiquette textuelle associée à un contenu pour faciliter la navigation. Un article, un produit ou un profil peuvent recevoir plusieurs tags simultanément. L’utilisateur filtre ensuite les contenus en sélectionnant un ou plusieurs tags.
Ce type de tag n’est pas du code : c’est une métadonnée stockée en base de données, affichée en interface et exploitée par le moteur de recherche interne de l’application. Sa valeur est sémantique, pas technique.
La distinction avec une catégorie est importante. Une catégorie structure la hiérarchie de l’application, un tag traverse cette hiérarchie. Un même contenu peut appartenir à une seule catégorie mais recevoir plusieurs tags issus de dimensions différentes.
Comment créer un tag de tracking dans une application mobile
La méthode varie selon que l’on passe par un gestionnaire de balises ou par une intégration directe du SDK.
- Via Google Tag Manager pour mobile : créer un conteneur pour l’application, l’associer à l’identifiant de l’app, configurer un tag depuis l’interface (type de balise, déclencheur, variables), puis publier la version. Le SDK GTM récupère la configuration au prochain lancement de l’application.
- Via Firebase directement : intégrer le SDK Firebase dans le projet Android ou iOS, appeler la méthode logEvent() au point de code correspondant à l’action, en passant le nom de l’événement et un objet de paramètres. La donnée remonte dans la console Firebase sans intermédiaire.
- Via un SDK tiers : chaque outil (Amplitude, Mixpanel, AppsFlyer) expose une méthode d’enregistrement d’événement similaire. L’intégration implique de vérifier ce que le SDK collecte au-delà des événements déclarés, y compris les données transmises automatiquement.
Ce troisième point mérite une attention particulière. Ajouter un SDK tiers rend l’équipe responsable de l’ensemble des données collectées et transmises par cette bibliothèque, même si l’application elle-même n’envoie pas explicitement ces données. Pour Google Play, les déclarations de sécurité des données doivent tenir compte des SDK intégrés.
Points de vigilance sur iOS et la conformité au tracking
Sur iOS, la présence d’un SDK d’analytics ne détermine pas à elle seule si la demande App Tracking Transparency (ATT) doit s’afficher. C’est la nature des données collectées et leur usage (notamment le croisement avec des données d’autres applications) qui déclenche cette obligation. Un tag qui enregistre des événements purement internes à l’application sans les relier à un identifiant publicitaire ne relève pas nécessairement d’ATT.
Confondre analytics interne et tracking publicitaire est l’erreur la plus fréquente dans la configuration des tags sur iOS. Les deux peuvent utiliser les mêmes outils, mais leurs implications de conformité sont différentes.
Plan de taggage : organiser avant d’implémenter
Quelle que soit la méthode choisie, instrumenter une application sans plan de taggage préalable produit des données incohérentes et difficilement exploitables. Un plan de taggage recense les événements à mesurer, leurs déclencheurs, leurs paramètres et l’outil de destination. Il sert de référence partagée entre les équipes produit, développement et data.
- Lister les actions utilisateur qui correspondent à des objectifs métier mesurables (inscription, achat, partage, abandon).
- Attribuer à chaque action un nom d’événement normalisé, des paramètres obligatoires et des paramètres optionnels.
- Identifier l’outil de collecte pour chaque événement et vérifier les contraintes de nommage propres à cet outil.
- Documenter les conditions de déclenchement pour éviter les doublons ou les déclenchements parasites.
Un plan de taggage se construit avant le développement, pas après. Le corriger une fois les tags en production implique souvent un nouveau déploiement de l’application, sauf si un gestionnaire de balises permet de modifier les configurations à distance.
La qualité des données analytiques d’une application mobile dépend directement de la rigueur avec laquelle les tags ont été définis et implémentés. Un événement mal nommé ou un paramètre manquant dans un tag critique peut invalider plusieurs semaines de mesure.
