Un événement se déclenche. Il enregistre un achat. Le montant devrait être de 99 $. Mais il enregistre 990 $. Une virgule est mal placée. Ce sont de mauvaises données. Un événement se déclenche. Il devrait capter une catégorie de produit. Mais il ne capte rien. Ce sont des données manquantes. De mauvaises données faussent vos statistiques. Les conclusions sont fausses. Vous décidez à partir de chiffres faux. La qualité des données est essentielle. Chaque événement doit capter des données exactes. Chaque paramètre doit avoir la bonne valeur. Cela demande une configuration soignée et une surveillance continue.
Cet article explique comment faire en sorte que les paramètres d'événements captent des données de qualité.
Pourquoi la qualité des données compte
Les statistiques ne servent que si les données sont exactes. Vous analysez les taux de conversion. Vous optimisez à partir des chiffres. Mais si les chiffres de conversion sont faux, votre optimisation l'est aussi. Vous risquez d'optimiser la mauvaise chose. Vous risquez de rater des occasions.
Les mauvaises données s'accumulent. Une petite erreur sur un événement devient une grosse erreur au total. Si 10 pour cent des événements d'achat ont un montant faux, vos chiffres d'affaires sont faussés de 10 pour cent. C'est une erreur importante pour vos décisions.
La qualité des données crée la confiance. Votre équipe se fie aux statistiques quand les chiffres sont exacts. Elle décide à partir d'eux. Si les données sont peu fiables, elle cesse de leur faire confiance. Elle cesse de les utiliser.
Définir précisément les paramètres d'événements
Avant de créer un événement, définissez ce que doit contenir chaque paramètre. Nom du paramètre. Description du paramètre. Type de données du paramètre. Plage de valeurs attendue. D'où vient la valeur.
Un paramètre de montant d'achat doit être clairement défini. Est-ce le total avec taxes et livraison ? Ou seulement le coût du produit ? Est-il en centimes ou en dollars ? Est-ce du texte ou un nombre ? Définissez-le précisément. La mise en place en dépend.
Documentez chaque paramètre. La documentation évite la confusion. Un développeur qui met en place l'événement sait exactement quoi capter. Un analyste qui lit les données sait ce qu'elles représentent.
Capter les données à la bonne source
La qualité des données dépend de la source où on les capte. Un montant d'achat doit venir de votre système de traitement des commandes. Pas d'une estimation. Pas d'une saisie de l'utilisateur. Le montant réel confirmé.
Une catégorie de produit doit venir de votre base de données produits. Pas de ce que l'utilisateur a saisi. Pas d'une supposition. La catégorie de référence.
Prenez les données au plus près de la source. Les vrais systèmes de transaction connaissent les vrais montants. Les vraies bases de données connaissent la vraie classification. Puisez là. Ne calculez pas et n'estimez pas.
Valider les données avant le déclenchement des événements
Validez les données avant de les envoyer aux statistiques. Vérifiez que le montant de l'achat est un nombre. Vérifiez qu'il est positif. Vérifiez que l'identifiant du produit existe.
La validation attrape les erreurs avant qu'elles deviennent des problèmes de statistiques. Un développeur fait une erreur. La validation l'attrape. Les données n'arrivent jamais aux statistiques. L'événement se déclenche avec de bonnes données.
Les validations courantes comprennent le contrôle du type (texte, nombre ou date), le contrôle de plage (dans les valeurs attendues) et le contrôle d'existence (l'élément référencé existe-t-il).
Utiliser des noms de paramètres cohérents
Le nom des paramètres compte. Si un événement appelle un paramètre « amount » et un autre « purchase_amount », vos rapports les traitent comme deux paramètres différents. Vous ne pouvez pas les comparer.
Créez une norme de nommage. Toutes les valeurs monétaires utilisent le suffixe « _amount ». Tous les identifiants utilisent le suffixe « _id ». Tous les comptages utilisent le suffixe « _count ». Appliquez cette norme de façon cohérente.
Une fois un paramètre nommé, ne le changez plus. Changer le nom d'un paramètre sépare vos données. Les anciennes données sont sous l'ancien nom. Les nouvelles sont sous le nouveau. Les rapports montrent des données scindées. Soignez le nommage avant de déployer.
Gérer les cas limites et les données manquantes
Certaines données sont difficiles à capter. Transactions hors ligne. Transactions d'anciens systèmes. Informations utilisateur incomplètes. Comment gérer les données manquantes ?
N'envoyez jamais d'événements auxquels il manque des paramètres essentiels. Si vous ne pouvez pas obtenir le montant de l'achat, ne déclenchez pas l'événement d'achat. N'envoyez l'événement que lorsque vous avez des données complètes.
Pour les données facultatives, utilisez toujours la même valeur vide (null ou chaîne vide). N'écrivez pas « unknown » à un endroit et « N/A » à un autre. Un traitement cohérent des données manquantes facilite l'analyse.
Surveiller la qualité des données dans le temps
La qualité des données se dégrade avec le temps. Les intégrations cassent. Les systèmes changent. Ce qui marchait le mois dernier peut casser ce mois-ci. Surveillez en continu.
Cherchez les anomalies. Des valeurs nulles là où il ne devrait pas y en avoir. Des montants aberrants. Des paramètres manquants. Mettez en place des alertes. Si quelque chose semble anormal, enquêtez.
Consultez régulièrement les rapports de qualité des données. La plupart des outils de statistiques en proposent. Utilisez-les. Repérez les problèmes tôt.
Questions fréquentes
Comment tester si les paramètres d'événements captent correctement ?
Utilisez les rapports en temps réel. Faites l'action. Regardez le rapport. Vérifiez que l'événement apparaît avec les bons paramètres et les bonnes valeurs. Utilisez les outils de développement du navigateur. Inspectez les données avant leur envoi aux statistiques. Vérifiez qu'elles correspondent aux attentes. Avec le créateur de site web de WEMASY, vous pouvez le configurer directement sur votre site.
Que faire si la valeur d'un paramètre est toujours vide ?
Les données ne sont pas captées. Vérifiez votre mise en place. Le paramètre est-il bien configuré ? Les données sont-elles disponibles au moment où l'événement se déclenche ? Y a-t-il un problème de timing ? Déboguez la source. N'envoyez pas de données vides. Réglez la cause.
Peut-on renommer un paramètre après la collecte des données ?
Techniquement oui, mais évitez. Les anciennes données restent sous l'ancien nom. Les nouvelles vont sous le nouveau. Vos rapports montrent des données scindées. Choisissez le bon nom dès le départ. Si vous devez renommer, prévoyez la scission des données.
Comment gérer la devise dans les paramètres d'événements ?
Captez séparément le montant numérique et le code de la devise. Le montant dans un paramètre comme « purchase_amount ». La devise dans un paramètre comme « currency_code » avec des valeurs comme « USD » ou « EUR ». Cela permet d'analyser entre devises.
Faut-il stocker des données brutes ou mises en forme dans les paramètres ?
Stockez des données brutes. Montants en centimes et non en dollars. Horodatages au format ISO et non lisibles par un humain. Les données mises en forme sont plus difficiles à analyser et à comparer. Les données brutes sont plus flexibles. Mettez-les en forme dans les rapports si nécessaire.
Quel taux d'erreur est raisonnable pour les données d'événements ?
L'objectif est zéro. Mais en pratique, moins de 1 pour cent est acceptable. Certains cas limites poseront problème. Des anciens systèmes n'auront peut-être pas les données. Mais si le taux d'erreur dépasse 1 à 2 pour cent, enquêtez et réglez la cause.