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 qui rapportent de l’argent — une vente, un prospect, une inscription — sont les seuls de cette page que rien n’envoie automatiquement. GA4 définit leurs noms et leur forme ; votre site doit pousser chacun dans le dataLayer, exactement sous ce nom, au moment où il se produit.

Chaque conteneur SignalHost tient prêts un déclencheur et une balise d’événement GA4 pour seize d’entre eux :

• Neuf pour le tunnel d’achat d’une boutique : view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info et purchase, chacun avec un objet ecommerce attaché.
• Cinq pour les prospects : generate_lead, contact, schedule, submit_application et subscribe.
• Deux pour les inscriptions : sign_up et start_trial.

Un thème Shopify standard n’en pousse aucun, pas plus que le cœur de WooCommerce : 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. À l’instant où votre site en pousse un, la balise est là pour le transmettre — le push, c’est à vous de l’organiser, et l’article sur Shopify et WooCommerce décrit exactement quoi installer.

Le bouton « Événements pris en charge » de la carte « Événements » de votre conteneur les liste tous, avec ce que chacun signifie et ce qu’il faut pousser. Si votre conteneur envoie déjà l’un d’eux à GA4 avec une balise à vous, SignalHost laisse cet événement à votre balise plutôt que de le compter deux fois.

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 choses empêcheront toujours les deux listes de coïncider exactement. Un visiteur qui n’a pas répondu à votre bannière envoie quand même chaque événement, sous forme de ping sans cookie, et le conteneur le compte tandis qu’Analytics l’écarte — la page affiche les deux chiffres pour que vous voyiez lequel est lequel. Et session_start et first_visit n’apparaissent jamais sur la page du conteneur : le navigateur ne les envoie pas comme événements, il pose deux drapeaux sur le premier page_view, et Analytics fabrique les événements de son côté.

Au-dessus de la liste, la carte compte combien de ces seize événements sont arrivés au cours des 30 derniers jours, si bien que celui que votre site a oublié d’envoyer saute aux yeux.

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 l’un des seize, 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.

Vous partez de zéro ? Configurer Google Tag Manager côté serveur, étape par étape.