Reconciliación servidor-vs-cliente
Los clientes comparan periódicamente sus cifras de Zenovay con GA4, recibos de Stripe o sus propios logs de backend y descubren que los números no coinciden exactamente. A veces Zenovay reporta más eventos, a veces menos. La respuesta honesta es que todas las herramientas de analítica — Zenovay incluida — están haciendo una estimación basada en lo que llegó al navegador, lo que llegó al servidor y lo que confirmó un webhook.
La reconciliación es el mecanismo de Zenovay para cuantificar esa brecha con etiquetas de confianza en lugar de fingir que no existe.
Qué compara
La reconciliación se ejecuta como un trabajo diario que compara tres capas de verdad, por sitio web, por tipo de métrica, por día:
| Capa | Qué mide | Dónde vive |
|---|---|---|
| Cliente | Eventos disparados por el tracker del navegador | page_views, user_events con source = 'browser' |
| Servidor | Eventos ingeridos vía POST /api/v1/events | Las mismas tablas, source = 'server' |
| Webhook | Confirmaciones de webhook de Stripe / LemonSqueezy / Polar | payment_events con status = 'succeeded' |
Para cada triple (website, day, metric) registra: cuántos eventos vio cada capa, cuántos coincidieron, el porcentaje de pérdida estimado y una razón principal de mismatch elegida de un conjunto fijo.
Los tres tipos de métrica V1
V1 cubre las tres métricas que tienen una capa de verdad inequívoca:
- Páginas vistas — cliente (navegador) vs servidor (
POST /api/v1/events). - Completaciones de objetivos — eventos de objetivo del cliente vs eventos de objetivo del servidor.
- Eventos de ingresos — eventos de compra del cliente vs verdad del webhook de Stripe (
payment_events).
Los eventos personalizados, llamadas identify y otros tipos de eventos están fuera del alcance de V1 — no tienen una capa de verdad comparable.
Cómo se estima la pérdida
Para páginas vistas y objetivos, la capa de verdad es server_count. Para ingresos, la capa de verdad es webhook_count (el webhook del proveedor de pagos es la fuente de verdad — es lo que efectivamente cobró al cliente).
estimatedLoss = (truth - client) / truth × 100
Se permiten valores negativos: si el servidor capturó más eventos que el tracker del navegador, eso también es información — significa que tu tracker omitió eventos que la ingesta del servidor sí capturó, que es precisamente la razón para ejecutar ambos.
Etiquetas de confianza
Cada fila de reconciliación lleva una de tres etiquetas:
| Etiqueta | Cuándo aplica |
|---|---|
| Confianza alta | Ambas capas tienen ≥100 eventos cada una y la pérdida estimada es menor al 30 %. |
| Confianza media | Una capa está en el rango 50–100 eventos, o la pérdida está entre el 30 % y el 60 %. |
| Datos limitados | Menos de 50 eventos en una capa, la pérdida supera el 60 %, o solo una capa está presente. |
"Datos limitados" no es un problema a corregir — solo significa que la muestra es demasiado pequeña o sesgada como para sacar una conclusión confiable. Las etiquetas de confianza mantienen la vista Trust honesta sobre lo que sabe.
Razones de mismatch
Cuando la reconciliación detecta una brecha significativa, elige una de siete razones, ordenadas por prioridad de detección:
| Razón | Regla de detección | ¿Accionable? |
|---|---|---|
webhook_delay | Cliente > webhook en ≥20 % Y el conteo de webhook de hoy está ≥2σ por debajo de la media de 6 días | ✓ |
client_blocked | Servidor > cliente en ≥10 % | ✓ |
route_mapping | Las 1–2 rutas principales representan ≥50 % de la brecha | ✓ |
duplicate_suppression | El pipeline de ingesta deduplicó eventos del navegador dentro del día | informativa |
id_stitching | Alta varianza en cliente no apareado entre segmentos de visitantes | informativa |
no_server_layer | server_count = 0 y client_count > 0 | informativa |
unknown | Ningún umbral activado | informativa |
Tres razones son accionables — lo que significa que la acción te corresponde a ti (corregir tu CSP, configurar reintentos del SDK, verificar la entrega del webhook de Stripe). Las otras cuatro aportan contexto diagnóstico.
Dónde verlo
Abre Dominios, haz clic en tu sitio y luego selecciona la pestaña Trust (bajo Confiabilidad). Verás:
- La pérdida de tracking estimada de los últimos 7 días, con una etiqueta de confianza.
- Un desglose por métrica (páginas vistas, objetivos, ingresos) que muestra los conteos de cliente / servidor / coincidentes y la brecha visualizada como una sección rayada de una barra de completitud.
- Las principales razones de mismatch ordenadas por impacto en eventos, con pasos de acción para las accionables.
- (Pro y superior) Un desglose por ruta que muestra exactamente qué rutas contribuyen más a la brecha.
Lo que no es
- No es una garantía de corrección. Es una medición de la calidad de la medición.
- No es un intento de corregir la brecha. Las correcciones — configuración de CSP, configuración de webhook, normalización de rutas — son de tu lado.
- No nombra servicios ni proveedores terceros que no estés usando ya. Las razones de mismatch se mantienen genéricas para que los pasos de acción sigan siendo relevantes sea cual sea tu stack.
- No crea una nueva recolección de datos. La reconciliación lee filas existentes de
page_views,user_eventsypayment_events— sin nuevas cookies, sin nuevos identificadores, y la garantía de tracking sin cookies se mantiene sin cambios.
Disponibilidad por plan
La pestaña Trust en sí está disponible en todos los planes. El desglose por ruta y los pasos de acción para razones accionables están disponibles en Pro y superior. Free muestra agregados y nombres de razón sin el detalle a nivel de ruta.
Conceptos relacionados
- Tasa de rebote — otra señal de calidad que se beneficia del contexto de reconciliación.
- Ingesta de eventos del lado del servidor — el endpoint
POST /api/v1/eventsque alimenta la capa servidor de la reconciliación. - Tracking sin cookies — por qué el tracker en memoria no contamina la reconciliación con identificadores obsoletos.