GA4 Web & App : guide express pour un tracking 360°
Points abordés dans cet article
- Web + App : la check-list express pour vos rapports GA4 🔗
- Ce que vous allez apprendre dans cet article
- 1. Pourquoi unifier Web & App ?
- 2. GA4 vs Firebase UI : deux interfaces, un même SDK
- 3. Panorama technique : comment GA4 et Firebase s’imbriquent
- 4. Mode d’emploi pas-à-pas
- 5. Évènements auto-collectés : tout ce que GA4 capture « gratuitement »
- 6. Évènements recommandés & personnalisés
- 7. Fonctionnalités exclusives de l’interface GA4
- 8. Évènements recommandés & personnalisés
- 9. Fonctionnalités exclusives de l’interface GA4
- 10. Exploiter la donnée cross-plateforme
- 11. Checklist post-déploiement
- 12. Best practices 2025+
- 13. Conclusion
- FAQ – 10 questions fréquentes
- Glossaire express des termes techniques rencontrés dans l’article
- 📚 Pour aller plus loin
Mis à jour le 4 juillet 2025
Web + App : la check-list express pour vos rapports GA4 🔗
- 1· But — Réunir site & app dans UNE propriété GA4 pour un suivi 360 ° (install ➜ achat desktop).
- 2· Pourquoi c’est clé ?
- ❌ Plus de doublons sessions/utilisateurs.
- 🛒 Funnels cross-device, LTV consolidée.
- 🎯 Audiences remarketing communes Web + App.
- 🤖 Insights & audiences prédictives activables en Ads / FCM.
- 3· Matériel minimum
- Propriété GA4 déjà installée côté Web (Google tag ou GTM).
- Projet Firebase existant ou à créer.
- SDK “Google Analytics for Firebase” (v11+).
- 4· Pas-à-pas (3 clics)
- GA4 ▸ Admin ▸ Add App Stream.
- Link existing Firebase project (ou “Create new”).
- Intégrer le SDK iOS & Android → vérifier dans DebugView.
- 5· Une fois en place …
- ⚡ Explorations : funnels, pathing, cohortes cross-device.
- 📈 BigQuery export gratuit (< 1 M events/j) pour SQL et ML.
- 🛠️ Recommended events + 500 noms personnalisés max ; regrouper via paramètres !
- 6· Bonnes pratiques 2025+
- ✅ DebugView en staging, quotas < 500 noms / 25 params.
- 🔒 Consent Mode v2 & Privacy Sandbox mobile prêts.
- 🖥️ Pensez sGTM pour un proxy first-party anti-adblock.
➡️ Suivez cette fiche et convertissez vos données dispersées en insights actionnables — sans une ligne de SQL !
Votre app cartonne, votre site convertit… mais vos rapports GA4 ressemblent encore à un puzzle incomplet ?
Avec Google Analytics 4 (GA4), trois clics suffisent pour fusionner les pièces : ajoutez un flux App alimenté par le SDK Firebase et regroupez Web + Mobile dans une seule propriété. Résultat : une vision 360 ° des parcours — de la première installation mobile au checkout desktop —, des audiences unifiées pour vos campagnes et des insights prédictifs qui parlent enfin la même langue que votre business.
Ce que vous allez apprendre dans cet article
- Pourquoi unifier Web & App ?
Les limites des rapports séparés, l’impact sur les audiences et la valeur vie client (LTV). - GA4 vs Firebase UI : deux interfaces, un seul SDK
Même données, deux tableaux de bord : quand privilégier la console Firebase centrée développeur et quand passer à l’UI GA4 orientée marketing. - Architecture technique simplifiée
Propriété GA4, projet Firebase, SDK unique, BigQuery — comment tout s’imbrique sans sur-coût ni doublon. - Pas-à-pas de l’implémentation
- Créer ou lier un projet Firebase.
- Configurer les flux App iOS & Android.
- Installer le SDK et activer les événements automatiques.
- Au-delà du suivi de base
- Événements recommandés & personnalisés (500 noms uniques).
- Explorations GA4 (funnels, pathing, cohortes).
- Rapports exclusifs jeux & e-commerce.
- Checklist de validation et bonnes pratiques 2025+
DebugView, quotas, Consent Mode v2, Privacy Sandbox mobile et server-side tagging. - FAQ express
Dix réponses rapides pour lever les doutes les plus courants (Flutter, React Native, GTM, etc.).
1. Pourquoi unifier Web & App ?
Lorsque vos données Web et Mobile vivent dans deux propriétés distinctes, GA passe son temps à empiler des sessions et des utilisateurs en double – impossible, ensuite, de reconstruire un parcours ou une valeur client cohérents. En fusionnant vos flux Web (Google tag) et App (SDK Firebase) dans UNE propriété GA4, vous éliminez ces biais et débloquez de nouveaux leviers marketing.
1.1 Fin des doublons de sessions
GA4 s’appuie sur une « reporting identity » hiérarchique – User-ID, données Google signals, device ID, puis modélisation – pour regrouper toutes les interactions d’un même individu, même s’il change d’appareil ou refuse les cookies. Résultat : moins de sessions fantômes et des métriques (utilisateurs, taux de conversion, revenu moyen) enfin fidèles à la réalité.
1.2 Parcours cross-device sans couture
Avec les data streams Web + App réunis, chaque étape du funnel (ex. « première ouverture d’app → ajout au panier mobile → achat desktop ») devient traçable dans un seul rapport : funnels exploratoires, analyses de chemin (pathing), vues en temps réel, etc. Cette vision 360° révèle les véritables points de friction et aide à prioriser les optimisations UX ou CRM.
1.3 Audiences et LTV plus fiables
- Remarketing multi-support : les listes GA4 agrègent automatiquement Web + App et se synchronisent avec Google Ads pour recibler les mêmes utilisateurs où qu’ils soient.
- Lifetime Value sans approximations : l’exploration « User lifetime » calcule le revenu cumulé, la probabilité d’achat ou de churn sur l’ensemble du cycle de vie, sur tous les écrans. Parfait pour pondérer vos coûts d’acquisition et arbitrer vos budgets media.
Ce qu’il faut retenir
Passer à une propriété GA4 unifiée, c’est :
- Nettoyer vos KPIs (utilisateurs uniques, taux de conversion).
- Lire un vrai parcours client, du premier scroll in-app au paiement sur desktop.
- Activer des audiences premium et piloter l’investissement média sur une LTV consolidée.
En clair : un seul taggage, mais trois victoires immédiates pour votre marketing et votre analyse produit.
2. GA4 vs Firebase UI : deux interfaces, un même SDK
2.1 Même SDK, mêmes données
Que vous regardiez vos chiffres dans la console Firebase ou dans l’interface GA4, le flux provient du même SDK Google Analytics for Firebase.
- Ajoutez simplement le SDK à l’app ; les événements partent vers la propriété GA4 et s’affichent dans Firebase quelques heures plus tard.
- Une fois le projet Firebase lié à la propriété, la collecte devient bidirectionnelle : le tag Web (G-tag) et le SDK mobile alimente une base unique que les deux UIs interrogent.
À retenir : aucune duplication de taggage – seul l’affichage change.
2.2 Console Firebase : la vue développeur
Pensée pour les équipes mobile, la console Firebase met l’accent sur le build-measure-learn :
| Atout clé | Comment ça aide un dev mobile ? | |
|---|---|---|
| A/B Testing intégré | Lancer/stopper une expérience sans publier une nouvelle build | |
| Remote Config | Pousser une config, activer un flag pour un segment précis | |
| Crashlytics + Analytics | Croiser taux de crash et événements pour cibler les correctifs | |
| Audiences ↔ FCM | Déclencher une notif push sur un segment Analytics en un clic |
3. Panorama technique : comment GA4 et Firebase s’imbriquent
3.1 La propriété GA4, hub unique
Une propriété GA4 peut héberger autant de flux qu’il vous faut :
- Web (Google tag ou GTM)
- Android et iOS (SDK Google Analytics for Firebase)
Dès qu’un flux App est créé, GA4 propose soit de lier un projet Firebase existant, soit d’en générer automatiquement un nouveau. La bonne pratique ? **Toujours relier votre projet Firebase déjà utilisé par l’app ** : vous évitez les doublons et conservez vos intégrations Remote Config, Crashlytics, etc.
3.2 Projet Firebase : passerelle Mobile → GA4
Le projet Firebase agit comme un conteneur mobile : il stocke les clés de configuration, sert le SDK et pousse les événements vers la propriété GA4 liée. Une fois la liaison établie (« Connect Firebase to Google Analytics »), la console Firebase crée pour chaque plateforme un App Stream dans GA4, prêt à recevoir les données.
3.3 SDK unifié : un seul code, deux consoles
Le SDK Google Analytics for Firebase (≥ v 11.x en 2025) envoie les mêmes événements à :
- Firebase UI – orientée développeurs pour A/B Testing, Remote Config, notifications.
- GA4 UI – orientée marketing pour Explorations, Advertising Hub, e-commerce & jeux.
Aucune duplication : un seul appel logEvent() alimente simultanément les deux interfaces.
3.4 BigQuery Export : vos données brutes en quasi temps réel
En un lien (Admin ▸ BigQuery Links), vous pouvez :
| Option | Délai d’arrivée | Tables créées | Idéal pour |
|---|---|---|---|
| Daily export (gratuit) | < 24 h | events_YYYYMMDD |
Reporting batch, modélisation historique |
| Streaming export (payant) | Quelques minutes | events_intraday_YYYYMMDD + daily |
Tableaux de bord temps réel, alertes |
4. Mode d’emploi pas-à-pas
Étape 1 — Créer ou lier le projet Firebase
| Situation | Que faire ? | Points de vigilance |
|---|---|---|
| Votre app utilise déjà Firebase | 1. Ouvrez GA4 ▸ Admin ▸ Data Streams ▸ Add App Stream. 2. Choisissez “Link an existing Firebase project” et sélectionnez le projet. 3. Validez : le flux iOS/Android apparaît instantanément dans GA4 ; côté Firebase la propriété GA4 est également listée. |
• Vous devez être Owner ou Editor à la fois sur la propriété GA4 et sur le projet Firebase. • Vérifiez que l’option Google Analytics – Enable est activée dans Project Settings ▸ Integrations. |
| Votre app n’a pas Firebase | 1. Depuis GA4 ▸ Add App Stream, cliquez Create new Firebase project. 2. Nommez le projet, acceptez les conditions, puis laissez l’assistant générer le flux App. 3. Poursuivez immédiatement avec l’installation du SDK (étape 3). |
• Le projet Firebase créé reprend automatiquement le nom de la propriété GA4 (modifiable). • Les quotas gratuits Firebase suffisent pour la plupart des apps ; anticipez le passage au plan Blaze si vous activez BigQuery export + FCM push massif. |
5. Évènements auto-collectés : tout ce que GA4 capture « gratuitement »
5.1 Qu’est-ce qu’un évènement auto-collecté ?
Dès que le SDK Firebase est initialisé, GA4 enregistre sans la moindre ligne de code une série d’évènements standards. Ils décrivent les bases du cycle de vie de l’app et quelques interactions clés ; vous les verrez apparaître immédiatement dans DebugView, puis dans les rapports temps réel.
| Évènement | Quand se déclenche-t-il ? | Exemple d’usage |
|---|---|---|
| first_open | Au tout premier lancement de l’app (post-installation) | Compter les nouvelles installations réelles ; créer une audience « nouveaux utilisateurs ». |
| session_start | À chaque retour en avant-plan après ≥ 30 min d’inactivité | Suivre le nombre de sessions et la durée moyenne. |
| user_engagement | Toutes les 10 s, puis à la fermeture de l’app | Mesurer le temps passé actif par session. |
| screen_view | À chaque changement d’écran (UIViewController / Activity) | Construire des funnels d’écrans, repérer les points de friction UX. |
| in_app_purchase (Android) | Après un achat validé via Google Play | Suivre le revenu, la valeur moyenne d’ordre, la LTV. |
| app_update / app_remove | App installée puis mise à jour / désinstallée | Évaluer la rétention après mise à jour, détecter les churns précoces. |
6. Évènements recommandés & personnalisés
6.1 Pourquoi partir des “Recommended events” ?
Google publie une table de plus de 80 évènements pré-nommés ( login, add_to_cart, purchase, level_up, tutorial_complete, etc. ).
Les utiliser tels quels déverrouille automatiquement :
- les rapports e-commerce (CA, panier moyen, remboursements) ;
- les tableaux Jeux (rétention par niveau, ARPU) ;
- les dimensions et entonnoirs prêts à l’emploi dans Explorations.
⚠️ Astuce : si l’un de ces noms correspond à votre besoin, recyclez-le au lieu d’inventer un alias : vous gagnerez des rapports sans configuration supplémentaire.
6.2 Syntaxe logEvent() (SDK Firebase ≥ v 11)
// Android / Kotlin
Firebase.analytics.logEvent("add_to_cart") {
param("currency", "EUR")
param("value", 39.90)
param("items", "[{\"item_id\":\"SKU_123\"}]")
}
// iOS / Swift
Analytics.logEvent("add_to_cart", parameters: [
"currency":"EUR",
"value":39.90,
"items":[["item_id":"SKU_123"]]
])- Nom : ≤ 40 car., lettres/chiffres+underscore, démarre par une lettre.
- Paramètres : max 25 par évènement (dont 10 dans
items[]). - Requête MP : max 25 évènements par appel lorsque vous passez par le Measurement Protocol.
6.3 Limite “500 noms uniques” : comment la gérer ?
Sur les flux App, GA4 accepte 500 noms d’évènements distincts par utilisateur ; les auto-collectés et Enhanced Measurement ne comptent pas dans ce quota. Les flux Web ne sont pas plafonnés mais gardez votre plan de marquage lisible.
Bonnes pratiques pour rester sous le seuil :
| Mauvaise idée | Bonne idée |
|---|---|
button_click_signup, button_click_buy, button_click_share |
Un seul button_click + paramètre purpose |
scroll_25, scroll_50, scroll_75 |
Un seul scroll_depth + paramètre percentage |
video_start_ID123, video_start_ID987 |
video_start + paramètre video_id |
7. Fonctionnalités exclusives de l’interface GA4
| Bloc | Ce que vous débloquez | Cas d’usage phare |
|---|---|---|
| Explorations avancées | • Funnel Exploration : entonnoirs sur-mesure, drop-offs, boucles. • Path Exploration : parcours réels avant/après un événement ou un écran clé. • Cohort & User Lifetime : rétention, LTV cumulée, revenu par cohorte. • Segment Overlap : croiser jusqu’à trois segments et mesurer leur intersection. |
– Optimiser un tunnel d’achat cross-device. – Comprendre les chemins qui mènent aux désinstallations. – Chiffrer la valeur vie client par source de trafic. |
| Reporting Jeux | Collection « Games » prête à l’emploi : progression par niveau, ARPU, achats in-app, rétention jour 1/7/30. | Surveiller la difficulté des niveaux, réengager les joueurs à forte probabilité d’achat. |
| E-commerce natif | Rapports : articles vus, ajout panier, achats, remboursements ; Explorations e-commerce pour les funnels d’abandon et la valeur par catégorie. | Détecter les produits à forte marge mais faible conversion, affiner vos campagnes Shopping. |
| Insights & ML | • Détection d’anomalies automatique (pics, chutes). • Audiences prédictives : probabilité d’achat, de churn, revenus attendus. • Alertes proactives dans l’espace Insights. |
Être notifié d’un bug qui divise le CA mobile par 2 ; recibler les utilisateurs à haute probabilité d’achat <5 jours. |
Ce qu’il faut retenir
- Une seule base, mais une puissance d’analyse qui dépasse la console Firebase : funnels, pathing et ML ne sont accessibles que depuis l’UI GA4.
- Ces rapports se construisent en glisser-déposer ; aucun SQL ni export obligatoire pour explorer à la volée.
- Couplés aux flux Web + App, ils offrent une lecture complète du cycle de vie utilisateur — du tuto in-app au panier desktop — et des leviers immédiats pour la monétisation et la rétention.
8. Évènements recommandés & personnalisés
8.1 La « table GA4 » : 80 évènements prêts à l’emploi
| Catégorie | Évènements clés | Paramètres obligatoires |
|---|---|---|
| Engagement | login, sign_up, tutorial_complete | method (login / signup) |
| E-commerce | view_item, add_to_cart, begin_checkout, purchase, refund |
currency, value, items[] |
| Lead / Contenu | generate_lead, share, search, select_content | content_type, item_id |
| Jeux | level_start, level_up, earn_virtual_currency, post_score | level, character |
| Apps / Abonnements | in_app_purchase, subscription_start, subscription_renew | price, subscription_period |
Pourquoi les réutiliser ?
GA4 active automatiquement des rapports prêts à l’emploi (funnel d’achat, jeux,
onboarding, LTV) lorsqu’il reconnaît ces noms exacts.
8.2 Syntaxe logEvent() (SDK Firebase ≥ 11)
// Android / Kotlin
Firebase.analytics.logEvent("add_to_cart") {
param("currency", "EUR")
param("value", 49.90)
param("items", "[{\"item_id\":\"SKU_123\"}]")
}
// iOS / Swift
Analytics.logEvent("level_up", parameters: [
"level": 3,
"character": "elf_archer"
])
- Nom : 40 car. max, snake_case, commence par une lettre.
- Paramètres : 25 max par évènement (dont 10 dans
items[]). - Floats / currency : utiliser le point « . » comme séparateur décimal.
8.3 Limite : 500 noms d’évènements uniques
- Quota appliqué par propriété côté App.
- Les évènements auto-collectés ne comptent pas.
- Au-delà, les nouveaux noms sont ignorés jusqu’au lendemain.
Pour éviter la saturation :
| Mauvais design | Bon design |
|---|---|
| video_start_ID123, video_start_ID456 | video_start + param video_id |
| form_submit_contact, form_submit_demo | form_submit + param form_type |
| scroll_25, scroll_50, scroll_75 | scroll_depth + param percentage |
8.4 Naming convention gagnante
- Utilisez toujours le snake_case :
purchase_success, jamaisPurchaseSuccess. - Préfixez par domaine :
mkt_,ux_,game_, etc. - Choisissez des paramètres parlants :
value,currency,item_category,step. - Documentez dans un dictionnaire partagé : nom, description, paramètres, exemple de payload, propriétaire.
8.5 Checklist avant publication
- Nom déjà présent dans la table ? ⟶ réutiliser.
- ≤ 40 car. & snake_case ?
- Paramètres essentiels renseignés, ≤ 25 ?
- Test visible en DebugView sur Android & iOS ?
- Ajouté au dictionnaire de traçage interne ?
Suivez ces règles : vous resterez sous les 500 noms, profiterez des rapports
automatiques GA4 et garderez un plan de marquage lisible — même quand vos équipes
produit, marketing et data ajoutent chacune leurs propres évènements.
9. Fonctionnalités exclusives de l’interface GA4
| Bloc | Ce que vous débloquez | Cas d’usage phare |
|---|---|---|
| Explorations avancées | • Funnel Exploration : entonnoirs sur-mesure, drop-offs, boucles. • Path Exploration : parcours réels avant/après un événement. • Cohort & User Lifetime : rétention, LTV cumulée. • Segment Overlap : intersection de segments utilisateurs. |
Optimiser le tunnel d’achat cross-device, analyser les chemins menant aux désinstallations, chiffrer la valeur vie client par source de trafic. |
| Reporting Jeux | Collection « Games » prête à l’emploi : progression par niveau, ARPU, achats in-app, rétention J1/J7/J30. | Mesurer la difficulté des niveaux, réengager les joueurs à haute probabilité d’achat. |
| E-commerce natif | Rapports : articles vus, ajout panier, achats, remboursements ; funnels d’abandon et valeur par catégorie. | Identifier les produits à forte marge mais faible conversion, optimiser les campagnes Shopping. |
| Insights & ML | • Détection d’anomalies automatique. • Audiences prédictives : probabilité d’achat, de churn, revenus attendus. • Alertes proactives dans l’espace « Insights ». |
Être notifié d’un bug divisant le CA, recibler les utilisateurs à forte probabilité d’achat < 5 jours. |
En résumé : ces rapports n’existent pas dans la console Firebase.
Couplés aux flux Web + App, ils offrent une vision 360 ° et des leviers immédiats pour la monétisation,
la rétention et l’attribution marketing.
10. Exploiter la donnée cross-plateforme
10.1 Rapports Acquisition unifiés
Une fois les flux Web et App connectés à une même propriété GA4 :
- Vue unique des canaux : « Paid », « Organic », « Direct » agrègent installations, sessions web et conversions in-app.
- Cost + ROI : import des dépenses Google Ads, Meta, TikTok → marge réelle par canal, sans tableur manuel.
- 📊 KPI prêts à l’emploi :
first_open,session_start,purchase,revenuesur le même graphique.
10.2 Funnels mélangeant écrans & pages
Avec Funnel Exploration, superposez écrans mobiles et pages web :
| Étape | Évènement / Page | Plateforme |
|---|---|---|
| 1 | first_open |
App iOS/Android |
| 2 | Écran Search results | App |
| 3 | Page /checkout | Web desktop |
| 4 | purchase |
Web ou App |
Vous identifiez ainsi :
- les points de friction lorsqu’un utilisateur passe de mobile à desktop ;
- les abandons avant paiement pour cibler des relances.
10.3 Audiences prédictives & activation
GA4 calcule automatiquement la probabilité qu’un utilisateur :
- Achète dans les 7 jours (Purchase probability)
- Désinstalle ou devienne inactif (Churn probability)
- Génère un revenu élevé (Predicted revenue)
Créez une audience « High Purchase 7d » → exportez-la vers Google Ads ou FCM push ; le ciblage se met à jour quotidiennement sans action manuelle.
En pratique : combinez ces trois briques pour suivre l’utilisateur du premier clic publicitaire à la ré-achat in-app, optimiser vos entonnoirs et activer les bonnes audiences au bon moment — le tout depuis une seule propriété GA4.
11. Checklist post-déploiement
| 🗹 À vérifier | But / Résultat attendu | Responsable |
|---|---|---|
| DebugView GA4 | • Tous les événements auto + personnalisés remontent. • Paramètres complets, sans doublons. |
Data / Dev |
| Tag Assistant (web) | • Aucun third-party bloqué. • Avertissements GA4 résolus (cookies, consentement). |
Front / QA web |
| QA iOS & Android | • Test first_open, purchase, parcours complet. • Vérifier que debug_mode est désactivé en prod. |
Mobile QA |
| Quotas évènements | • < 500 noms App. • < 25 paramètres / event. • Aucune alerte « Too many events » dans Admin ▸ Debug. |
Data Lead |
| BigQuery sampling | • Export quotidien activé. • Tables events_YYYYMMDD créées.• Vérifier absence de « sampled = true » dans les requêtes clés. |
Data Engineer |
⚡ Rappels rapides
- Garder un environnement test avec
debug_modepermanent pour reproduire les bugs. - Planifier un audit mensuel des quotas (évènements, utilisateurs, appels BigQuery).
- Documenter chaque nouveau tag / évènement dans le tracking dictionary.
- Automatiser une alerte Insights en cas de chute brutale de revenus ou de sessions.
12. Best practices 2025+
- SDK auto-update• Intégrez Firebase BoM (Android) ou Swift Package Manager (iOS) → correctifs et nouvelles fonctions sans changer de version manuellement.• Activez Gradle version catalog ou Dependabot pour surveiller les releases majeures.
- Predictive metrics GA4• Exploitez les audiences prédictives (achat 7 jours, churn) pour vos campagnes Google Ads, FCM Push ou Meta CAPI.• Ajoutez l’export BigQuery streaming et combinez-le avec Vertex AI pour des modèles maison plus fins (propension, LTV).
- Privacy Sandbox & ATT• Implémentez App Privacy Sandbox (Android 15) : envoyez les events dans l’API Attribution Reporting → moins de perte de signal.• Sur iOS, affichez le prompt ATT au bon moment (post-value pitch) et configurez
Analytics.setConsentpour respecter l’opt-out. - Server-side tagging mobile• Déployez un conteneur sGTM sur Cloud Run + domaine first-party (
stats.votresite.com).• Dans le SDK, pointeztransport_urlvers ce proxy → moins de bloqueurs, contrôle cookie, temps de chargement réduit.
13. Conclusion
En unifiant vos flux Web et App au sein d’une seule propriété GA4, vous obtenez :
- La même vision pour toutes les équipes : développeurs, marketing, data.
- Les mêmes KPIs (installations, revenus, LTV) sans retraitement Excel.
- Des décisions plus rapides grâce aux insights ML et aux rapports cross-device.
Le résultat ? Une croissance unifiée : acquisition optimisée, rétention renforcée, monétisation maximisée — avec une stack de mesure durable, respectueuse de la vie privée et prête pour l’avenir.
FAQ – 10 questions fréquentes
1. Puis-je créer un seul flux pour Android et iOS ?
Non : GA4 exige un flux par plateforme. Gardez-les dans la même propriété pour consolider les rapports et les audiences.
2. Mon app utilise déjà Firebase Analytics ; dois-je migrer ?
Pas de migration technique : activez simplement Google Analytics dans la console Firebase, puis liez le projet à votre propriété GA4.
3. Quelle interface dois-je consulter – Firebase UI ou GA4 UI ?
Développeurs ➡ Firebase (A/B Testing, Remote Config).
Marketers / analystes ➡ GA4 (Explorations, Advertising Hub, e-commerce).
4. Quelle version du SDK dois-je viser ?
Toujours la dernière stable (≥ v11.x en 2025). Utilisez BoM (Android) ou Swift Package Manager (iOS) pour rester à jour automatiquement.
5. Comment éviter de dépasser la limite des 500 noms d’évènements ?
Regroupez les variantes sous un même évènement et passez les différences en paramètres : video_start + video_id, plutôt que video_start_ID123.
6. Puis-je utiliser Google Tag Manager dans une app ?
Oui : utilisez le SDK GTM for Firebase. Gardez néanmoins le SDK Analytics natif pour les évènements critiques et la compatibilité future.
7. Que se passe-t-il côté vie privée (ATT, Privacy Sandbox) ?
Sur iOS, demandez le consentement ATT avant de collecter l’IDFA. Sur Android 15, passez par l’API Attribution Reporting de Privacy Sandbox.
8. Et pour Flutter ou React Native ?
Installez les packages officiels firebase_analytics (Flutter) ou @react-native-firebase/analytics ; les évènements iront dans GA4 sans adaptation.
9. Comment passer d’Universal Analytics for Firebase à GA4 ?
Le SDK est déjà le même. Créez la propriété GA4, liez le projet Firebase et commencez à envoyer les évènements au nouvel ID sans perte de données.
10. Le server-side tagging mobile est-il vraiment utile ?
Oui si vous visez une meilleure performance, moins de blocages par les ad-blockers et un contrôle RGPD accru. Pour les petites apps, commencez côté client puis migrez lorsque le volume ou la conformité l’exige.
Glossaire express des termes techniques rencontrés dans l’article
- GA4 (Google Analytics 4) : nouvelle version de Google Analytics qui suit tous les appareils (Web + App) et utilise un modèle basé sur les évènements.
- Propriété : « compte enfant » dans GA4 qui reçoit les données. Une entreprise peut avoir plusieurs propriétés (par ex. : Europe, US, R-&-D).
- Flux de données (Data Stream) : canal d’entrée (Web, iOS ou Android) branché à une propriété GA4.
- Firebase : plateforme mobile de Google (hébergement, notifications, A/B test). Sert aussi de passerelle pour envoyer les évènements d’app dans GA4.
- SDK : « trousse de développement » à installer dans l’appli pour envoyer automatiquement les évènements.
- Google Tag / gtag.js : petit script JavaScript qui expédie les hits GA4 depuis un site Web.
- Google Tag Manager (GTM) : outil gratuit pour poser ou modifier des balises (GA4, Ads, Meta…) sans toucher au code du site.
- sGTM (Server-side GTM) : version serveur de Tag Manager ; fait transiter les hits via votre domaine pour contourner les bloqueurs et mieux gérer les cookies.
- BigQuery : entrepôt de données Google Cloud qui stocke chaque évènement brut pour des requêtes SQL et du machine-learning.
- BigQuery export : connexion qui envoie, chaque jour (ou quasi temps réel), les évènements GA4 vers BigQuery.
- DebugView : écran temps réel dans GA4/Firebase qui affiche les évènements de votre appareil en mode test.
- Enhanced Measurement : option GA4 qui collecte d’office les pages vues, scrolls, téléchargements, clics sortants, etc., sans code supplémentaire.
- Évènement auto-collecté : évènement envoyé automatiquement par le SDK (ex.
first_open,session_start). - Recommended event : nom d’évènement officiel conseillé par Google (ex.
add_to_cart) qui débloque des rapports prêts à l’emploi. - Paramètre : information complémentaire attachée à un évènement (prix, couleur, ID produit…). GA4 en accepte 25 par évènement.
- Quota 500 noms : limite de 500 noms d’évènements différents côté App pour éviter l’explosion du suivi.
- Funnel : entonnoir qui visualise, étape par étape, la progression des utilisateurs (ex. : vue produit → panier → paiement).
- Pathing : rapport GA4 qui montre le chemin réel suivi avant ou après une action donnée.
- Cohorte : groupe d’utilisateurs partageant un point commun (date d’installation, campagne, etc.) analysé dans le temps.
- LTV (Lifetime Value) : revenu total qu’un utilisateur génère durant tout son cycle de vie.
- Remarketing : technique qui cible de nouveau des visiteurs ou acheteurs passés via des annonces personnalisées.
- FCM (Firebase Cloud Messaging) : service gratuit pour envoyer des notifications push aux apps mobiles.
- Google signals : données cross-device issues des comptes Google de l’utilisateur (activées si celui-ci accepte la personnalisation des annonces).
- User-ID : identifiant propre à votre entreprise (login, ID CRM) qui regroupe les actions d’un même utilisateur sur plusieurs appareils.
- Reporting identity : méthode à « étages » (User-ID → Google signals → device ID) que GA4 utilise pour dé-doubler les utilisateurs.
- Consent Mode v2 : API Google qui adapte la mesure (cookies on/off) et modélise les conversions manquantes lorsque l’utilisateur refuse le suivi.
- Privacy Sandbox : ensemble d’initiatives Google pour remplacer les cookies tiers et limiter le pistage, sur Web (Chrome) et Android.
- ATT / IDFA : cadre Apple ; ATT est le pop-up demandant l’autorisation de suivi, IDFA l’identifiant publicitaire iOS concerné.
- Audiences prédictives : segments automatiques de GA4 (probabilité d’achat, de churn, revenu futur) calculés par l’IA Google.
- ML Insights : alertes et tendances détectées automatiquement par les modèles de machine-learning intégrés à GA4.
- BoM (Bill of Materials) : gestionnaire de dépendances Android qui fixe d’un coup toutes les versions Firebase/Google compatibles.
- Swift Package Manager : équivalent Apple pour ajouter et mettre à jour les librairies dans une app iOS.
- Remote Config : module Firebase qui change à distance l’apparence ou le comportement de l’app, sans re-publication.
- Crashlytics : service Firebase qui remonte les plantages d’une app et les classe par priorité.
- A/B Testing Firebase : outil qui lance des expériences (variantes d’écran, prix, message) auprès de sous-groupes d’utilisateurs.
- Measurement Protocol : interface HTTP qui permet d’envoyer des évènements à GA4 depuis un serveur ou un job back-office.
- ARPU : Average Revenue Per User, c’est-à-dire le revenu moyen par utilisateur.
- Vertex AI : plateforme de machine-learning de Google Cloud pour entraîner et déployer des modèles personnalisés.
- CAPI (Conversions API) : méthode côté serveur pour envoyer les conversions à Meta (Facebook) sans passer par le pixel navigateur.
- Flutter / React Native : frameworks qui créent des apps mobiles multi-plateformes avec un code unique (Dart ou JavaScript).
- Server-side tagging : technique qui fait transiter les hits par votre propre serveur avant de les envoyer à GA4 ou Ads, pour gagner en vitesse et en contrôle.
💡 N’hésitez pas à revenir à ce glossaire lorsque vous croisez un terme obscur : une définition claire vaut mieux qu’un copier-coller de jargon !
