Skip to main content

Consumir resultados de query: quién lee un Calculated Insight, y por qué todos leen el mismo

La mitad de recuperar-muchas de computar-una-vez-recuperar-muchas, hecha explícita. Adónde va un Calculated Insight después de computarse — segmentos, activaciones, agentes, analytics — y por qué que cada consumidor herede el mismo grain y la misma frescura es el punto, no un accidente.

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

Un Calculated Insight es solo media oración. Computás una métrica una vez — lifetime value, un score de engagement, un conteo de órdenes por persona — y después algo la lee. Esta página es sobre la lectura: quién consume un CI o un resultado de query, y la disciplina que se sostiene a través de todos ellos. El lado del cómputo tiene su propia página (Calculated Insights); acá el CI ya está terminado, ahí sentado como objeto consultable, y la pregunta es adónde va después.

El hilo conductor es un hecho dicho de cuatro formas: cada consumidor recupera el mismo CI en vez de recomputarlo. Ese es todo el valor de "computar una vez, recuperar muchas" (principios de Data 360 (antes Data Cloud), principio 7) — y corta para los dos lados. Acertá el grain y la frescura una vez y cada consumidor los hereda gratis. Equivocalos una vez y cada consumidor hereda eso, idéntico y en silencio. Un CI no es un número en un dashboard; es un número sobre el que un segmento, una activación, un agente y un reporte están parados al mismo tiempo.

Esta página se queda del lado de la query: el CI como input, y quién lo lee. La mecánica de construir un segmento y cablear una activación vive en su propia subcategoría — ver Segmentación y Activación para el cómo. Acá el tema es el consumo.

Los segmentos leen un CI como atributo pre-computado

El primer consumidor es la segmentación. Un segmento que necesita "clientes con lifetime value mayor a $5.000" no recomputa el lifetime value mientras evalúa — referencia el CI que ya lo tiene. El CI aparece en el builder de segmentos como un atributo directo sobre el que filtrás, igual que un campo de perfil, salvo que el valor detrás se agregó una vez en un grain que elegiste.

Esta es la ilustración más limpia de por qué la decisión de grain carga peso. Si el insight de LTV se computa por individuo unificado, el segmento filtra personas. Si por accidente se computó en un grain más fino — por orden, por hogar — el filtro pasa a significar otra cosa en silencio, y nadie que filtre sobre él puede verlo desde el canvas del segmento. El segmento confía por completo en el grain del CI; no tiene forma de no hacerlo.

Así que la pregunta que el segmento hereda es la que el CI ya respondió: ¿en qué grain es verdadera esta métrica, y ese es el grain que esta audiencia necesita? El segmento no puede arreglar un grain equivocado — solo puede heredarlo. (La mecánica de arrastrar ese atributo al canvas y los operadores disponibles pertenecen a Segmentación y Activación; lo que importa acá es que el segmento lee el CI, no lo recomputa.)

Las activaciones llevan un valor de CI al canal

Una vez construido el segmento, la activación es donde sus miembros — y los atributos que viajan con ellos — salen de Data 360 y hacen trabajo en algún lado. Un CI es una de las cosas que puede viajar. Una métrica de CI llevada a una activación se vuelve un input de decisión o un token de personalización en el destino: un decision split de un journey que ramifica sobre un score de engagement, un mensaje que interpola el tier o el valor predicho de un cliente.

Para Cleon, ese destino es muy seguido Marketing Cloud Engagement — un segmento de Data 360 activando a un Journey de MC, con los valores de CI viajando al lado para que el Journey pueda ramificar y personalizar sobre ellos (principios de Data 360, principio 8). El valor sobre el que el Journey ramifica es el valor que el CI computó; la activación lo transporta, no lo recalcula. Un CI stale acá significa un Journey tomando la decisión de ayer con plena confianza hoy.

La disciplina es la misma, una capa más afuera: la activación hereda la frescura del CI exactamente. Si el CI refresca a diario y el Journey corre por hora, el Journey está tomando decisiones por hora sobre data diaria — no equivocado en todos lados, sino equivocado justo cuando el cliente cambió en las últimas 24 horas, que suele ser el momento que importaba. El setup del target de activación, el mapeo de atributos, el schedule — todo eso es Segmentación y Activación. El punto acá es más estrecho y más difícil de revertir: la frescura que tenga el CI es la frescura sobre la que actúa el canal.

Los agentes recuperan un CI — no lo recomputan

El consumidor más exigente es un agente. Agentforce, o un LLM externo fundamentado a través de un retriever de Data 360, lee un CI igual que todo lo demás — recupera el valor pre-computado. No re-deriva el lifetime value a partir de órdenes crudas al vuelo; se fundamenta en el número que el CI ya tiene, el mismo número que usan el segmento y la activación. Esa consistencia es la feature: el agente y la campaña coinciden porque leen la misma fuente.

Lo que significa que el agente hereda la corrección del CI sin juicio propio. Un analista humano al que le pasan un número con un lag de 24 horas quizás le pondría un asterisco — "esto es a anoche". Un agente fundamentado sobre el mismo CI stale lo dice plano, fluido, con la autoridad del asistente. Un CI equivocado o stale no hace dudar al agente; lo hace equivocarse con seguridad, lo cual es peor que un agente que simplemente no puede responder (principios de Data 360, principio 10).

Analytics y exports leen el CI como measure

La última clase de consumidor es la que más se parece a consultar normal: reporting y movimiento de data. Los Data 360 Reports exponen los CIs como measures sobre los que construís dashboards. Las herramientas de BI — Tableau vía el connector, CRM Analytics — leen resultados de CI para visualizarlos. Y la Query API puede sacar las filas de un CI para un export, una integración, o un análisis en otro sistema (la Query API).

La disciplina de recuperar-muchas aparece acá como reconciliación. Cuando el dashboard, el segmento y el agente leen todos el mismo CI, sus números coinciden por construcción — hay una definición de lifetime value y todos la citan. En el momento en que alguien recomputa "su propio" LTV en una herramienta de BI con una regla apenas distinta, tenés dos números que deberían coincidir y no, y una tarde gastada en descubrir que ambos están "bien" contra definiciones distintas. El CI existe precisamente para que eso no pase; leerlo en vez de re-derivarlo es lo que mantiene a cada superficie contando la misma historia.

Leer un CI de vuelta es SQL normal de Data 360 — un select de un solo objeto contra el Calculated Insight Object, sin recómputo:

-- Recuperá un CI pre-computado. Acá no hay agregación — el grain y los
-- números se fijaron cuando el CI corrió. Cada consumidor lee ESTO, sin cambios.
SELECT
  ci.buyer,
  ci.lifetime_value
FROM Customer_Lifetime_Value__cio ci
WHERE ci.lifetime_value > 5000
LIMIT 100;

La misma precaución que aplica a cualquier pull de la Query API aplica a un export de un CI: los result sets grandes paginan y las queries grandes van async, así que un caller que lee la primera página y para está exportando una fracción de la métrica sin ningún error que lo marque (gotchas de Query e Insights, gotcha 7). El CI está computado bien; el export igual puede truncarlo en la salida.

La única decisión debajo de las cuatro

Segmentos, activaciones, agentes, reportes — cuatro consumidores distintos, una dependencia compartida. Ninguno recomputa la métrica; todos heredan lo que el CI decidió. Eso es lo que significa "recuperar muchas" en la práctica: el grain y la frescura del CI no son decisiones locales que cada consumidor pueda ajustar, son hechos globales sobre los que cada consumidor está parado.

Así que la palanca está toda aguas arriba. No ajustás la corrección en el punto de consumo — no hay nada que ajustar ahí; el segmento lee lo que el CI tiene, el agente lee lo que el CI tiene, el reporte lee lo que el CI tiene. Acertás el grain y la frescura una vez, donde el CI se define, y cada consumidor queda correcto gratis. Equivocalos una vez, y el lugar más barato donde haberlo arreglado fue siempre el CI, nunca los cuatro lugares que lo leen.

Relacionado

Referencia: