Tous les événements GA4 que voit votre conteneur serveur, et d’où vient chacun

Dès que la balise Google se charge avec votre ID de mesure, quatre événements circulent sans aucun réglage derrière. Rien dans Analytics ne les désactive, et rien dans votre conteneur n’a besoin de les demander.

• page_view — un par chargement de page, ou par changement de route dans une application monopage lorsque l’option « modifications de page » du flux est activée.
• session_start — le premier hit d’une nouvelle session. Une session se termine après trente minutes d’inactivité ; un visiteur qui revient deux heures plus tard en démarre une autre.
• first_visit — une fois par navigateur, lors de la toute première session que GA4 en a vue. Effacer les cookies en produit un nouveau.
• user_engagement — envoyé quand la page est restée au premier plan dix secondes, ou quand le visiteur part après avoir interagi. C’est de là que vient la durée d’engagement de GA4.

Si vous voyez page_view et rien d’autre, la balise fonctionne. Ce n’est pas une panne ; c’est un site dont personne n’a encore atteint le bas de page.

La mesure améliorée de GA4 collecte neuf événements de plus dans le navigateur, sans balise pour aucun d’eux. Ils se configurent sur le flux de données, pas dans Tag Manager, et c’est pourquoi un conteneur serveur les transmet sans savoir qu’ils existent.

Chacun a une condition plus stricte que son nom ne le laisse penser.

• scroll — une fois par page, et seulement quand 90 % de la hauteur de la page a été visible. Pas à n’importe quel défilement : en atteignant le bas. Une page plus courte que la fenêtre ne le déclenche jamais.
• click — un clic sortant, vers un domaine autre que le domaine courant. Les liens internes ne comptent pas. L’événement s’appelle click, avec un paramètre outbound ; il n’existe pas d’outbound_click.
• view_search_results — un chargement de page dont l’URL porte un paramètre de recherche (q, s, search, query ou keyword par défaut).
• file_download — un clic sur un lien se terminant par une extension de document, d’archive, d’audio, de vidéo ou de tableur.
• form_start et form_submit — la première interaction avec un formulaire de la page, et son envoi.
• video_start, video_progress et video_complete — pour les lecteurs YouTube intégrés uniquement, et seulement si l’intégration a l’API JS activée.

Voici la partie qui coûte des semaines. Chacun de ces neuf dépend de l’interrupteur principal de mesure améliorée du flux, et un flux créé via l’API d’administration Analytics — plutôt que dans l’interface Analytics — a cet interrupteur sur OFF. Lisez les paramètres via l’API et chaque option individuelle répond true ; l’interrupteur principal est simplement absent de la réponse, parce qu’il est false et que l’API omet les booléens faux. La configuration paraît donc entièrement activée et ne livre que page_view.

Nous l’avons découvert sur notre propre propriété. SignalHost active l’interrupteur principal lorsqu’il crée une propriété pour vous ; si la vôtre a été créée autrement et que scroll n’arrive jamais, ouvrez le flux de données dans Analytics et vérifiez « Mesure améliorée » elle-même, pas les options en dessous.

Les événements commerce — view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info et purchase — sont ceux qui comptent vraiment pour une boutique, et les seuls de cette page que rien n’envoie automatiquement. GA4 définit les noms et la forme ; votre site doit pousser chacun dans le dataLayer, exactement sous ce nom, avec un objet ecommerce attaché.

Un thème Shopify standard ne le fait pas. Le cœur de WooCommerce ne le fait pas. Une application ou un plugin dataLayer le fait, et sur Shopify les événements de paiement exigent un Custom Pixel, parce que le conteneur du thème ne se charge jamais sur les pages de paiement. Quand vous choisissez une plateforme de boutique dans l’assistant SignalHost, nous installons un déclencheur et une balise d’événement GA4 pour chacun des sept, de sorte qu’à l’instant où votre site pousse purchase, l’événement est transmis — mais le push, c’est à vous de l’organiser. L’article suivant décrit exactement quoi installer.

Chaque requête de mesure qui traverse votre conteneur est comptée par nom d’événement, par jour, pendant 400 jours. Seul le nom est conservé — ni l’URL, ni l’identifiant client, pas un seul paramètre — et c’est ce qui rend sûr de le garder aussi longtemps. La liste est ce qui est arrivé à votre nom d’hôte ; elle répond donc à une question qu’Analytics lui-même ne peut pas trancher : le navigateur l’a-t-il seulement envoyé ?

Attendez-vous à des comptes inégaux. Chaque chargement de page est un page_view ; seuls les chargements qui atteignent le bas sont un scroll ; seules les sessions qui dépassent dix secondes sont un user_engagement. Un site avec dix pages vues et deux scrolls est un site normal.

Deux cas, et la page du conteneur les distingue.

Si l’événement n’est pas dans la liste du conteneur, votre site ne l’a jamais envoyé. Le conteneur ne peut pas transmettre ce qui n’est pas arrivé. Pour un événement standard, vérifiez l’interrupteur de mesure améliorée du flux ; pour un événement commerce, vérifiez que le push dataLayer a lieu, avec le bon nom, sur la page où il devrait.

Si l’événement est dans la liste du conteneur mais pas dans Analytics, il est arrivé et a été transmis, et le problème est du côté Google de la ligne : mauvais ID de mesure, filtre de données, propriété dans un autre compte que celui que vous regardez, ou simplement le délai des rapports — le temps réel l’affiche en quelques secondes, les rapports standard peuvent prendre une journée.