Calculated Insights Recommender para Data Cloud.
KPIs canónicos en lugar de fórmulas inventadas en cinco lugares distintos.
El agente OOTB de Agentforce que detecta KPIs y métricas faltantes según el uso real (queries, dashboards, segmentos), propone fórmulas SQL y business logic, valida outputs sobre sample, monitorea drift y mantiene una library viva de Calculated Insights por dominio. Pensado para Analytics Engineer, Data Architect, Marketing Analytics y BI Lead que quieren un único catálogo de métricas confiables, no un wiki de fórmulas duplicadas.
¿Qué hace Calculated Insights Recommender?
Es un agente OOTB de Agentforce que mantiene viva la library de Calculated Insights de la compañía. Lee el query history, dashboards, segmentos y patrones de uso, detecta KPIs que se calculan de varias maneras en lugares distintos, propone una fórmula canónica con la business logic correcta, simula sobre sample y deja la CI lista para deploy con refresh policy adecuada. Audita drift y propone retiro de CIs abandonadas.
Cómo funciona paso a paso
De señal de uso a CI deployada con refresh diario. 5 pasos por iteración.
Señal de uso
El agente escanea queries del copilot, dashboards de Tableau o CRMA, segmentos y CIs existentes para detectar métricas recurrentes que no tienen una versión canónica.
Proponer CI con fórmula
Propone una fórmula SQL alineada al glossary, define la business logic explícita, sugiere el refresh policy adecuado y muestra la lista de consumers que se beneficiarían.
Validar sobre sample
Ejecuta la fórmula sobre datos históricos representativos. Reporta distribución, valores extremos, outliers y compara contra las versiones existentes de la métrica.
Deploy con governance
El Analytics Engineer aprueba. El agente despliega la CI con naming convention, owner asignado y refresh schedule. Notifica a los consumers afectados.
Monitorear drift
Vigila la distribución de la CI en el tiempo. Si detecta deriva más allá del threshold definido, alerta al owner y propone investigación o ajuste de la fórmula.
Ejemplo de interacción
[El agente detecta duplicación]
[Propuesta canónica]
Arquitectura técnica
Topics, Actions, Hydrators, Effectors, Channels, DMOs, Trust Layer y Memory que sostienen al agente.
Topics
Dominios de razonamiento
- CI Pattern Detector
- Formula Composer
- Validation Loop
- Refresh Optimizer
- Lineage Mapper
- Anomaly Watcher
Actions y canales
Lo que ejecuta y dónde vive
- proposeCI
- validateCI
- deployCI
- refreshCI
- retireCI
- Lightning
- Slack vía MCP
Hydrators y DMOs
Contexto y memoria
- DMOs documentados
- CIs previos
- Query history
- Dashboard usage Tableau / CRMA
- Segments definitions
- Memory: aceptaciones y rechazos
Effectors y Trust Layer
Escrituras y guardrails
- Crear CI definition
- Schedule de refresh
- Monitor de drift
- PII handling y masking si aplica
- Audit trail completo
- Lineage upstream y downstream
Cómo se implementa en 5 fases
De métricas dispersas a una library de Calculated Insights canónica y viva.
Discovery del catálogo de métricas
Auditamos CIs existentes, dashboards, queries recurrentes y métricas duplicadas. Identificamos el dominio que duele más empezar a ordenar.
Definición de glossary y naming
Trabajamos con el equipo de analytics el business glossary mínimo y la naming convention de CIs (dominio_metrica_ventana).
Configuración del agente
Configuramos Topics, Actions y permisos. Definimos thresholds de drift, criterios de propuesta y matriz de approval por dominio.
Primer batch de CIs canónicas
El agente propone las CIs faltantes del primer dominio. El Analytics Engineer revisa, aprueba y se despliegan con plan de migración para reemplazar versiones duplicadas.
Cadencia continua y drift watch
El agente sigue proponiendo CIs nuevas, monitorea drift y propone retiro de CIs sin consumers. Cadencia mensual de revisión con el Analytics Engineer.
Equipo típico de implementación
Requisitos para arrancar
Lo que necesitás listo antes de poner el Calculated Insights Recommender en producción.
Datos
- DMOs documentados con descriptions
- Identity Resolution funcionando
- CIs existentes catalogadas
- Glossary mínimo viable
Integraciones
- Tableau Next o CRMA conectado
- Telemetría de queries activa
- Slack vía MCP para notificaciones
- Lineage habilitado
Organizacional
- Ownership por dominio
- Política de approval de fórmulas
- Sponsor en BI o Analytics
- Cadencia de revisión mensual
Trust y compliance
- Trust Layer activo
- Masking de PII si la CI la usa
- Audit trail habilitado
- Permisos por rol revisados
Qué se busca optimizar
Lo que el agente busca mejorar — los rangos exactos dependen del baseline de cada compañía.
Time-to-insight
Pasar de un sprint para definir y validar una métrica nueva a un día con propuesta y simulación previa.
CIs reutilizadas vs. duplicadas
Subir el porcentaje de CIs canónicas reutilizadas y reducir las versiones duplicadas en distintos dashboards y segmentos.
Cobertura de dashboards
Aumentar la cobertura de dashboards que usan CIs canónicas en lugar de fórmulas inline calculadas en cada herramienta.
Frescura del catálogo
Mantener al día las descriptions, owners y refresh policy de cada CI activa, para que el discovery del LLM y de los humanos sea confiable.
Drift detectado a tiempo
Bajar el tiempo entre la deriva de una métrica y su detección, para que campañas y reportes no operen sobre números engañosos.
Tiempo del Analytics Engineer
Liberar capacidad del equipo de analytics del trabajo repetitivo de definir métricas y hacer revisiones manuales de fórmulas.
Qué considerar al implementar
Decisiones de diseño que vale la pena tomar al principio. Solu acompaña cada una con un patrón probado.
Glossary y descriptions maduros
El agente compone fórmulas con la semántica que lee del catálogo. Solu enriquece descriptions y trabaja el glossary con el equipo de analytics antes de activar el agente, para que las propuestas sean acertadas desde el primer batch.
Ownership por dominio para aprobar
Una CI sin owner queda huérfana. Solu acompaña la asignación de ownership por dominio para que cada propuesta tenga un revisor claro, y propone un workflow ligero de approval para evitar fricción.
Lineage activo para impactos downstream
Cambiar una CI sin saber qué dashboard depende de ella rompe reportes. Solu mantiene lineage activo y notifica a consumers afectados antes de aplicar cambios o deprecaciones.
Naming convention para CIs
Sin naming, la library se vuelve ilegible. Solu propone una convención (ej. dominio_metrica_ventana) y la enforcea desde el agente, lo que mejora discovery y reuso.
Refresh policy adecuada
Refresh real-time para una métrica que solo cambia día a día es desperdicio. Solu calibra el refresh por CI según cómo y cuándo cambian los datos upstream y cómo lo consume cada destino.
Preguntas Frecuentes
No. El agente cubre la propuesta inicial, la validación sobre sample y el monitoreo de drift. La aprobación de fórmulas, la definición de business logic ambigua y la decisión de cómo medir un KPI nuevo siguen siendo del Analytics Engineer humano. El agente le devuelve tiempo para análisis y diseño.
Sí. Cuando un Data Graph materializa una relación (Customer ↔ Order ↔ Product), el agente puede componer CIs sobre ese graph para obtener latencias bajas. Es la combinación recomendada para métricas que requieren joins repetidos.
Antes de proponer una CI nueva, busca CIs equivalentes en el catálogo y en las fórmulas inline de dashboards. Si encuentra duplicación, propone una versión canónica y un plan de migración para reemplazar las versiones existentes.
Sí. Lee la telemetría de uso para detectar qué métricas se calculan repetidamente en dashboards. Cuando despliega una CI canónica, los dashboards pueden migrar a esa CI con cambio mínimo, manteniendo la coherencia entre herramientas.
El Trust Layer aplica masking según el rol del consumer. Si la CI agrega PII (cohorte, conteo), no expone valores individuales. Si la CI necesita PII a nivel registro, el agente fuerza permisos restringidos por rol y deja audit trail.
Cuando un DMO o una fuente cambia, el lineage avisa qué CIs dependen y el agente propone ajuste de fórmula si es necesario. La revisión la hace el Analytics Engineer y queda registrada con justificación.
El agente la detecta cuando los consumers caen bajo el threshold definido y propone retiro. Antes de remover, notifica a posibles consumers latentes y mantiene un período de gracia. Si nadie reclama, la CI se deprecia con audit trail.
Una library de Calculated Insights canónica y viva.
Hablá con un Solu Architect. Auditamos tu catálogo, tu glossary y diseñamos el primer batch de CIs canónicas para tu dominio crítico.