La vue Trust : comment lire la qualité de votre tracking

La vue Trust se trouve dans votre tableau de bord par domaine et donne une mesure honnête de la part de votre tracking effectivement capturée. Elle s'exécute quotidiennement et compare trois signaux — le tracker du navigateur, l'ingestion côté serveur et la vérité des webhooks — pour estimer les écarts et expliquer leur origine probable.

Ce guide explique comment lire la vue et ce qu'il faut faire quand quelque chose mérite d'être investigué.

Où la trouver

Dans app.zenovay.com, ouvrez n'importe quel tableau de bord de domaine et sélectionnez l'onglet Trust du groupe Reliability dans la barre latérale (il se trouve à /domains/{id}?tab=trust). La vue affiche les résultats de réconciliation des 7 derniers jours.

Si le site est tout neuf, vous verrez peut-être un état vide convivial. La première ligne de réconciliation apparaît dans les 24 heures suivant l'activité (le job quotidien tourne à 00:00 UTC).

Le chiffre principal

En haut, vous verrez un grand pourcentage intitulé « perte de tracking estimée » accompagné d'une puce de confiance :

• Pourcentage positif (par ex. 8,4 %) — votre tracker navigateur enregistre moins d'événements que ne le suggèrent la couche serveur ou la couche webhook. Une certaine perte est normale ; le détail ci-dessous explique pourquoi.
• Pourcentage négatif / « +X % sur-comptés » — votre serveur enregistre plus d'événements que votre tracker navigateur. Ce n'est pas un bug ; cela signifie généralement que l'ingestion côté serveur a capté des événements que les bloqueurs de publicités ou les pertes réseau auraient perdus.
• — (tiret cadratin) — il n'y a pas encore assez de données comparables, généralement parce que la couche serveur ou webhook est vide pour ce site.

Sous le pourcentage se trouve une barre de complétude. La section émeraude pleine montre les événements qui correspondent entre couches. La section ambre hachurée montre l'écart estimé.

Étiquettes de confiance

Chaque métrique porte l'une de trois étiquettes :

Puce	Signification
Confiance élevée ●●●	Les deux couches ont ≥100 événements et la perte est inférieure à 30 %. Le chiffre est fiable.
Confiance moyenne ●●○	Une couche est dans la plage 50–100 événements, ou la perte est entre 30 % et 60 %. Traitez le chiffre comme indicatif.
Données limitées ●○○	Une ou deux couches ont moins de 50 événements, ou la perte dépasse 60 %. La vue dit ce qu'elle voit, mais n'agissez pas sur ce seul chiffre.

La confiance n'est pas la sévérité. Une perte de 5 % à confiance élevée est plus utile qu'une perte de 80 % à confiance limitée.

Lire la ventilation par métrique

Trois lignes sous le chiffre principal montrent la même comparaison appliquée séparément aux pages vues, aux conversions d'objectifs et aux événements de revenus. Chaque ligne porte sa propre étiquette de confiance et trois colonnes (client / serveur / webhook), plus une barre de complétude.

Quelques motifs courants :

• Pages vues : client et serveur devraient être proches. Un écart persistant indique souvent des bloqueurs de publicités ou des règles CSP qui bloquent silencieusement le tracker sur certaines pages.
• Objectifs : les écarts sont souvent légitimes — le visiteur ferme l'onglet entre l'événement client et la confirmation côté serveur. Surveillez plus le trend qu'un pourcentage isolé.
• Revenus : la couche webhook est la source de vérité (c'est ce qui a effectivement débité le client). Un écart signifie généralement soit que les événements d'achat client ne se déclenchent pas à chaque paiement réussi, soit que les livraisons de webhooks sont retardées.

Si vous voyez sur une ligne un petit message du type « Ingestion côté serveur pas encore en place », cela signifie que la couche de vérité pour cette métrique est vide. La réconciliation montrera quelque chose (Trust utilise la couche existante), mais avec une confiance faible.

Principales raisons de mismatch

Sous la ventilation par métrique, Trust classe les principales raisons suspectées, triées par nombre d'événements affectés cette semaine.

Trois raisons sont marquées Actionnable avec un petit tag ambre. Pour celles-ci, les plans Pro et plus voient une étape d'action en une ligne. Les autres sont diagnostiques — elles expliquent ce qui se passe sans exiger d'action de votre part.

Raisons actionnables et que faire

Tracker client probablement bloqué (client_blocked)

• Ce qu'on a vu : les comptes côté serveur étaient nettement plus élevés que les comptes navigateur pour au moins une métrique.
• Cause probable : un bloqueur de publicités, une extension de confidentialité de navigateur ou votre propre en-tête Content-Security-Policy bloque le tracker sur certaines visites.
• Ce qu'il faut essayer : ajoutez api.zenovay.com à votre directive CSP connect-src. Si vous utilisez une CSP plus stricte avec script-src, ajoutez-le aussi là. Pour les pertes liées aux extensions de confidentialité, envisagez le tracking first-party afin que le tracker se charge depuis votre propre domaine.

Livraison webhook retardée (webhook_delay)

• Ce qu'on a vu : les événements d'achat côté client devançaient les arrivées de webhooks ET le compte de webhooks d'aujourd'hui est tombé bien en dessous de la moyenne sur 6 jours.
• Cause probable : votre fournisseur de paiement (généralement Stripe) n'a pas encore livré certains webhooks. Cela se résout souvent tout seul en quelques heures.
• Ce qu'il faut essayer : ouvrez le tableau de bord de livraison des webhooks de votre fournisseur et cherchez les webhooks en échec ou en attente. Si vous voyez des relances, l'écart devrait se combler à mesure qu'elles arrivent. Si les webhooks échouent complètement, vérifiez que votre endpoint est joignable et renvoie des réponses 2xx.

Mismatch de normalisation de route (route_mapping)

• Ce qu'on a vu : 1 à 2 routes spécifiques représentent plus de la moitié de l'écart.
• Cause probable : ces routes sont normalisées différemment entre le tracker navigateur et le serveur. Cas fréquent : une route SPA que le tracker rapporte comme /checkout/abc123 mais que le serveur enregistre comme /checkout/[id].
• Ce qu'il faut essayer : revoyez la gestion des routes SPA de votre tracker pour les URL concernées. La table drilldown Pro+ montre exactement quelles routes contribuent à l'écart.

Raisons diagnostiques (aucune action requise)

• Doublons supprimés — le pipeline d'ingestion a détecté des événements navigateur en doublon avec la même clé d'idempotence et n'en a gardé qu'un. Comportement correct.
• Lacunes d'identité visiteur — l'identifiant navigateur d'un visiteur ne correspondait pas proprement à travers les événements enregistrés côté serveur. Fréquent quand le visiteur a effacé ses cookies en cours de session.
• Ingestion côté serveur pas en place — vous n'avez pas encore commencé à envoyer les événements côté serveur à POST https://api.zenovay.com/e/{trackingCode}. La réconciliation côté serveur n'est pas possible sans cela. Voir Événements côté serveur pour la configuration.
• Aucune cause dominante identifiée — l'écart est sous le seuil de toute raison spécifique. Souvent, cela signifie simplement que votre tracking est en bonne santé.

La table drilldown Pro+

Si votre plan est Pro ou supérieur, vous verrez en bas une table Écart par route listant les plus grandes différences entre comptes client et serveur sur une seule route cette semaine, classées par écart en événements.

C'est la partie la plus actionnable de la vue : elle vous dit exactement où regarder. Quelques exemples :

• Une seule page de détail produit qui représente l'essentiel de l'écart de pages vues → vérifiez si cette page a une règle CSP, un script inline personnalisé ou une mise en page testée en A/B qui casse le tracker.
• Une route /checkout qui n'apparaît que côté serveur → votre tracker côté client n'est peut-être pas installé sur la page de checkout (omission fréquente avec les flux de paiement isolés).
• Un motif /blog/[slug] avec des centaines de routes contribuant chacune 1 à 2 événements → attendu ; à ignorer.

Foire aux questions

L'onglet Trust dit que je perds 12 % des pages vues. Devrais-je m'inquiéter ?

Pas nécessairement. Les références sectorielles pour l'analytics basée sur navigateur situent la perte due aux bloqueurs entre 20 % et 40 % dans certains secteurs. Une perte mesurée de 12 % avec une comparaison serveur réelle est bien meilleure que la perte non mesurée d'un outil d'analytics typique. La vraie question est de savoir si l'écart est concentré sur des routes spécifiques (réparable) ou réparti uniformément (coût d'exploitation).

Pourquoi mon chiffre montre-t-il « +5 % sur-comptés » ?

Votre serveur a capturé plus d'événements que votre tracker navigateur. C'est une bonne nouvelle — l'ingestion côté serveur comble des écarts que votre tracker aurait manqués. Le « + » indique clairement que ce n'est pas une perte.

La vue dit « Données limitées » pour les revenus. Qu'est-ce que cela signifie ?

Vous n'avez pas beaucoup d'événements d'achat cette semaine (moins de 50 sur la fenêtre), ou seule l'une des couches de vérité est remplie (par ex. vous avez des événements d'achat client mais pas de webhook Stripe configuré). La solution est généralement d'attendre plus d'événements ou de brancher la couche manquante.

Pourquoi ne vois-je pas d'étapes d'action pour certaines raisons ?

Les étapes d'action pour les trois raisons actionnables sont disponibles à partir de Pro. Sur Free, vous voyez le nom de la raison et le nombre d'événements, mais le correctif suggéré est verrouillé. Les raisons elles-mêmes et les chiffres principaux sont visibles dans tous les plans.

L'onglet Trust apparaît-il sur mes tableaux de bord publics ?

Non. Trust est une surface diagnostique interne uniquement. Les tableaux de bord partagés publiquement ne l'incluent jamais.

Guides liés

• Taux de rebond et durée de session — se marie bien avec la réconciliation pour enquêter sur la qualité d'engagement
• Comprendre les métriques — définitions des comptes sous-jacents que la vue Trust agrège
• Événements côté serveur — comment brancher la couche serveur qui alimente la réconciliation