GA4 pour une application mobile : Firebase, événements et DebugView

GA4 rapporte les données, Firebase relie l'application

Firebase sert de projet et de couche de connexion pour l'application. Le SDK est intégré à l'application iOS ou Android, recueille des événements automatiques et personnalisés, puis les envoie au projet Firebase. Lorsque ce projet est associé à Google Analytics, les données apparaissent dans une propriété GA4.

Google présente cette liaison comme un moyen de mesurer l'engagement dans une application et, lorsqu'un site existe aussi, de rapprocher une partie des parcours. Cela ne définit pas automatiquement l'activation, une réservation ou un achat réussi. Ces décisions appartiennent à l'équipe produit.

Firebase reste proche de la configuration technique de l'application. GA4 sert davantage à analyser les parcours, créer des entonnoirs, comparer des audiences et choisir des actions importantes. La documentation Firebase sur les événements explique la différence entre les événements collectés automatiquement et ceux que l'équipe doit définir.

Le chemin d'une action jusqu'au rapport

Décris ce chemin avant de développer. Cela révèle rapidement une propriété GA4 reliée au mauvais projet, ou un événement envoyé sans paramètres vérifiables.

Sépare les données de développement et de production lorsque l'architecture le permet. Des achats de test mélangés au chiffre réel perturbent les décisions. Documente au minimum l'environnement, la version et les compilations autorisées à envoyer des données de production.

Prépare le dictionnaire d'événements avant le code

Le dictionnaire d'événements est un accord court entre produit, design, développement, QA et analyse. Il précise le sens d'un événement, son moment de déclenchement, ses paramètres et la personne qui l'utilise. Sans cette règle, la même action peut devenir `signup`, `sign_up_complete` ou `registration_done` selon l'équipe qui l'a développée.

Commence par les questions du produit :

• À quel moment une nouvelle personne obtient-elle son premier résultat utile ?
• Quelle étape bloque une réservation, une commande, une leçon ou un paiement ?
• Quelle erreur nécessite une modification du produit et laquelle doit être traitée par le support ?
• Quel événement confirme-t-il qu'un abonnement ou une adhésion est actif ?
• Quelle action montre-t-elle qu'une personne revient pour une raison utile ?

Garde des noms stables et place le contexte dans des paramètres. `checkout_started` reste comparable même si le texte du bouton change. Des paramètres comme `plan_type`, `payment_method`, `course_id` ou `error_type` ajoutent du contexte sans multiplier les événements.

Les événements utiles pour un premier produit

Les événements automatiques sont un bon point de départ, mais une application commerciale a besoin de ses propres actions. Une application de cours ne possède pas le même entonnoir qu'une application de réservation ou une boutique.

N'envoie pas de nom, de téléphone, d'adresse e-mail ou de texte médical libre dans les paramètres. Un identifiant de commande peut être utile pour une vérification autorisée, mais il ne doit pas devenir une façon détournée d'identifier une personne.

Pour un MVP, un dictionnaire court est plus facile à tester qu'une collection de centaines d'événements. La personne responsable du produit doit pouvoir expliquer chaque événement en une phrase et préciser la décision qu'il aide à prendre.

DebugView et Realtime ne répondent pas à la même question

La première vérification ne se fait pas dans le rapport standard. Les données peuvent demander un délai de traitement et les rapports peuvent appliquer des filtres différents. Pendant l'intégration, utilise un appareil de développement et un scénario connu.

Firebase DebugView permet de voir l'activité d'un appareil en mode débogage avec un délai réduit. L'équipe peut ouvrir un événement et inspecter ses paramètres. Google indique comment activer le mode sur Android avec `adb` et sur iOS avec un argument de lancement Xcode. Le mode débogage sert à valider l'intégration, pas à représenter le trafic normal de production.

Realtime dans GA4 permet de vérifier que l'activité récente arrive dans la bonne propriété et le bon flux d'application. Il ne remplace pas un scénario de test. Déclenche un événement, vérifie ses paramètres, recommence après un redémarrage et confirme qu'un double appui ne crée pas deux achats ou deux réservations.

Une vérification simple avant publication suit cet ordre :

1. Installe une version de développement propre sur un appareil réel.
2. Active le mode débogage Analytics.
3. Termine le parcours principal avec un compte de test.
4. Vérifie dans DebugView le nom et les paramètres obligatoires.
5. Recommence avec une mauvaise connexion, une permission refusée et après un redémarrage.
6. Contrôle dans Realtime que l'activité arrive dans le bon flux d'application.
7. Désactive le débogage avant de transmettre la version aux utilisateurs ordinaires.

Les actions importantes doivent représenter le succès

GA4 peut recevoir beaucoup d'événements, mais ils ne méritent pas tous le même niveau d'attention. Marque comme actions importantes les résultats qui comptent pour l'activité : une réservation confirmée, un abonnement payé, une commande terminée, une première leçon suivie ou un contact qualifié.

Ne transforme pas `screen_view`, `button_tap` et chaque ouverture de menu en actions importantes. Un rapport plein d'activité ne montre pas si le produit progresse. Un entonnoir utile peut suivre `first_open`, `sign_up_complete`, `first_value_reached`, ou `product_viewed`, `checkout_started`, `purchase_complete`.

Chaque action importante a besoin d'un responsable. Le produit définit le succès, le développement rend l'événement fiable, la QA vérifie les cas limites et l'analyse suit le résultat après publication. Toute modification de nom, de paramètre ou de condition de déclenchement doit être liée à la version de l'application.

Paramètres, propriétés et versions

Les paramètres décrivent un événement. Les propriétés utilisateur servent à comparer des groupes stables et non sensibles. La plateforme, la version et l'environnement donnent le contexte technique.

Par exemple, `booking_complete` peut contenir `service_type`, `payment_method`, `amount` et `currency`. `account_role` peut distinguer client et professionnel si cette information est nécessaire et appropriée. `app_version`, `platform` et `environment` appartiennent au contexte technique.

Définis les valeurs autorisées. Si une version envoie `online_course` et une autre `course_online`, le rapport crée deux catégories. Ajoute les événements à la trame de spécification technique d'une application mobile et indique qui peut modifier le dictionnaire.

Les problèmes qui rendent les données peu fiables

La plupart des incidents viennent d'un passage de relais incomplet :

• l'application utilise le mauvais projet Firebase ou le mauvais flux de production ;
• le même événement est ajouté à deux endroits et se déclenche deux fois ;
• iOS, Android et le serveur utilisent des noms différents ;
• le paramètre nécessaire manque précisément dans le parcours en erreur ;
• l'équipe consulte un rapport standard juste après un test et pense que l'événement est perdu ;
• le trafic de débogage est confondu avec le trafic réel ;
• une modification du SDK ou du consentement est publiée sans nouveau test ;
• l'événement d'achat part au début du paiement et non après sa confirmation.

Un dictionnaire partagé, une liste de publication et des tests reproductibles règlent mieux ces problèmes qu'un tableau de bord supplémentaire. Si l'événement part au mauvais moment, le rapport ne peut pas corriger le parcours.

Confidentialité et informations des stores

L'analytique influence les informations de confidentialité, le consentement et les formulaires des stores. Apple demande de décrire les données collectées par l'application et les tiers. Google Play demande des informations exactes dans la section Data safety. La réponse dépend du SDK installé, des types de données, de la finalité, de la conservation et du contexte juridique.

Ne copie pas une déclaration trouvée dans une autre application. Relie chaque SDK, paramètre, propriété et destination au flux réel. Réduis les données collectées et demande une revue adaptée si l'application traite la santé, les enfants, la finance, la localisation ou une autre donnée sensible. Notre guide sur la politique de confidentialité mobile décrit la mise en cohérence générale.

La façon dont Appfyl intègre l'analytique

Appfyl considère la mesure comme une partie du périmètre produit. Pendant la découverte, nous relions les questions métier aux parcours principaux, choisissons les événements du premier lancement et repoussons le suivi sans décision utile. Le dictionnaire devient un document partagé par le produit, le mobile, le backend et la QA.

Avant la publication, nous vérifions la version réelle dans DebugView et Realtime, les scénarios réussis et les erreurs, puis les informations de confidentialité par rapport aux SDK réellement intégrés. L'outil peut changer, mais la responsabilité de données fiables reste dans le projet.

Si tu ne sais pas encore quelles mesures inclure dans le MVP, ajoute-les au brief d'estimation Appfyl avec les rôles, les paiements, l'administration et le parcours principal. Le nom d'un outil ne suffit pas à estimer le travail.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

L'ordre conseillé avant le lancement

1. Écris les questions auxquelles la première version doit répondre.
2. Dessine le parcours principal et choisis les événements de résultat.
3. Note les noms, paramètres, valeurs autorisées et responsables dans la spécification.
4. Confirme le projet Firebase, les identifiants de l'application et la propriété GA4.
5. Implémente les événements automatiques et personnalisés sans données personnelles inutiles.
6. Teste succès, erreur, hors connexion, permission refusée et redémarrage dans DebugView.
7. Confirme l'activité récente dans Realtime et configure les actions importantes.
8. Compare politique, consentement et formulaires des stores au comportement réel des SDK.
9. Transmets le dictionnaire et la version avec la documentation de livraison.
10. Observe le premier entonnoir après le lancement avant d'ajouter de nouveaux événements.

Questions fréquentes