Event Tracking dans les applications mobiles : définition, types d'événements et configuration

Qu'est-ce que l'Event Tracking ?

L'Event Tracking est le processus de collecte, de stockage et d'analyse des actions discrètes des utilisateurs dans une application. Chaque événement se compose d'un nom (event_name) et d'un ensemble de paramètres (event_params). Par exemple, l'événement purchase possède les paramètres price, currency, product_id, quantity.

Contrairement au Screen View qui enregistre le fait d'ouvrir un écran, l'Event Tracking décrit ce que l'utilisateur fait exactement sur cet écran : il a cliqué sur le bouton « Acheter », ouvert le panier, appliqué un code promo. Sans événements, il est impossible de comprendre la motivation et le contexte des actions de l'utilisateur.

Structure d'un événement

Chaque Analytics Event contient des champs obligatoires et facultatifs. Obligatoires : event_name, event_timestamp, user_id (ou device_id). Facultatifs : paramètres, description du contexte.

Le paramètre revenue est particulièrement important — il est transmis aux plateformes MMP pour le calcul automatique du ROAS et du LTV.

Types d'événements dans l'analytique mobile

Les événements sont classés par origine et par objectif. Cette classification permet d'organiser la structure des données et de définir les droits d'accès pour différentes équipes.

Événements automatiques (SDK)

Les SDK des plateformes analytiques collectent automatiquement les événements de base : app_install, app_remove, session_start, screen_view. Firebase Analytics génère environ 20 événements automatiques sans une seule ligne de code. Ces événements couvrent les métriques de base mais ne permettent pas de comprendre la logique métier.

Événements personnalisés (Custom Events)

Les événements personnalisés sont ce qui rend l'Event Tracking précieux. Ils décrivent les actions métier : add_to_cart, start_subscription, level_complete, share_content, search_performed. Les événements personnalisés nécessitent un envoi explicite depuis le code de l'application.

// Envoi d'un événement personnalisé à Firebase
val bundle = Bundle().apply {
    putString(AnalyticsParam.ITEM_ID, "prod_789")
    putString(AnalyticsParam.ITEM_NAME, "Premium Subscription")
    putString(AnalyticsParam.CURRENCY, "USD")
    putDouble(AnalyticsParam.PRICE, 29.99)
    putString(AnalyticsParam.SOURCE, "onboarding_screen")
}
FirebaseAnalytics.getInstance(this)
    .logEvent("subscribe_premium", bundle)

Dans l'exemple, l'événement subscribe_premium contient quatre paramètres de contexte. Le paramètre source permet de savoir depuis quel écran l'utilisateur a souscrit — onboarding, paramètres ou paywall.

User Properties et Super Properties

En plus des événements, l'Event Tracking inclut les User Properties — des attributs liés à l'utilisateur : niveau d'abonnement, pays, version de l'application. Une User Property est envoyée une fois et s'applique à tous les événements suivants de la session. Cela permet de segmenter l'analytique sans ajouter de paramètres à chaque événement.

Les Super Properties (Amplitude) ou Global Properties (Mixpanel) sont des attributs liés à la session, pas à l'utilisateur. Utilisées pour les tests A/B : variant_id est ajouté comme Super Property à tous les événements de la session, permettant à l'analyste de voir à quel groupe appartient l'utilisateur.

Événements de revenu

Les événements de revenu sont une classe distincte pour enregistrer les transactions. Ils contiennent le montant, la devise et le type d'achat (abonnement, achat unique, restauration). Les plateformes MMP (AppsFlyer, Adjust) ont besoin des événements de revenu pour calculer le ROAS.

Selon Branch (2024), les applications qui transmettent correctement les événements de revenu aux MMP obtiennent des données d'attribution 25 % plus précises et peuvent optimiser leurs campagnes sur le LTV plutôt que sur le CPI.

Comment configurer l'Event Tracking ?

La configuration de l'Event Tracking se déroule en trois étapes : planification du schéma d'événements, intégration du SDK, validation des données.

Étape 1 : Conception du schéma d'événements

Créez une Event Taxonomy — un document décrivant chaque événement : nom, paramètres, déclencheur d'envoi, responsable. Exemple pour l'e-commerce : order_completed → paramètres : order_id, total_price, items_count, payment_method, shipping_city.

• Chaque événement répond à la question : qu'a fait l'utilisateur ?
• Chaque paramètre répond à la question : dans quel contexte ?
• Évitez les événements sans paramètres — ils sont inutiles pour l'analyse

Étape 2 : Intégration du SDK

Intégrez le SDK d'analytique au projet. Firebase Analytics, Amplitude, Mixpanel — chaque SDK nécessite une initialisation dans Application.onCreate(). Exemple pour Flutter :

import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  final _analytics = FirebaseAnalytics.instance();

  Future<void> logPurchase({
    required String productId,
    required double price,
    required String currency,
  }) async {
    await _analytics.logEvent(
      name: 'purchase_completed',
      parameters: {
        'product_id': productId,
        'price': price,
        'currency': currency,
        'timestamp': DateTime.now().millisecondsSinceEpoch,
      },
    );
  }
}

La classe AnalyticsService centralise l'envoi de tous les événements. Chaque méthode correspond à une action métier. Cela simplifie la recherche — si un événement n'arrive pas, on cherche par le nom de la méthode dans le code. Avec la montée en charge du projet, le nombre de méthodes peut atteindre 50 à 100, mais la structure reste lisible grâce au regroupement par fonctionnalités.

Étape 3 : Validation avec DebugView

Firebase DebugView permet de voir les événements en temps réel sur l'appareil du développeur. Activez le mode : adb shell setprop debug.firebase.analytics.app your.package. Tous les événements apparaissent dans la console Firebase avec moins de 5 secondes de latence.

Après avoir activé DebugView, ouvrez l'application et exécutez un scénario de test — inscription, achat, navigation dans le catalogue. Vérifiez dans la console : tous les événements ont-ils été envoyés, les bons paramètres sont-ils transmis, n'y a-t-il pas de doublons. Amplitude propose un outil similaire — Amplitude Debugger pour iOS et Android.

La validation automatique via CI/CD est le niveau de qualité suivant. Ajoutez un script à la pipeline qui vérifie que chaque événement du schéma a été envoyé au moins une fois pendant le test. Cela empêche le déploiement de versions avec des événements manquants et fait gagner du temps aux ingénieurs QA.

Bonnes pratiques de nommage des événements

Le nommage des événements est l'aspect le plus sous-estimé de l'Event Tracking. Un mauvais nom rend l'analytique inutile dès que le projet dépasse 50 événements.

Standard Object + Action

Utilisez le modèle object_action (minuscules, snake_case) : product_added, cart_opened, payment_failed, subscription_cancelled. L'objet est l'entité, l'action est le verbe au passé. Cela se lit comme une phrase : « produit ajouté », « panier ouvert ».

• product_viewed, pas "tap_on_product_card" (l'événement est le résultat, pas l'action)
• order_completed, pas "successful_payment_transaction" (court et clair)
• level_started, pas "begin_level_with_parameters" (sans mots superflus)

Modèles interdits

N'utilisez PAS d'espaces ("Add to Cart"), de CamelCase ("AddToCart"), de points ("add.to.cart"), de tirets ("add-to-cart"). La plupart des SDK recommandent le snake_case. N'utilisez PAS de noms d'éléments d'interface ("btn_submit_clicked") — l'événement doit être métier, pas technique.

Ajoutez un préfixe avec le nom de la fonctionnalité ou de l'écran : onboarding_step_completed, checkout_payment_selected. Cela permet de filtrer les événements par fonctionnalité dans les rapports.

Types de paramètres d'événements

Les paramètres se divisent en trois types : string (valeur), number (nombre pour l'agrégation), boolean (drapeau). Les paramètres string contiennent des données catégorielles : pays, source de trafic, nom du produit. Les paramètres number servent de métriques : prix, quantité, durée. Les paramètres boolean indiquent un état : is_trial, is_promo_applied.

Évitez de passer des objets ou des tableaux dans un seul paramètre — les plateformes analytiques ne savent pas les parser. Au lieu d'une chaîne JSON dans un seul champ, passez plusieurs paramètres plats. Par exemple, au lieu de items_count_total, passez items_count et total_price séparément.

Plateformes d'Event Tracking

Le choix de la plateforme d'Event Tracking dépend de l'ampleur du projet et de l'équipe. Examinons trois options de différents niveaux.

Firebase Analytics (gratuit, jusqu'à 500 événements)

Firebase est le choix standard pour les startups. La limite gratuite est de 500 event_name différents, nombre de paramètres illimité. Intégration avec BigQuery pour l'analytique personnalisée. Inconvénients : segmentation limitée, pas de liaison automatique des événements en session.

Amplitude (Pro à partir de 1 000 $/mois)

Amplitude est une plateforme d'analytique produit. Elle prend en charge les Behavioural Cohorts, l'analyse d'entonnoir (Funnel Analysis) et Pathfinder. Permet de créer des événements virtuels à partir de combinaisons d'événements réels. Intégrée à plus de 50 outils via Segment.

Segment (à partir de 120 $/mois)

Segment est un middleware de gestion d'événements. Vous envoyez les événements à Segment, qui les distribue à plus de 300 outils. Utile dans les environnements enterprise où Firebase, Amplitude, Mixpanel, Braze et Salesforce sont utilisés simultanément.

PostHog (alternative open-source)

PostHog est une plateforme d'analytique produit open-source avec son propre Event Tracking. Elle prend en charge la capture automatique d'événements, l'enregistrement de session et les feature flags. Déployée sur votre propre serveur, ce qui est crucial pour les projets soumis au GDPR ou traitant des données confidentielles. Fournit une API compatible Python pour les pipelines ETL.

Pour les projets Flutter, nous recommandons flutterfire_analytics + Amplitude via le plugin amplitude_flutter. Pour React Native — react-native-firebase + mixpanel-react-native.