DebugView

Parce que les rapports GA4 mettent du temps à se remplir et agrègent tout.

Un événement mal nommé, un paramètre absent, une valeur vide n’apparaissent pas comme des erreurs dans un rapport : ils produisent une ligne un peu fausse que personne ne remarque avant des semaines.

DebugView montre l’événement au moment où il part, avec son nom exact et le contenu de chaque paramètre. C’est la seule façon de vérifier avant publication.

Trois méthodes selon le contexte.

Le mode aperçu de Google Tag Manager. En activant l’aperçu, la session bascule automatiquement en débogage. C’est la méthode habituelle pendant le paramétrage.

L’extension de débogage Google Analytics, pour un site sans gestionnaire de balises.

Le paramètre de débogage envoyé avec l’événement, utile pour tester depuis un environnement de préproduction ou une application.

Seuls les appareils en mode débogage apparaissent, ce qui évite d’être noyé par le trafic réel.

Quatre points, dans cet ordre.

Le nom de l’événement. Une faute de frappe crée un événement distinct qui n’alimente rien. C’est l’erreur la plus fréquente et la plus silencieuse.

Les paramètres et leurs valeurs. Un paramètre présent mais vide est aussi inutile qu’un paramètre absent.

Le déclenchement. L’événement part-il au bon moment, une seule fois. Un envoi au chargement de page plutôt qu’à l’action réelle gonfle les chiffres, et un double envoi les double.

L’état du consentement. Les signaux du Consent Mode sont visibles, ce qui permet de vérifier qu’ils passent bien de refusé à accordé après le clic.

Il ne montre que les appareils en débogage : il ne dit rien de ce qui se passe sur le trafic réel.

Il ne détecte pas les événements manquants. Un événement jamais déclenché n’apparaît nulle part, et seule une liste de ce qui devrait exister permet de le voir.

Et il ne remplace pas une vérification dans les rapports quelques jours plus tard, où apparaissent les problèmes de volume et de cohérence.