La vista Trust se encuentra en tu panel de dominio y ofrece una medición honesta de cuánto de tu tracking se está capturando realmente. Se ejecuta diariamente y compara tres señales — el tracker del navegador, la ingesta del lado del servidor y la verdad de los webhooks — para estimar las brechas y explicar de dónde provienen probablemente.
Esta guía recorre cómo leer la vista y qué hacer cuando algo merece investigación.
Dónde encontrarla
En app.zenovay.com, abre cualquier panel de dominio y selecciona la pestaña Trust del grupo Reliability en la barra lateral (está en /domains/{id}?tab=trust). La vista muestra los resultados de reconciliación de los últimos 7 días.
Si el sitio es nuevo, podrías ver un estado vacío amable. La primera fila de reconciliación aparece dentro de las 24 horas posteriores a la actividad (el job diario corre a las 00:00 UTC).
El número principal
Arriba verás un porcentaje grande etiquetado «pérdida de tracking estimada» junto a un chip de confianza:
- Porcentaje positivo (p. ej.
8,4 %) — tu tracker del navegador registra menos eventos de los que sugieren la capa servidor o webhook. Algo de pérdida es normal; el desglose siguiente explica por qué. - Porcentaje negativo / «+X % sobre-contados» — tu servidor registra más eventos que tu tracker del navegador. No es un bug; normalmente significa que la ingesta del servidor capturó eventos que los bloqueadores de anuncios o caídas de red habrían perdido.
—(raya) — aún no hay suficientes datos comparables, generalmente porque la capa servidor o webhook está vacía para este sitio.
Debajo del porcentaje hay una barra de completitud. La sección esmeralda sólida muestra eventos que coinciden entre capas. La sección rayada ámbar muestra la brecha estimada.
Etiquetas de confianza
Cada métrica lleva una de tres etiquetas:
| Chip | Significado |
|---|---|
| Confianza alta ●●● | Ambas capas tienen ≥100 eventos y la pérdida está por debajo del 30 %. El número es confiable. |
| Confianza media ●●○ | Alguna capa está en el rango de 50–100 eventos, o la pérdida está entre el 30 % y el 60 %. Trata el número como direccional. |
| Datos limitados ●○○ | Una o ambas capas tienen menos de 50 eventos, o la pérdida supera el 60 %. La vista dice lo poco que ve, pero no actúes solo en este número. |
Confianza no es severidad. Una pérdida del 5 % con confianza alta es información más útil que una pérdida del 80 % con confianza limitada.
Leer el desglose por métrica
Tres filas debajo del número principal muestran la misma comparación aplicada por separado a páginas vistas, conversiones de objetivos y eventos de ingresos. Cada fila lleva su propia etiqueta de confianza y tres columnas (cliente / servidor / webhook), más una barra de completitud.
Algunos patrones comunes:
- Páginas vistas: cliente y servidor deberían estar cerca. Una brecha persistente suele apuntar a bloqueadores de anuncios o reglas CSP que bloquean silenciosamente al tracker en ciertas páginas.
- Objetivos: las brechas aquí son a menudo legítimas — el visitante cierra la pestaña entre disparar el evento cliente y la confirmación del servidor. Presta más atención a los cambios de tendencia que a un porcentaje aislado de un día.
- Ingresos: la capa webhook es la fuente de verdad (es lo que efectivamente cobró al cliente). Una brecha aquí significa o bien que los eventos de compra del cliente no se disparan en cada pago exitoso, o que las entregas de webhook están retrasadas.
Si ves en una fila un mensaje pequeño como «Ingesta del servidor aún no en uso», significa que la capa de verdad para esa métrica está vacía. La reconciliación mostrará algo (Trust usa la capa que existe), pero con confianza baja.
Razones principales de mismatch
Debajo del desglose por métrica, Trust clasifica las razones principales sospechadas, ordenadas por cuántos eventos afecta cada razón esta semana.
Tres razones están marcadas como Accionable con una pequeña etiqueta ámbar. Para estas, los planes Pro y superiores ven un paso de acción de una línea. Las otras razones son diagnósticas — explican qué está pasando sin requerir que hagas nada.
Razones accionables y qué hacer
Tracker del cliente probablemente bloqueado (client_blocked)
- Lo que vimos: los conteos del lado del servidor fueron notablemente más altos que los del navegador para al menos una métrica.
- Causa probable: un bloqueador de anuncios, una extensión de privacidad del navegador o tu propio encabezado Content-Security-Policy está bloqueando el tracker en algunas visitas.
- Qué probar: añade
api.zenovay.coma tu directiva CSPconnect-src. Si usas una CSP más estricta conscript-src, añádelo también allí. Para pérdidas por extensiones de privacidad, considera habilitar tracking first-party para que el tracker se cargue desde tu propio dominio.
Entrega de webhook retrasada (webhook_delay)
- Lo que vimos: los eventos de compra del cliente superaron las llegadas de webhooks Y el conteo de webhook de hoy cayó muy por debajo de la línea base de 6 días.
- Causa probable: tu proveedor de pagos (típicamente Stripe) aún no ha entregado algunos webhooks. Esto a menudo se resuelve solo en horas.
- Qué probar: abre el panel de entregas de webhooks de tu proveedor de pagos y busca webhooks fallidos o pendientes. Si ves reintentos, la brecha debería cerrarse a medida que lleguen. Si los webhooks están fallando completamente, comprueba que tu endpoint sea alcanzable y devuelva respuestas 2xx.
Mismatch de normalización de ruta (route_mapping)
- Lo que vimos: 1–2 rutas específicas representan más de la mitad de la brecha.
- Causa probable: esas rutas se normalizan de forma diferente entre el tracker del navegador y el servidor. Caso común: una ruta SPA que el tracker reporta como
/checkout/abc123pero el servidor registra como/checkout/[id]. - Qué probar: revisa el manejo de rutas SPA de tu tracker para las URL afectadas. La tabla drilldown Pro+ muestra exactamente qué rutas contribuyen a la brecha.
Razones diagnósticas (sin acción requerida)
- Eventos duplicados suprimidos — el pipeline de ingesta detectó eventos del navegador duplicados con la misma clave de idempotencia y mantuvo solo uno. Comportamiento correcto.
- Brechas de identidad de visitante — el ID del navegador de un visitante no coincidió limpiamente entre eventos registrados en el servidor. Común cuando el visitante borró cookies a mitad de sesión.
- Ingesta del servidor no en uso — aún no has comenzado a enviar eventos del lado del servidor a
POST https://api.zenovay.com/e/{trackingCode}. La reconciliación del servidor no es posible sin eso. Ver Eventos del servidor para configuración. - No se identificó causa dominante — la brecha está por debajo del umbral para cualquier razón específica. A menudo significa simplemente que tu tracking está sano.
La tabla drilldown Pro+
Si tu plan es Pro o superior, verás abajo una tabla Brecha por ruta que enumera las mayores diferencias de una sola ruta entre conteos cliente y servidor esta semana, ordenadas por brecha de eventos.
Es la parte más accionable de la vista: te dice exactamente dónde mirar. Algunos ejemplos:
- Una sola página de detalle de producto que representa la mayor parte de la brecha de páginas vistas → comprueba si esa página tiene una regla CSP, un script inline personalizado o una maquetación probada en A/B que rompe el tracker.
- Una ruta
/checkoutque aparece solo en el lado del servidor → tu tracker del cliente puede no estar instalado en la página de checkout (omisión común con flujos de pago aislados). - Un patrón
/blog/[slug]con cientos de rutas que contribuyen cada una 1–2 eventos → esperado; ignorar.
Preguntas frecuentes
La pestaña Trust dice que estoy perdiendo el 12 % de las páginas vistas. ¿Debería preocuparme?
No necesariamente. Las referencias del sector para analytics basados en navegador sitúan la pérdida por bloqueadores entre el 20 % y el 40 % en algunos verticales. Una pérdida medida del 12 % con una comparación real del lado del servidor es mucho mejor que la pérdida no medida de una herramienta de analytics típica. La pregunta accionable es si la brecha está concentrada en rutas específicas (reparable) o repartida uniformemente (coste del negocio).
¿Por qué mi número muestra «+5 % sobre-contados»?
Tu servidor capturó más eventos que tu tracker del navegador. Es buena noticia — la ingesta del servidor está rellenando brechas que tu tracker habría perdido. El «+» deja claro que no es pérdida.
La vista dice «Datos limitados» para ingresos. ¿Qué significa?
O bien no tienes muchos eventos de compra esta semana (menos de 50 en la ventana), o solo una de las capas de verdad está poblada (p. ej. tienes eventos de compra del cliente pero no hay webhook de Stripe configurado). La solución suele ser esperar más eventos o conectar la capa que falta.
¿Por qué no veo pasos de acción para algunas razones?
Los pasos de acción para las tres razones accionables están disponibles desde Pro. En Free verás el nombre de la razón y el conteo de eventos, pero la solución sugerida está restringida. Las razones en sí y los números principales son visibles en todos los planes.
¿Aparece la pestaña Trust en mis paneles públicos?
No. Trust es una superficie de diagnóstico solo interna. Los paneles compartidos públicamente nunca la incluyen.
Guías relacionadas
- Tasa de rebote y duración de sesión — combina bien con reconciliación al investigar la calidad de engagement
- Entender métricas — definiciones de los conteos subyacentes que Trust agrega
- Eventos del servidor — cómo conectar la capa servidor que alimenta la reconciliación