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 webhook 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ë :
- Vues de page — 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 vues de page et les objectifs, la couche de vérité est server_count. Pour les revenus, la couche de vérité est webhook_count (le webhook du fournisseur de paiement est la source de vérité — c'est celui-ci qui a effectivement débité le client).
estimatedLoss = (truth - client) / truth × 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 — cela signifie que votre tracker a manqué des événements que l'ingestion côté serveur a captés, ce qui est précisément la raison pour laquelle 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 tirer une conclusion avec confiance. 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 au cours de 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 — ce qui signifie que l'action vous appartient (corriger votre CSP, configurer le retry du SDK, vérifier la livraison du webhook Stripe). Les quatre autres sont un contexte diagnostique.
Où la voir
Ouvrez Domains, cliquez sur votre site, puis sélectionnez l'onglet Trust (sous Reliability). Vous verrez :
- La perte de tracking estimée pour les 7 derniers jours, avec une étiquette de confiance.
- Une ventilation par métrique (vues de page, objectifs, revenus) montrant les comptes client / serveur / appariés et l'écart visualisé comme une section 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 — vous appartiennent.
- 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 pas de 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 est 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 et plus. 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.