Respuesta
Cuando un KPI no coincide entre Zoho CRM y Zoho Analytics, casi siempre es por una de tres cosas: no están midiendo lo mismo (definición y filtros), no están mirando el mismo momento (fechas y zona horaria), o los datos no están idénticos todavía (sincronización, permisos o joins que duplican). La forma más rápida de encontrar la causa es aislar un KPI, fijar un periodo exacto y conciliar a nivel registro con IDs. En cuanto encuentras el primer deal “culpable”, el patrón suele repetirse y el arreglo deja de ser misterioso. Piensa en esto como reconciliar una cuenta bancaria: no se resuelve mirando el saldo, se resuelve revisando movimientos concretos.
Alinear alcance: qué KPI no coincide, en qué periodo y con qué filtros
El error común aquí es empezar “arreglando el dashboard” sin acordar la pregunta exacta. Si comparas ingresos en CRM por mes de cierre, pero en Analytics lo estás viendo por mes de creación, ambos números pueden ser correctos y aun así no coincidir.
Primero, define el caso de prueba con precisión: qué KPI exacto, qué periodo, qué moneda, qué pipeline, qué etapa, qué equipo y qué usuario. En Zoho CRM anota si el reporte usa “Todos los tratos” o “Mis tratos”, y si parte de una vista o criterio guardado. En Zoho Analytics identifica si el dashboard tiene filtros a nivel de página, de gráfico o de usuario.
Tip práctico 1: reduce el alcance a una ventana pequeña y dolorosa, por ejemplo “últimos 14 días” o “un mes cerrado”, y elige un segmento simple, como un solo pipeline y una sola moneda. Diagnosticar un KPI anual con 9 filtros activos es como buscar unas llaves en una playa.
Revisar sincronización: conector Zoho CRM → Zoho Analytics
Antes de entrar a fórmulas, confirma salud de datos. Verifica la hora de la última sincronización y si hubo fallos. Si el conector está en incremental, un cambio masivo reciente en CRM puede tardar en reflejarse o quedar a medias si hubo límites o errores.
Dos puntos suelen romper la paridad:
Permisos del usuario conector. Si el usuario que conecta no ve ciertos deals, campos o módulos, Analytics tampoco los verá, aunque tú como admin sí. Esto es especialmente traicionero con campos de importe, moneda, owner y con módulos relacionados.
Tablas que no se están trayendo. Para KPIs de embudo y tiempos por etapa, necesitas historia. Si solo tienes el estado actual del deal, tus métricas de conversión y duración por etapa pueden “inventarse” sin querer.
Tip práctico 2: haz una comprobación rápida de volumen. Cuenta deals por mes en CRM y en Analytics con los mismos filtros, solo un conteo de IDs. Si el conteo ya difiere, todavía no es un problema de “cálculo de KPI”, es un problema de datos o de filtros.
Conciliación a nivel registro: muestreo y comparación 1:1
Cuando hay discrepancia, la forma profesional de cortar el ruido es conciliar por ID.
En CRM, arma un listado de los deals que componen tu KPI para ese periodo. Incluye columnas mínimas: Deal ID, Amount, Stage, Pipeline, Owner, Created Time, Closing Date, Modified Time, moneda.
En Analytics, arma el mismo listado desde la tabla sincronizada. Idealmente exporta ambos a CSV.
Cruza por Deal ID. Busca tres tipos de diferencias: IDs que están en CRM pero no en Analytics, IDs extra en Analytics, e IDs que existen en ambos pero con valores distintos.
Empieza por los “top” por monto. Una discrepancia de 5 deals explica más que 200 deals pequeños y te da una pista inmediata del patrón, por ejemplo “todos los que cambiaron de etapa ayer”, “todos los multi moneda”, o “todos los reabiertos”.
Fechas y zona horaria: la causa #1 (Created vs Close vs Modified vs Stage change)
Si tuviera que apostar, apostaría por fechas. En CRM conviven varias fechas que la gente mezcla:
Created Time: cuándo nació el deal.
Closing Date: la fecha de cierre esperada o real, según tu disciplina de datos.
Modified Time: cuándo se tocó el registro.
Stage change time: cuándo cambió de etapa, que no siempre coincide con Modified Time si hay automatizaciones o actualizaciones de campos.
Para ingresos “ganados”, lo más estable es reconocerlos por Closing Date del estado Won, y agrupar por esa fecha en la misma zona horaria. Para tasa de cierre y ciclo de venta, la definición cambia el resultado de forma dramática: puedes medir tasa por cohortes de creados, o tasa por cierres en el periodo. Ninguna es “la correcta” en abstracto, pero mezclar definiciones entre CRM y Analytics es garantía de discrepancias.
A continuación tienes una tabla de controles típicos que conviene revisar porque, si están mal, rompen KPIs temporales:
Set: Zona horaria. Si CRM y Analytics no comparten zona horaria, los cierres de fin de mes se “mueven” de periodo.
Set: Fecha de cierre (Closing Date). Si se usa de forma inconsistente, ingresos y forecast se distorsionan.
Set: Fecha de creación (Created Time). Es la base para tasas por cohorte y no es intercambiable con Closing Date.
Set: Ciclo de venta. Alinea el punto de inicio y fin o el KPI será incomparable.
Set: Deals sin Closing Date. Un porcentaje pequeño sin fecha puede hacer que el total del mes “no cuadre”.
Un detalle muy humano: el 31 a las 23:30 en una zona horaria puede ser el 1 a las 00:30 en otra. Y ahí tienes el misterio del mes cerrado, sin necesidad de teorías conspirativas.
Etapas, pipelines y cambios históricos (Stage History) vs estado actual
La segunda gran fuente de discrepancias es el embudo. Si tienes múltiples pipelines, etapas renombradas o etapas eliminadas, tus KPIs dependen de cómo esté mapeado cada valor en cada herramienta.
Además, hay una diferencia conceptual entre medir sobre el estado actual y medir sobre historia:
Si hoy un deal está Won, CRM te lo muestra Won. Pero para responder “cuánto tardó en pasar por Propuesta”, necesitas Stage History o un registro de cambios. Si en Analytics calculas tiempos por etapa usando solo el estado actual o Modified Time, tendrás números que parecen razonables pero no representan el recorrido real.
Revisa si tu modelo en Analytics está usando tablas de historia o solo la tabla principal de Deals. Si no tienes historia, limita el KPI a lo que sí puedes medir con integridad, por ejemplo ciclo de venta desde Created Time a Closing Date para deals cerrados, y no “tiempo en cada etapa” hasta tener Stage History.
Deals reabiertos, backdating y ediciones retroactivas
Los deals no son fósiles, se editan. Tres escenarios rompen la coherencia histórica:
Reabrir deals. Un deal puede pasar de Won a una etapa abierta por devolución, cancelación o error. Si tu KPI en CRM se basa en “estado actual” y tu KPI en Analytics se basa en “eventos de cierre”, verás diferencias.
Backdating. Cambiar Closing Date al pasado para “acomodar” el cierre. Esto mueve ingresos entre meses sin que necesariamente se note en un gráfico de tendencia si no auditas.
Ediciones retroactivas de Amount después de ganar. Si un comercial ajusta el monto por descuento final una semana después, el mes pasado cambia. Tu dashboard no está mal, solo es demasiado honesto.
Aquí, Modified Time es tu aliado para detectar “cambios tardíos” y explicarlos. Si tu negocio necesita estabilidad contable, define una regla: después de Won, solo ciertos roles pueden editar Amount y Closing Date, o se registra el cambio en un campo de auditoría.
Duplicados, merges y relaciones (Accounts/Contacts/Deals)
Los duplicados y los merges crean discrepancias de dos formas:
Primero, el mismo deal puede existir dos veces por error operativo, y un reporte en CRM puede estar filtrando uno por vista mientras Analytics suma ambos.
Segundo, y más sutil, las relaciones duplican montos en Analytics cuando haces joins. El caso clásico es Deals con múltiples productos. Si haces un join Deals con Products y luego sumas Amount, cada deal se repite por línea de producto y el ingreso se multiplica.
Señales de alerta:
Ingresos inflados justo cuando activaste productos.
Conteo de deals correcto pero suma de Amount demasiado alta.
La corrección típica es agregar en el nivel correcto. Suma ingresos desde Deals sin expandir a líneas, o usa agregación previa antes del join. Si necesitas análisis por producto, usa el importe de línea, no el Amount del deal.
Campos de importe: Amount vs Total, impuestos, descuentos y multi moneda
En Zoho CRM, “Amount” no siempre significa lo mismo en todas las implementaciones. Algunas organizaciones trabajan con Amount como subtotal, otras con Grand Total, y otras con un campo personalizado que incluye impuestos o descuentos.
Si además hay multi moneda, aparece otra capa: qué tipo de cambio se usa, cuándo se aplica y en qué moneda estás reportando. Es común que CRM muestre el valor en la moneda del deal, mientras Analytics lo convierta a una moneda base o viceversa.
Práctica recomendada: documenta un campo objetivo para reporting, por ejemplo “Amount en moneda base”, y úsalo de punta a punta para KPIs financieros. Si no documentas, cada dashboard acaba contando una historia distinta con el mismo dato, que es como pedir un café “tamaño normal” en un aeropuerto.
Filtros ocultos: roles, compartición, owner, territorios, vistas
A veces el KPI “no coincide” porque no estás viendo el mismo universo de datos.
En CRM, un reporte puede aplicar reglas de compartición, jerarquía, territorios o filtros por owner. En Analytics, puede haber filtros a nivel de dashboard o reglas de acceso por usuario.
Prueba rápida: compara como admin en ambos lados, sin filtros, con un conteo de deals y un sumatorio simple. Luego añade filtros uno a uno: owner, pipeline, fecha, moneda. Cuando el número se rompe al aplicar un filtro específico, ya encontraste el culpable.
Pruebas específicas por KPI (ingresos, tasa de cierre, ciclo)
Para cerrar el diagnóstico, te propongo mini pruebas muy concretas por KPI. La idea no es sofisticación, es reproducibilidad.
Ingresos
Prueba de suma por ID. En Analytics crea una tabla con Deal ID y Amount para deals Won con Closing Date en el periodo. Suma y compárala con el reporte equivalente en CRM. Si difiere, revisa los 10 deals de mayor monto y mira Amount, moneda y Closing Date.
Prueba de fecha. Repite el cálculo agrupando por día en lugar de por mes. Si el total mensual difiere pero el diario te muestra picos en el último día del mes, sospecha de zona horaria o de backdating.
Prueba de join. Si tu gráfico usa productos o facturas relacionadas, calcula ingresos desde la tabla de Deals sin relaciones. Si ahí coincide, el problema es duplicación por relación.
Tasa de cierre
Define el denominador. Tasa por cohorte significa: deals creados en el periodo que terminaron Won o Lost dentro de una ventana. Tasa por cierres significa: de los que cerraron en el periodo, cuántos fueron Won. Son KPIs distintos y se parecen solo en nombre.
Prueba de estados cerrados. Asegura que “Lost” esté bien definido. Si tienes etapas como “No contactado” o “On hold” que en realidad son abiertos, no deben entrar como perdidos.
Prueba por pipeline. Calcula la tasa por pipeline por separado. Un pipeline mal mapeado o con etapas mezcladas suele explicar discrepancias grandes.
Ciclo de venta
Población limpia. Calcula ciclo solo para deals cerrados, con Created Time y Closing Date presentes. Los deals sin Closing Date o con fechas irreales distorsionan todo.
Mediana antes que promedio. Un par de deals que tardaron 400 días disparan el promedio. Usa mediana para decisiones de operación y deja el promedio para análisis estadístico.
Prueba de inicio del ciclo. Decide si el ciclo empieza en Created Time o cuando entra a la primera etapa “calificada”. Si tu equipo crea deals muy temprano, Created Time infla el ciclo y no es un bug.
Si quieres una heurística para priorizar: primero haz que ingresos coincida. Luego tasa de cierre. Por último ciclo de venta, porque depende de definiciones y de disciplina en fechas.
Para profundizar en cómo estructurar KPIs y dashboards con criterios consistentes, te sirve el marco de KPIs en CRM y dashboards en Zoho Analytics, y para troubleshooting de discrepancias el enfoque de Zoho sobre encontrar causa raíz en KPIs es muy alineado con este método de aislar, comparar y verificar definiciones. Mi recomendación práctica final es simple: elige un KPI y un mes, concilia por ID, fija definiciones de fechas y moneda, y recién ahí optimiza visualizaciones. Lo demás es cosmética.
| Control | Dónde vive | Qué configurar | Qué se rompe si está mal |
|---|---|---|---|
| Set: Zona horaria | Configuración de Zoho CRM y Zoho Analytics | Asegurar que ambas plataformas usen la misma zona horaria | Discrepancias en fechas y horas de eventos, afectando KPIs temporales |
| Set: Fecha de cierre (Closing Date) | Módulo de Oportunidades en CRM | Usar Closing Date para ingresos 'ganados'. Evitar fechas futuras irreales. | Ingresos proyectados incorrectos, forecast de ventas erróneo |
| Set: Fecha de creación (Created Time) | Módulo de Oportunidades en CRM | Usar Created Time para calcular la tasa de cierre por cohorte | Análisis de eficiencia de embudo distorsionado |
| Set: Ciclo de venta | Módulo de Oportunidades en CRM | Definir inicio — Created Time o 1ª etapa y fin — Closing Date | Duración del ciclo de venta inexacta, impactando la planificación |
| Set: Deals sin Closing Date | Módulo de Oportunidades en CRM | Establecer reglas para que todas las oportunidades tengan una Closing Date | Oportunidades no consideradas en reportes de ingresos o forecast |
| Set: Edición de Closing Date | Módulo de Oportunidades en CRM | Auditar cambios en Closing Date, especialmente si se edita al pasado | Historial de ingresos alterado, dificultando el análisis de tendencias |
Fuentes
- KPIs Clave En Un CRM Y Dashboards En Zoho Analytics
- Motivator's KPI data seems wrong or does not match with CRM data ...
- Zoho Analytics | Conecta tus Datos de Zoho CRM - YouTube
- Introducción y Espacios de Trabajo en Zoho Analytics | Guía Práctica
- [3 Errores Comunes en Zoho Analytics y cómo Evitarlos Tips para ...
- How to Check Analytics in Zoho CRM 2026? - YouTube
Última actualización: 2026-04-03 | Calypso