Reconciliación servidor-vs-cliente
Los clientes comparan periódicamente sus cifras de Zenovay con GA4, los recibos de Stripe o sus propios logs de backend y descubren que los números no coinciden del todo. 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, 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 | Mismas tablas, source = 'server' |
| Webhook | Confirmaciones de Stripe / LemonSqueezy / Polar | payment_events con status = 'succeeded' |
Para cada triple (sitio, día, métrica) registra: cuántos eventos vio cada capa, cuántos coinciden, 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). - Conversiones de objetivos — eventos de objetivo del cliente vs del servidor.
- Eventos de ingresos — eventos de compra del cliente vs verdad del webhook de Stripe (
payment_events).
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, es webhook_count (el webhook del proveedor de pagos es la fuente de verdad — es lo que efectivamente cobró al cliente).
pérdida_estimada = (verdad - cliente) / verdad × 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 se perdió eventos que la ingesta del servidor sí capturó, que es precisamente la razón para tener ambas.
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 | Alguna 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 alguna capa, pérdida mayor al 60 %, o solo una capa 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 con confianza. 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 dedujo eventos del navegador dentro del día | informativa |
id_stitching | Alta varianza de eventos cliente no apareados 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 — la acción es tuya (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 cualquier panel de dominio en app.zenovay.com y selecciona la pestaña Trust. Verás:
- La pérdida de tracking estimada de los últimos 7 días, con etiqueta de confianza.
- Un desglose por métrica (páginas vistas, objetivos, ingresos) mostrando los conteos de cliente / servidor / apareados y la brecha visualizada como 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) Una tabla drilldown 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 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 menciona 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 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.
Disponibilidad por plan
La pestaña Trust en sí está disponible en todos los planes. El drilldown por ruta y los pasos de acción para razones accionables están disponibles desde Pro. 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.