Réconciliation serveur-vs-client
Les clients comparent régulièrement leurs chiffres Zenovay à GA4, aux reçus Stripe ou à leurs propres logs backend, et constatent que les chiffres ne concordent pas tout à fait. Parfois Zenovay rapporte plus d'événements, parfois moins. La réponse honnête est que tout outil d'analytics — Zenovay compris — fournit une estimation basée sur ce qui a atteint le navigateur, ce qui a atteint le serveur et ce qu'un webhook a confirmé.
La réconciliation est le mécanisme par lequel Zenovay quantifie cet écart avec des étiquettes de confiance plutôt que de prétendre qu'il n'existe pas.
Ce qu'elle compare
La réconciliation s'exécute comme une tâche quotidienne qui compare trois couches de vérité, par site, par type de métrique, par jour :
| Couche | Ce qu'elle mesure | Où elle se trouve |
|---|---|---|
| Client | Événements émis par le tracker du navigateur | page_views, user_events avec source = 'browser' |
| Serveur | Événements ingérés via POST /api/v1/events | Mêmes tables, source = 'server' |
| Webhook | Confirmations Stripe / LemonSqueezy / Polar | payment_events avec status = 'succeeded' |
Pour chaque triplet (site, jour, métrique), elle enregistre : combien d'événements chaque couche a vus, combien correspondent, le pourcentage de perte estimé et une raison principale de mismatch choisie dans une liste fixe.
Les trois types de métriques V1
V1 couvre les trois métriques pour lesquelles il existe une couche de vérité non ambiguë :
- Pages vues — client (navigateur) vs serveur (
POST /api/v1/events). - Conversions d'objectifs — événements d'objectif côté client vs côté serveur.
- Événements de revenus — événements d'achat client vs vérité webhook Stripe (
payment_events).
Les événements personnalisés, les appels identify et les autres types d'événements sont hors périmètre V1 — ils n'ont pas de couche de vérité comparable.
Comment la perte est estimée
Pour les pages vues et les objectifs, la couche de vérité est server_count. Pour les revenus, c'est webhook_count (le webhook du fournisseur de paiement est la source de vérité — c'est lui qui a effectivement débité le client).
perte_estimée = (vérité - client) / vérité × 100
Les valeurs négatives sont autorisées : si le serveur a capturé plus d'événements que le tracker du navigateur, c'est aussi une information — votre tracker a manqué des événements que l'ingestion côté serveur a captés. C'est précisément pour cela qu'on exécute les deux.
Étiquettes de confiance
Chaque ligne de réconciliation porte l'une des trois étiquettes :
| Étiquette | Conditions |
|---|---|
| Confiance élevée | Les deux couches ont chacune ≥100 événements et la perte estimée est inférieure à 30 %. |
| Confiance moyenne | L'une des couches est dans la plage 50-100 événements, ou la perte est entre 30 % et 60 %. |
| Données limitées | Moins de 50 événements sur une couche, perte supérieure à 60 %, ou une seule couche présente. |
« Données limitées » n'est pas un problème à corriger — cela signifie simplement que l'échantillon est trop petit ou trop unilatéral pour conclure avec certitude. Les étiquettes de confiance maintiennent la vue Trust honnête sur ce qu'elle sait.
Raisons de mismatch
Lorsque la réconciliation détecte un écart significatif, elle choisit l'une des sept raisons, classées par priorité de détection :
| Raison | Règle de détection | Actionnable ? |
|---|---|---|
webhook_delay | Client > webhook de ≥20 % ET le compte webhook du jour est ≥2σ sous la moyenne sur 6 jours | ✓ |
client_blocked | Serveur > client de ≥10 % | ✓ |
route_mapping | Les 1-2 routes principales représentent ≥50 % de l'écart | ✓ |
duplicate_suppression | Le pipeline d'ingestion a dédupliqué des événements navigateur dans la journée | informatif |
id_stitching | Forte variance des événements client non appariés à travers les segments de visiteurs | informatif |
no_server_layer | server_count = 0 et client_count > 0 | informatif |
unknown | Aucun seuil franchi | informatif |
Trois raisons sont actionnables — l'action est de votre côté (corriger votre CSP, configurer le retry du SDK, vérifier la livraison du webhook Stripe). Les quatre autres fournissent un contexte diagnostique.
Où la voir
Ouvrez n'importe quel tableau de bord de domaine sur app.zenovay.com et sélectionnez l'onglet Trust. Vous y verrez :
- La perte de tracking estimée pour les 7 derniers jours, avec une étiquette de confiance.
- Une ventilation par métrique (pages vues, objectifs, revenus) montrant les comptes client / serveur / appariés et l'écart visualisé en zone hachurée d'une barre de complétude.
- Les principales raisons de mismatch classées par impact en événements, avec des étapes d'action pour les actionnables.
- (Pro et plus) Un tableau drilldown par route montrant exactement quelles routes contribuent le plus à l'écart.
Ce qu'elle n'est pas
- Ce n'est pas une garantie d'exactitude. C'est une mesure de la qualité de mesure.
- Ce n'est pas une tentative de corriger l'écart. Les corrections — configuration CSP, configuration webhook, normalisation des routes — sont de votre côté.
- Elle ne nomme pas de services ou fournisseurs tiers que vous n'utilisez pas déjà. Les raisons de mismatch restent génériques afin que les étapes d'action restent pertinentes quel que soit votre stack.
- Elle ne crée aucune nouvelle collecte de données. La réconciliation lit les lignes existantes de
page_views,user_eventsetpayment_events— pas de nouveaux cookies, pas de nouveaux identifiants, et la garantie de tracking sans cookie reste inchangée.
Disponibilité par plan
L'onglet Trust lui-même est disponible sur tous les plans. Le drilldown par route et les étapes d'action pour les raisons actionnables sont disponibles à partir de Pro. Free affiche les agrégats et les noms de raisons sans le détail au niveau des routes.
Concepts liés
- Taux de rebond — un autre signal de qualité qui bénéficie du contexte de réconciliation.
- Ingestion d'événements côté serveur — le point de terminaison
POST /api/v1/eventsqui alimente la couche serveur de la réconciliation. - Tracking sans cookie — pourquoi le tracker en mémoire ne pollue pas la réconciliation avec des identifiants obsolètes.