La première fois que j'ouvre Google Analytics 4 pour un client, je vois toujours la même hésitation : l'interface ne ressemble à rien de ce que les gens connaissaient sur Universal Analytics, et la majorité des tutoriels trouvés en ligne datent d'avant la bascule. Depuis l'arrêt du traitement des données sur Universal Analytics au 1er juillet 2023, GA4 est la seule option disponible, et mal le configurer au démarrage coûte des mois de données inexploitables. Avant les rapports, imprime la checklist de configuration en 12 points plus bas, elle t'évite les pièges classiques des premiers réglages.
Créer et configurer sa propriété GA4
Je commence toujours par un compte Google Analytics dédié à l'activité, jamais un compte Gmail personnel partagé avec d'autres usages. Dans ce compte, je crée une propriété GA4 en renseignant le bon fuseau horaire et la bonne devise dès le départ : ces deux paramètres ne se corrigent pas rétroactivement sur les données déjà collectées.
L'étape suivante consiste à ajouter un flux de données web, qui génère l'identifiant de mesure au format G-XXXXXXX. Je pose ensuite le tag via Google Tag Manager plutôt que d'insérer le script gtag.js en dur dans le code : ça me laisse la main pour ajouter des événements personnalisés plus tard sans retoucher au thème ou au template.
Un réglage que je change systématiquement à la création : la rétention des données, fixée à 2 mois par défaut, que je pousse immédiatement à 14 mois dans les paramètres de propriété. Ce changement n'est pas rétroactif, alors autant le faire avant la première visite enregistrée.
Checklist de configuration GA4 à imprimer (12 points)
Je reprends cette liste à chaque nouvelle propriété, dans l'ordre, pour ne rien oublier avant de laisser tourner le suivi :
- Compte dédié : un compte Google Analytics propre à l'activité, séparé de tout usage personnel.
- Fuseau horaire et devise : réglés dès la création de la propriété, non modifiables rétroactivement.
- Flux de données web : créé et identifiant de mesure (G-XXXXXXX) récupéré.
- Installation via Google Tag Manager : plus souple qu'un gtag.js codé en dur pour la suite.
- Rétention des données à 14 mois : changée immédiatement, jamais laissée sur les 2 mois par défaut.
- Key events définis : 2 à 3 actions qui comptent vraiment, marquées comme telles.
- Trafic interne exclu : filtre IP ou tag de session pour ne pas polluer les rapports.
- Suivi cross-domain activé : si tunnel de paiement ou sous-domaine séparé du site principal.
- Search Console relié : connexion faite dans les paramètres d'acquisition de la propriété.
- Groupes de canaux vérifiés : attribution par défaut (data-driven) contrôlée une première fois.
- Audience "utilisateurs engagés" : créée pour isoler le trafic qualifié des rapports globaux.
- Test en temps réel : vérification que les événements automatiques (page_view, scroll, click) remontent bien.
Comprendre les rapports essentiels de GA4
Le rapport Temps réel confirme que le tag capte bien les visites, mais je ne m'y attarde pas plus de quelques minutes après une mise en ligne. C'est le rapport Acquisition qui m'intéresse ensuite : il montre par quel canal (organique, direct, référent, réseaux sociaux) les visiteurs arrivent, avec un regroupement par défaut parfois trop large pour être exploitable sans ajustement.
Le rapport Engagement remplace l'ancien taux de rebond d'Universal Analytics par des métriques comme la durée d'engagement moyenne et le taux d'engagement, calculées différemment : une session est jugée engagée dès qu'elle dépasse 10 secondes, comporte un événement de conversion ou au moins deux pages vues. Cette logique change complètement la lecture des performances par rapport à l'ancien modèle basé sur les sessions et le rebond.
Ces données alimentent directement mon travail lors d'un audit SEO : sans elles, toute analyse de positionnement ou de comportement utilisateur reste partielle.
Configurer les événements et les key events
GA4 capte automatiquement une dizaine d'événements dès l'installation du tag : page_view, scroll, click sortant, session_start, first_visit. Ça donne une base, mais pas de quoi mesurer ce qui compte réellement pour un site (formulaire envoyé, appel cliqué, panier validé).
Pour ces actions, je crée des événements personnalisés via Google Tag Manager, puis je les marque comme "key events" dans les paramètres GA4, terme qui a remplacé "conversions" en 2024 pour éviter la confusion avec les conversions Google Ads. Concrètement, n'importe quel événement peut devenir un key event si tu le désignes comme tel : pas besoin de code supplémentaire, juste un interrupteur à activer dans l'interface une fois l'événement remonté au moins une fois.
Je limite volontairement le nombre de key events à 2 ou 3 par propriété. Au-delà, les rapports de conversion deviennent illisibles et personne ne les consulte plus. Avant de lancer cette étape, je m'appuie sur ma propre checklist d'audit SEO, qui couvre aussi les points techniques à vérifier avant de considérer un suivi comme fiable.
Relier GA4 à tes autres outils
Une fois la propriété stable, je connecte GA4 à Search Console dans les paramètres d'acquisition : ça fait apparaître les requêtes de recherche organique directement dans les rapports d'audience, sans jongler entre deux outils. C'est aussi ce croisement qui me permet de repérer les pages qui reçoivent des clics mais génèrent peu d'engagement une fois l'utilisateur arrivé dessus.
Les key events que tu configures ici servent aussi de base quand j'estime la rentabilité d'un projet côté client, avec mon calculateur de ROI automatisation : sans données de conversion fiables en amont, toute estimation de retour sur investissement reste approximative.
Une propriété GA4 bien réglée dès le départ, avec la rétention étendue et les bons key events, tient sur cette seule checklist et évite de perdre des mois de données exploitables faute d'avoir coché les bonnes cases au lancement.
