Suivre les soumissions de formulaires Elementor avec Google Analytics 4 semble, sur le papier, relativement simple. Il suffirait d’activer la mesure améliorée, de connecter Google Tag Manager, puis de constater l’apparition des événements dans GA4. Dans la réalité, les choses sont rarement aussi linéaires.
Très souvent, on observe des comportements ambigus : des événements qui apparaissent en double, des conversions incohérentes, ou des écarts entre ce que montre GTM et ce que GA4 finit par enregistrer. Ces écarts ne sont pas dus à une mauvaise configuration isolée, mais à une mauvaise compréhension de la manière dont GA4 et GTM interprètent les interactions côté navigateur.
L’objectif de cet article est de poser une lecture claire de ce qui se passe réellement lorsqu’un utilisateur soumet un formulaire Elementor, puis de montrer comment obtenir un tracking propre, reproductible et fiable, sans bricolage fragile.
Comprendre ce que GA4 observe réellement lors d’une soumission de formulaire
GA4 repose sur un modèle entièrement événementiel. Contrairement à Universal Analytics, il n’existe plus de notion de “hit” ou de “type de page” : tout est un événement, enrichi de paramètres.
Lorsque la mesure améliorée (« Enhanced measurement« ) est activée sur un flux web, GA4 tente de détecter automatiquement certaines interactions, dont les soumissions de formulaire. Cette détection repose sur l’observation du DOM et de signaux JavaScript standards, sans connaissance du framework utilisé par le site.
Autrement dit, GA4 ne sait pas ce qu’est Elementor. Il observe simplement qu’un formulaire a déclenché un comportement assimilable à une soumission.
C’est ici que les choses se compliquent.
Les formulaires Elementor fonctionnent en AJAX, sans rechargement de page. Ils déclenchent plusieurs signaux successifs : événements internes, callbacks JavaScript, mises à jour du DOM. Du point de vue du navigateur, plusieurs événements distincts peuvent donc correspondre à une seule action utilisateur.
C’est exactement ce que l’on observe dans le mode Preview de Google Tag Manager.
Ce que montre réellement le mode Preview de GTM
Lorsque l’on ouvre le mode Preview et que l’on soumet un formulaire Elementor, on observe souvent deux événements form_submit, avec un horodatage identique mais un priorityId différent.
Ces deux événements ne correspondent pas à deux soumissions utilisateur. Ils représentent deux passages successifs dans la chaîne d’exécution interne de GTM. Le navigateur émet un signal, puis GTM le traite à deux niveaux différents de priorité.
C’est un point fondamental : ce doublon n’est pas une erreur de tracking, c’est un artefact du moteur d’exécution.
C’est également pour cette raison que GA4, de son côté, ne crée généralement qu’un seul événement final. GA4 applique une normalisation et un regroupement logique des signaux entrants. Mais GTM, lui, vous montre tout.
Sans filtrage, cette différence de comportement peut rapidement mener à des implémentations instables, surtout lorsque l’on commence à créer des événements personnalisés comme generate_lead.
Pourquoi filtrer côté GTM et non côté GA4
À ce stade, deux approches sont possibles. Soit on laisse GA4 faire le tri, soit on décide de maîtriser ce qui est envoyé en amont.
La seconde approche est nettement plus saine.
Filtrer côté GTM permet de contrôler précisément ce qui déclenche un événement métier, d’éviter les doublons, et de garantir que chaque soumission utilisateur correspond à un seul événement exploitable.
C’est ici qu’intervient l’utilisation du gtm.priorityId.
Chaque événement traité par GTM se voit attribuer un identifiant incrémental. En pratique, lors d’une soumission Elementor, deux événements successifs partagent la même structure mais pas le même priorityId. Il devient alors possible de filtrer proprement l’un des deux.
La logique utilisée est volontairement simple : ne conserver qu’un événement sur deux, en se basant sur la parité du priorityId. Cette approche n’est pas un contournement fragile, mais une exploitation directe du fonctionnement interne documenté de GTM.
Mise en place concrète du filtrage
Une variable JavaScript personnalisée permet de réaliser ce filtrage proprement. Elle vérifie si la valeur du gtm.priorityId est paire, et retourne un booléen exploitable comme condition de déclenchement.
Cette variable devient alors un garde-fou. Elle ne décide pas de ce qu’est un formulaire, mais uniquement si l’événement courant doit être considéré comme valide.
Le déclencheur associé écoute l’événement form_submit, mais ne s’active que lorsque cette condition est vraie. On obtient ainsi un seul déclenchement logique par interaction réelle.
Construction de l’événement métier
À partir de ce point, on peut créer un événement GA4 propre, lisible et orienté métier. Dans cet exemple, il s’agit de generate_lead.
Les paramètres envoyés ne sont pas décoratifs. Ils correspondent à des données utiles pour l’analyse : identifiant du formulaire, nom du formulaire, URL de destination. Ces informations proviennent directement du eventModel exposé par GTM, ce qui garantit leur cohérence avec ce qui s’est réellement produit dans le navigateur.
On ne transmet donc pas une interprétation, mais un état observé.
C’est cette distinction qui rend le tracking robuste.
Validation dans GTM et dans GA4
Dans le mode Preview de GTM, on observe désormais deux événements form_submit, mais un seul déclenchement du tag generate_lead. C’est exactement le comportement attendu.
Dans GA4, via DebugView, un seul événement generate_lead apparaît, même si le flux montre plusieurs signaux techniques en amont. L’événement est propre, unique et exploitable pour des conversions, des audiences ou des analyses de parcours.
C’est ici que l’on comprend la différence fondamentale entre ce que voit GTM et ce que consomme GA4.
Pourquoi GA4 ne montre qu’un seul événement
GA4 applique une logique de normalisation et de déduplication. Lorsqu’il reçoit plusieurs signaux quasi simultanés représentant la même interaction, il les consolide.
Cela explique pourquoi certains voient des doublons dans GTM mais pas dans GA4, et inversement pourquoi certains setups “semblent fonctionner” alors qu’ils reposent sur une configuration fragile.
En maîtrisant le flux en amont, on ne dépend plus de cette normalisation implicite.
Ce que cette approche apporte réellement
Cette méthode permet de construire un tracking stable, lisible et maintenable. Elle évite les faux positifs, simplifie les analyses et rend les données exploitables dans le temps, y compris lorsque le site évolue ou que de nouveaux formulaires sont ajoutés.
Elle permet aussi de travailler sereinement avec Google Ads, des conversions importées ou des logiques d’attribution plus avancées, sans risquer de fausser les volumes.
En résumé
Le suivi des formulaires Elementor n’est pas complexe, mais il exige de comprendre comment GA4 et GTM interprètent les événements, plutôt que de simplement empiler des déclencheurs.
Une fois cette mécanique comprise, le tracking devient prévisible, documentable et robuste. C’est précisément ce qui distingue une implémentation fonctionnelle d’une implémentation fiable.
Si vous cherchez à sécuriser vos conversions, à fiabiliser vos données ou à industrialiser votre tracking sur plusieurs sites, cette approche constitue une base saine et durable.
Références
- Google Analytics 4 – Événements recommandés
https://support.google.com/analytics/answer/9267735 - DebugView – GA4
https://support.google.com/analytics/answer/7201382
