Skip to main content

Consuming query results: who reads a Calculated Insight, and why they all read the same one

The retrieve-many half of compute-once-retrieve-many, made explicit. Where a Calculated Insight goes after it's computed — segments, activations, agents, analytics — and why every consumer inheriting the same grain and freshness is the point, not an accident.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

A Calculated Insight is only half a sentence. You compute a metric once — lifetime value, an engagement score, an order count per person — and then something reads it. This page is about the read: who consumes a CI or a query result, and the discipline that holds across all of them. The compute side has its own page (Calculated Insights); here the CI is finished, sitting there as a queryable object, and the question is where it goes next.

The throughline is one fact stated four ways: every consumer retrieves the same CI rather than recomputing it. That is the whole value of "compute once, retrieve many" (Data 360 (formerly Data Cloud) principles, principle 7) — and it cuts both ways. Get the grain and freshness right once and every consumer inherits them for free. Get them wrong once and every consumer inherits that, identically and silently. A CI is not a number on a dashboard; it's a number a segment, an activation, an agent, and a report are all standing on at the same time.

This page stays on the query side: the CI as an input, and who reads it. The mechanics of building a segment and wiring an activation live in their own subcategory — see Segmentation & Activation for the how. Here the subject is consumption.

Segments read a CI as a pre-computed attribute

The first consumer is segmentation. A segment that needs "customers with lifetime value over $5,000" does not recompute lifetime value while it evaluates — it references the CI that already holds it. The CI surfaces in the segment builder as a direct attribute you filter on, the same way a profile field would, except the value behind it was aggregated once at a grain you chose.

This is the cleanest illustration of why the grain decision is load-bearing. If the LTV insight is computed per unified individual, the segment filters people. If it was accidentally computed at a finer grain — per order, per household — the filter quietly means something else, and nobody filtering on it can see that from the segment canvas. The segment trusts the CI's grain completely; it has no way not to.

So the question a segment inherits is the one the CI already answered: at what grain is this metric true, and is that the grain this audience needs? The segment can't fix a grain mismatch — it can only inherit it. (The mechanics of dragging that attribute onto the canvas and the operators available belong to Segmentation & Activation; what matters here is that the segment reads the CI, it doesn't recompute it.)

Activations carry a CI value into the channel

Once a segment is built, activation is where its members — and the attributes that travel with them — leave Data 360 and do work somewhere. A CI is one of the things that can travel. A CI metric carried into an activation becomes a decision input or a personalization token in the destination: a journey decision split that branches on an engagement score, a message that interpolates a customer's tier or predicted value.

For Cleon, that destination is very often Marketing Cloud Engagement — a Data 360 segment activating into an MC Journey, with CI values riding along so the Journey can split and personalize on them (Data 360 principles, principle 8). The value the Journey branches on is the value the CI computed; the activation transports it, it doesn't recalculate it. A stale CI here means a Journey making yesterday's decision with full confidence today.

The discipline is the same one, one layer out: the activation inherits the CI's freshness exactly. If the CI refreshes daily and the Journey runs hourly, the Journey is making hourly decisions on daily data — not wrong everywhere, but wrong precisely when the customer changed in the last 24 hours, which is often the moment that mattered. The setup of the activation target, the attribute mapping, the schedule — all of that is Segmentation & Activation. The point here is narrower and harder to walk back: whatever freshness the CI has is the freshness the channel acts on.

Agents retrieve a CI — they don't recompute it

The most demanding consumer is an agent. Agentforce, or an external LLM grounded through a Data 360 retriever, reads a CI the same way everything else does — it retrieves the pre-computed value. It does not re-derive lifetime value from raw orders on the fly; it grounds on the number the CI already holds, the same number the segment and the activation are using. That consistency is the feature: the agent and the campaign agree because they read the same source.

Which means the agent inherits the CI's correctness with no judgment of its own. A human analyst handed a number with a 24-hour lag might caveat it — "this is as of last night." An agent grounding on the same stale CI states it flat, fluently, with the authority of the assistant. A wrong or stale CI doesn't make the agent hesitate; it makes the agent confidently wrong, which is worse than an agent that simply can't answer (Data 360 principles, principle 10).

Analytics and exports read the CI as a measure

The last class of consumer is the one that looks most like ordinary querying: reporting and data movement. Data 360 Reports expose CIs as measures you build dashboards on. BI tools — Tableau through the connector, CRM Analytics — read CI results to visualize them. And the Query API can pull a CI's rows out for an export, an integration, or an analysis in another system (the Query API).

The retrieve-many discipline shows up here as reconciliation. When the dashboard, the segment, and the agent all read the same CI, their numbers agree by construction — there is one definition of lifetime value and everyone quotes it. The moment someone recomputes "their own" LTV in a BI tool with a slightly different rule, you have two numbers that should match and don't, and an afternoon spent discovering both are "right" against different definitions. The CI exists precisely so that doesn't happen; reading it instead of re-deriving it is what keeps every surface telling the same story.

Reading a CI back is normal Data Cloud SQL — a single-object select against the Calculated Insight Object, no recomputation:

-- Retrieve a pre-computed CI. No aggregation here — the grain and the
-- numbers were fixed when the CI ran. Every consumer reads THIS, unchanged.
SELECT
  ci.buyer,
  ci.lifetime_value
FROM Customer_Lifetime_Value__cio ci
WHERE ci.lifetime_value > 5000
LIMIT 100;

The same caution that applies to any Query API pull applies to an export of a CI: large result sets paginate and big queries go async, so a caller that reads the first page and stops is exporting a fraction of the metric with no error to flag it (Query & Insights gotchas, gotcha 7). The CI is computed correctly; the export can still truncate it on the way out.

The one decision underneath all four

Segments, activations, agents, reports — four different consumers, one shared dependency. None of them recomputes the metric; all of them inherit whatever the CI decided. That is what "retrieve many" means in practice: the CI's grain and freshness are not local choices that each consumer can adjust, they are global facts every consumer is standing on.

So the leverage is entirely upstream. You do not tune correctness at the point of consumption — there is nothing to tune there; the segment reads what the CI holds, the agent reads what the CI holds, the report reads what the CI holds. You get the grain and the freshness right once, where the CI is defined, and every consumer is right for free. Get them wrong once, and the cheapest place to have fixed it was always the CI, never the four places that read it.

Related

Reference: