GA4, GTM et data layerVérifié à chaque étapeSans écrire de code
Un événement qui ne part plus, une valeur d’achat à zéro, un identifiant produit qui change de format. Le plan de taggage casse en silence, et l’erreur ne se voit que des semaines plus tard, dans un chiffre qui ne colle pas.
C’est ce qui le rend dangereux. Le site fonctionne parfaitement, les clients achètent, personne ne remonte quoi que ce soit. Pendant ce temps l’événement d’achat part sans montant, et vous pilotez vos budgets publicitaires sur un chiffre faux. Le défaut se découvre en fin de mois, quand il est trop tard pour rattraper la donnée perdue.
Le scénario suit le parcours et vérifie qu’à chaque étape l’événement attendu est bien poussé, une fois et une seule.
Identifiant produit, montant, devise, quantité. Un événement qui part avec une valeur vide est aussi grave qu’un événement absent.
Ce qui se déclenche avant et après le choix de l’utilisateur. Un tag qui part malgré un refus est un sujet de conformité.
Le plan de taggage est vérifié comme le reste, pas une fois par an lors d’un audit.
“ Avec Mr Suricate, nous avons automatisé la vérification des étiquettes, sécuriser nos données et gagné en fiabilité pour prendre des décisions stratégiques sans erreur. En plus, c'est amusant ! ”
Xavier ValetHead of Data Analytics, HelloWork
ALLER PLUS LOIN
Quinze types de tests, quatre familles. Chacun répond à une question différente sur votre application.
Un terme vous échappe ? Le glossaire du test automatisé le définit.
VOS QUESTIONS
Ce qu'on nous demande le plus souvent sur le contrôle du taggage.
C'est un scénario qui joue un parcours utilisateur et vérifie, à chaque étape, les événements poussés dans la couche de données du site. Il contrôle la présence de l'événement, son nom et le contenu de ses paramètres.
Oui. Le contrôle porte sur ce que votre site pousse effectivement dans le data layer, ce qui est la source de ce que reçoivent GTM puis GA4. C'est le bon niveau : on vérifie l'émission, pas l'affichage dans l'outil de destination.
Oui, et c'est un des cas les plus utiles. Le scénario peut refuser les cookies puis vérifier qu'aucun tag de mesure ne part, et faire l'inverse après acceptation. C'est un contrôle de conformité autant que de qualité de la donnée.
À chaque mise en production, au même titre que la non-régression. Un plan de taggage se casse le plus souvent à l'occasion d'une évolution du site qui n'avait rien à voir avec la mesure, donc en dehors de toute vigilance de l'équipe data.
Non. Le parcours se construit comme n'importe quel scénario, et les contrôles d'événement s'ajoutent aux étapes concernées. Le travail préalable est éditorial plutôt que technique : il faut savoir quel événement doit partir, et avec quelles valeurs.
Une démo de 30 minutes sur votre propre application. Vous verrez un de vos parcours automatisé en direct, sans écrire de code.