Skip to main content

Calculated Insights: la métrica que computás una vez y recuperás en todos lados

Qué es un Calculated Insight: una agregación definida por dimensiones y measures — no un SELECT arbitrario — pre-computada una vez y servida en todos lados como un Calculated Insight Object consultable. Batch vs streaming, los límites reales de cada uno, la frescura que vuelve el resultado confiable o silenciosamente incorrecto, y el dialecto SQL separado con el que lo creás.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Un Calculated Insight es la respuesta a una pregunta que de otro modo harías una y otra vez, computada una sola vez y guardada para que cada consumidor recupere el mismo número en lugar de re-derivarlo. Es el principio 7 de la tesis de Data 360 (antes Data Cloud) hecho concreto — computá una vez, recuperá muchas. Lifetime value por cliente, un engagement score, órdenes por persona: definilo como un CI, y el segmento, la activación y el agente leen un resultado en vez de tres ligeramente distintos.

Esta página es la referencia de qué es un CI — no de cómo consumirlo (eso está en consumir resultados de query) ni del dialecto con el que lo volvés a leer (eso está en Data Cloud SQL). Crear un Calculated Insight es su propia superficie, con su propio dialecto SQL y su propia forma. La forma es el punto entero: un CI no es un query que aliaseás como tabla, es una agregación con un grain declarado.

Un CI es dimensiones y measures, no un SELECT arbitrario

El modelo mental que engaña es "un Calculated Insight es un query guardado". No lo es. Un CI es una agregación definida por dos cosas, y solo dos:

  • Dimensiones — los campos por los que agrupás. Las dimensiones son el grain: una fila del resultado por cada combinación única de valores de dimensión. Agrupás por buyer y obtenés una fila por buyer; agrupás por buyer y mes y obtenés una fila por buyer por mes. Elegir las dimensiones es elegir qué significa cada fila del insight.
  • Measures — las agregaciones que computás en ese grain. COUNT, SUM, COUNT(DISTINCT …), MIN/MAX sobre las filas que caen en cada grupo.

No hay un SELECT * arbitrario, ni passthrough a nivel de fila, ni "dame los registros nomás". Un CI es GROUP BY por construcción, y el grain es una decisión que tomás a propósito — porque cada consumidor lo hereda.

-- Un Calculated Insight ES dimensiones + measures. El grain es la decisión.
-- Dimensión: una fila por buyer. Measures: su cantidad de órdenes y lifetime value.
-- Agrupá por la dimensión equivocada y cada consumidor hereda el número equivocado.
SELECT
  o.ssot__BuyerId__c                AS buyer,          -- dimensión: el grain
  COUNT(DISTINCT o.ssot__Id__c)     AS order_count,    -- measure
  SUM(o.ssot__GrandTotalAmount__c)  AS lifetime_value  -- measure
FROM ssot__SalesOrder__dlm o
GROUP BY o.ssot__BuyerId__c;

Equivocá el grain — agrupá por la key equivocada, o SUM donde necesitabas COUNT(DISTINCT …) — y el número está mal en todos lados donde se recupera, consistente y silenciosamente. Ese es el doble filo de computar-una-vez-recuperar-muchas: una definición correcta propaga la correctitud a cada consumidor, y una definición incorrecta propaga el error con la misma fidelidad.

Una nota sobre traversal: el ejemplo de arriba agrega un solo objeto, que es como un CI ilustra más limpio. Los CIs reales muchas veces cruzan objetos — las órdenes de un buyer atadas de vuelta a la persona resuelta. Esos joins funcionan solo donde el modelo ya los tiene, y un objeto source nunca se une directo a UnifiedIndividual__dlm; el camino pasa por el bridge IndividualIdentityLink__dlm que mantiene la resolución de identidad. Modelá la relación primero, después el CI puede traversarla (ver Data Cloud SQL sobre joins modelados).

Batch y streaming: dos motores, límites distintos

Un CI corre en uno de dos modos, y son herramientas genuinamente distintas — no una versión rápida y una lenta de lo mismo.

Batch — agendado, poder expresivo completo

Un CI batch recomputa con un schedule, con una cadencia que seteás tan fina como cada hora o tan gruesa como una vez cada 24 horas. A cambio de no ser real-time, te da la superficie expresiva completa: agregación relacional, multi-objeto, sobre horizontes temporales largos, la historia completa de la data, los agregados que esperarías. Lifetime value, cantidad de órdenes de todos los tiempos, un engagement score sobre meses — estas son métricas batch, porque necesitan historia y no necesitan ser frescas al sub-minuto. Batch es el default y el que vas a usar la mayoría de las veces.

Streaming — continuo y de baja latencia, con restricciones reales

Un CI streaming actualiza continuamente a medida que llegan los engagement events, con latencia en segundos a minutos en vez del intervalo de refresh. Esa velocidad se paga con límites duros, y agarrar streaming porque "real-time es mejor" sin conocerlos es el error clásico:

  • No puede hacer join con Unified Profiles. Un streaming insight evalúa el stream de eventos entrante; no alcanza el perfil resuelto. Si tu métrica necesita un atributo del unified individual, streaming no lo puede expresar.
  • Opera solo dentro de una ventana de tiempo definida — sin métricas de lifetime. Cada CI streaming declara una ventana, de 5 minutos hasta 24 horas, y computa solo dentro de ella. "Clicks en los últimos 30 minutos" es una métrica streaming; "clicks de todos los tiempos" no es posible en streaming, por diseño.
  • Ve solo los eventos entrantes, no la historia completa. Streaming agrega los eventos que fluyen durante la ventana. No tiene vista de lo que pasó antes de que arrancara el stream ni fuera de la ventana.
  • Soporta solo SUM y COUNT, usados con una función WINDOW. La superficie de agregación es deliberadamente angosta: SUM y COUNT sobre la ventana, expresados con WINDOW.START / WINDOW.END y una cláusula WINDOW(…). La agregación multi-objeto rica que permite batch no está sobre la mesa.
  • Agrega aproximadamente cada 5 minutos, hasta el techo de ventana de 24 horas.

Frescura: un CI está exactamente tan fresco como su última corrida

Entre corridas, un CI sirve el último resultado que computó. Ese es el valor entero de la pre-computación — y su riesgo entero. Un CI batch refrescado a diario que alimenta una decisión en tiempo real está sirviendo un número que puede tener hasta un día de antigüedad, y nada en el consumidor lo dice. El segmento lo lee, el agente lo recupera, y ambos tratan un agregado viejo como verdad actual.

Un insight viejo no es una respuesta faltante — es una respuesta confiadamente incorrecta, que es peor. Un resultado vacío hace dudar a un consumidor; un número plausible-pero-viejo no. La frescura es una propiedad de la cadencia del CI, no del momento en que lo leés, así que la cadencia tiene que coincidir con la decisión más fresca que el CI alimenta.

Un CI es un objeto consultable: el Calculated Insight Object

Una vez definido, un Calculated Insight se expone como un Calculated Insight Object (CIO) — una tabla consultable de sus dimensiones y measures. Hacés SELECT sobre él igual que sobre cualquier DMO, en el dialecto Data Cloud SQL común, y te devuelve las filas pre-computadas:

-- Leer un CI de vuelta es Data Cloud SQL común sobre el CIO.
-- Recuperás el resultado pre-computado; no lo recomputás.
SELECT
  ci.buyer,
  ci.lifetime_value
FROM Customer_Lifetime_Value__cio ci
WHERE ci.lifetime_value > 1000
ORDER BY ci.lifetime_value DESC;

Este es el lado de lectura, y sigue cada regla que la página del dialecto plantea — identificadores con namespace, aliasing, el mismo comportamiento de cláusulas. El resultado ya está computado; el query solo lo trae.

Dos dialectos SQL, no uno

Lo más importante para tener claro: crear un Calculated Insight usa un dialecto SQL distinto del que usás para leerlo de vuelta. La propia documentación de Salesforce lo dice sin vueltas — la creación de calculated insights usa un dialecto SQL distinto del que describe la Query Guide. El dialecto de autoría tiene sus propias reglas (y, para streaming, la sintaxis WINDOW de arriba); el dialecto del Query Editor y la Query API es la superficie ANSI-leaning documentada en la página de Data Cloud SQL.

No los confundas. Una función que anda cuando creás un CI puede no existir cuando consultás el CIO, y viceversa. El límite es limpio una vez que lo nombrás: creás un CI en un dialecto, lo recuperás en otro, y la página del dialecto hace el mismo punto desde el lado del query.

Quién consume un CI — recuperan, no recomputan

La razón por la que vale la pena definir un CI es lo que pasa downstream. Los segmentos, las activaciones y los agentes todos recuperan el resultado del CIO; ninguno recomputa la agregación. Ese es el contrato:

  • Segmentos filtran sobre las measures de un CI — "lifetime value mayor a 1.000" — sin re-correr la agregación en cada refresh.
  • Activaciones llevan los valores de un CI al sistema destino como atributos.
  • Agentes — Agentforce o un LLM externo — fundamentan sus respuestas en el número del CI, recuperándolo exactamente como lo definiste.

Cada consumidor hereda el grain del CI, su frescura y su correctitud, sin cambios. Un CI definido en el grain correcto y refrescado en la cadencia correcta es un número en el que toda la org puede confiar; uno incorrecto es un número en el que toda la org confía igual — incluido el agente, que va a responder con confianza desde él. Cómo lee cada consumidor un CI es su propia página: ver consumir resultados de query.

Relacionado

Reference: