Salesforce Data Cloud Calculated Insights and SQL — Complete Guide 2026 | Module 08

Salesforce Data Cloud Calculated Insights and SQL Complete Guide 2026 | Module 08
☁ Data Cloud Complete Guide — Module 08

Calculated Insights & SQL
Complete Guide 2026

Master the SQL-powered metrics engine of Salesforce Data Cloud — build LTV, RFM, churn scores, engagement scores and any business metric directly on customer profiles

📅 Updated May 2026 ⏲ 20 min read 🎓 Beginner to Advanced 🆕 Module 8 of 15
Course Progress
Module 8 / 15
📍 What Are Calculated Insights?
The SQL-powered metrics engine that makes profiles intelligent

Calculated Insights are SQL-defined aggregation queries that run against DMO data and store the computed results directly on Unified Customer Profiles. They are the mechanism that transforms raw transactional and behavioral data into meaningful business metrics — Customer Lifetime Value, churn probability, purchase frequency, email engagement score and any other metric your business needs.

The key word is pre-computed. Instead of recalculating a customer's LTV every time a segment filter, Agentforce query or personalization request asks for it — Data Cloud computes it once on a schedule and stores the result on the profile. The next time anyone needs that LTV value it is retrieved instantly from the profile rather than computed on demand.

This architecture makes Data Cloud fast at scale. Computing the LTV of 10 million customers in real-time on every segment evaluation would be impossibly slow. Pre-computing it nightly and storing the result means every segment, every AI query and every API call gets the answer in milliseconds.

💡 Real World Analogy

Calculated Insights Are Like a Bank Credit Score

A bank does not recalculate your credit score every time you apply for a loan, use your card or check your balance. That would take hours. Instead the bank runs a complex calculation across your entire financial history on a scheduled basis — nightly or weekly — and stores the result as a single credit score number on your file.

The next time you apply for a credit card, the bank retrieves that pre-computed score instantly. The complex calculation already happened. The answer is already there.

Calculated Insights work the same way. A complex SQL query computes your LTV from 3 years of order history once per night. The result — 234,500 rupees — is stored on your Unified Profile. Every segment filter, AI query and personalization system retrieves that pre-computed number instantly without running the SQL again.

📍 Why Pre-Computing Matters — The Performance Case
Understanding why Calculated Insights exist as a concept

Consider what would happen if Calculated Insights did not exist and every segment had to compute LTV on the fly. A segment query filtering for customers with LTV greater than 50,000 rupees would need to join the Unified Individual DMO to the Sales Order DMO, SUM all order amounts per customer, filter for those above the threshold and return the matching profiles — every time the segment refreshes.

For a company with 10 million customers and 500 million order records — this query would take minutes to hours. If 50 segments all need LTV they each run this massive query independently. The entire Data Cloud system becomes paralyzed by repeated expensive computations.

Calculated Insights solve this by running the expensive computation once per schedule cycle and storing the result. The 10 million LTV values are computed overnight. In the morning every segment, every API call and every Agentforce agent retrieves pre-computed LTV from the profile in milliseconds — zero redundant computation.

📍 Architecture Principle

Calculated Insights follow the compute once, retrieve many principle. The SQL computation is expensive but happens on a controlled schedule. The retrieval is cheap and happens as many times as needed. This is what makes Data Cloud viable at billions of records — expensive aggregations are pre-computed and cached on profiles, not recalculated on every access.

📍 Dimensions vs Measures — The Critical Distinction
The most important concept to understand before writing any Calculated Insight SQL

Every Calculated Insight SQL query produces two types of output columns — Dimensions and Measures. Understanding this distinction is essential because it determines how the Insight is stored on the Unified Profile and how it can be used in segment filters.

📌 Dimensions — GROUP BY Fields
The fields that define the granularity of the insight
Always appear in the GROUP BY clause
Identify WHICH customer the metric belongs to
Example: Unified Individual ID
Example: Product Category (for per-category insights)
Example: Month (for monthly insights)
Cannot be aggregated — they are the anchor fields
📊 Measures — Aggregated Values
The actual computed metric values
Always use an aggregate function — SUM, COUNT, AVG, MAX, MIN
The answer to the business question being asked
Example: SUM(order_amount) AS lifetime_value
Example: COUNT(order_id) AS total_orders
Example: AVG(order_amount) AS avg_order_value
These are the numbers stored on the Unified Profile
⚠️ Interview Trap

Interviewers frequently ask — what happens if you forget the GROUP BY clause in a Calculated Insight query? The SQL will fail or return one aggregated row for the entire dataset instead of one row per customer. The GROUP BY on the Individual ID (or Unified Individual ID) is what makes each computed metric belong to a specific customer. Without it, you get one number for all 10 million customers combined — not one number per customer.

📍 The 5 Most Important Calculated Insights
The metrics every Data Cloud implementation uses
💵
Customer Lifetime Value (LTV)
SUM(order_amount) per customer
Total revenue from a customer across all time. Used to identify VIP customers, determine retention priority and personalize offers. The single most important business metric in any CDP.
🎯
RFM Score
Recency + Frequency + Monetary value
Combines days since last purchase, number of purchases and total spend into a composite customer score. Champions, Loyal, At Risk, Lost — four segments from one insight.
📨
Email Engagement Score
Weighted opens + clicks / emails sent
Measures how actively a customer engages with marketing emails. High scores indicate marketing-receptive customers. Low scores trigger re-engagement campaigns or channel switch to SMS.
Churn Risk Signals
Days since last purchase + engagement decline
Pre-cursor to Einstein churn prediction. Tracks behavioral signals — purchase recency, engagement decline, support ticket frequency. High signal customers get proactive retention treatment.
🔄
Purchase Frequency
COUNT(orders) / months_as_customer
How often a customer purchases per month on average. High frequency customers get loyalty rewards. Low frequency customers get activation campaigns. Used for loyalty tier classification.
📍 SQL Deep Dive — Writing Calculated Insights Queries
The complete SQL reference for Data Cloud Calculated Insights

Data Cloud SQL Syntax Rules

  • Must query DMOs — you cannot query DLOs directly in Calculated Insights
  • Must have GROUP BY — aggregation per customer is mandatory
  • Must include Individual ID — the dimension that links each result to a Unified Profile
  • Aggregate functions required — SUM, COUNT, AVG, MIN, MAX, COUNT DISTINCT
  • ANSI SQL compatible — standard SQL syntax with Data Cloud-specific object names
  • DMO API names — use the Data Cloud API name of each DMO in the FROM clause
  • HAVING for post-aggregation filtering — filter on aggregate results after GROUP BY
  • Date functions supported — DATEDIFF, DATE_TRUNC, DATEADD, CURRENT_DATE
SQL FunctionUse in Calculated InsightsExample
SUM()Total of all values per customerSUM(TotalAmount) AS lifetime_value
COUNT()Count of records per customerCOUNT(OrderId) AS total_orders
COUNT(DISTINCT)Count of unique values per customerCOUNT(DISTINCT ProductCategory) AS categories_purchased
AVG()Average value per customerAVG(TotalAmount) AS avg_order_value
MAX()Highest value per customerMAX(OrderDate) AS last_purchase_date
MIN()Lowest value per customerMIN(OrderDate) AS first_purchase_date
DATEDIFF()Days between two datesDATEDIFF(day, MAX(OrderDate), CURRENT_DATE) AS days_since_purchase
DATE_TRUNC()Truncate date to periodDATE_TRUNC(month, OrderDate) AS order_month
CASE WHENConditional classificationCASE WHEN days_since_purchase < 30 THEN High ELSE Low END
HAVINGFilter after aggregationHAVING SUM(TotalAmount) > 10000
📍 8 Real Calculated Insight SQL Examples
Production-ready SQL for the most common business metrics
💵 Insight 1 — Customer Lifetime Value
Total revenue per customer across all time
The most fundamental business metric. Used for VIP segmentation, retention priority and offer personalization.
SELECT ssot__Individual__c AS individual_id, -- Dimension: links to Unified Profile SUM(ssot__TotalAmount__c) AS lifetime_value, -- Measure: total spend COUNT(ssot__Id__c) AS total_orders, -- Measure: order count AVG(ssot__TotalAmount__c) AS avg_order_value, -- Measure: average spend per order MAX(ssot__OrderedDate__c) AS last_order_date, -- Measure: most recent purchase MIN(ssot__OrderedDate__c) AS first_order_date -- Measure: first ever purchase FROM ssot__SalesOrder__dlm -- Sales Order DMO WHERE ssot__Status__c IN ('Fulfilled', 'Delivered', 'Completed') -- Exclude cancelled orders GROUP BY ssot__Individual__c -- One row per customer
🔄 Insight 2 — Purchase Frequency and Recency
How often and how recently each customer purchases
Combined with LTV this forms the foundation of RFM scoring for loyalty segmentation.
SELECT ssot__Individual__c AS individual_id, COUNT(ssot__Id__c) AS total_orders, DATEDIFF(day, MAX(ssot__OrderedDate__c), CURRENT_DATE) AS days_since_last_purchase, DATEDIFF(month, MIN(ssot__OrderedDate__c), CURRENT_DATE) AS months_as_customer, -- Purchase frequency: orders per month as customer CASE WHEN DATEDIFF(month,MIN(ssot__OrderedDate__c),CURRENT_DATE) = 0 THEN COUNT(ssot__Id__c) ELSE COUNT(ssot__Id__c) / DATEDIFF(month,MIN(ssot__OrderedDate__c),CURRENT_DATE) END AS orders_per_month FROM ssot__SalesOrder__dlm GROUP BY ssot__Individual__c
🎯 Insight 3 — Product Category Affinity
Which product categories each customer prefers
Enables category-specific recommendations and targeted campaigns for each product line.
SELECT sop.ssot__Individual__c AS individual_id, p.ssot__ProductCategory__c AS product_category, -- Dimension: category COUNT(sop.ssot__Id__c) AS category_order_count, -- Measure: orders in category SUM(sop.ssot__TotalLineAmount__c) AS category_spend, -- Measure: spend in category MAX(so.ssot__OrderedDate__c) AS last_category_purchase -- Measure: recency in category FROM ssot__SalesOrderProduct__dlm sop JOIN ssot__SalesOrder__dlm so ON sop.ssot__SalesOrder__c = so.ssot__Id__c JOIN ssot__Product__dlm p ON sop.ssot__Product__c = p.ssot__Id__c WHERE so.ssot__OrderedDate__c >= DATEADD(month, -12, CURRENT_DATE) -- Last 12 months only GROUP BY sop.ssot__Individual__c, p.ssot__ProductCategory__c -- One row per customer per category
📨 Insight 4 — Email Engagement Score
Weighted engagement score based on email interactions
Opens score 1 point, clicks score 3 points. Score divided by emails sent gives engagement rate.
SELECT ssot__Individual__c AS individual_id, COUNT(CASE WHEN engagement_type = 'Open' THEN 1 END) AS email_opens, COUNT(CASE WHEN engagement_type = 'Click' THEN 1 END) AS email_clicks, COUNT(CASE WHEN engagement_type = 'Bounce' THEN 1 END) AS email_bounces, COUNT(ssot__Id__c) AS total_emails_sent, -- Weighted engagement score: opens=1pt, clicks=3pts ( COUNT(CASE WHEN engagement_type = 'Open' THEN 1 END) * 1 + COUNT(CASE WHEN engagement_type = 'Click' THEN 1 END) * 3 ) * 100 / NULLIF(COUNT(ssot__Id__c), 0) AS email_engagement_score FROM ssot__EmailEngagement__dlm WHERE engagement_date >= DATEADD(day, -90, CURRENT_DATE) -- Last 90 days only GROUP BY ssot__Individual__c
⚠ Insight 5 — Churn Risk Signals
Behavioral signals that predict churn before it happens
Combines recency, order decline and engagement drop into a composite churn signal score.
SELECT so.ssot__Individual__c AS individual_id, DATEDIFF(day, MAX(so.ssot__OrderedDate__c), CURRENT_DATE) AS days_since_last_purchase, COUNT(CASE WHEN so.ssot__OrderedDate__c >= DATEADD(month,-3,CURRENT_DATE) THEN 1 END) AS orders_last_3_months, COUNT(CASE WHEN so.ssot__OrderedDate__c >= DATEADD(month,-12,CURRENT_DATE) AND so.ssot__OrderedDate__c < DATEADD(month,-9,CURRENT_DATE) THEN 1 END) AS orders_prior_period, -- Churn risk: high if 90+ days no purchase and declining orders CASE WHEN DATEDIFF(day,MAX(so.ssot__OrderedDate__c),CURRENT_DATE) > 90 THEN 'High' WHEN DATEDIFF(day,MAX(so.ssot__OrderedDate__c),CURRENT_DATE) > 45 THEN 'Medium' ELSE 'Low' END AS churn_risk_level FROM ssot__SalesOrder__dlm so GROUP BY so.ssot__Individual__c
🏠 Insight 6 — Days Since Last Purchase
Simple recency metric for win-back campaigns
The simplest but most powerful churn signal. Used for win-back campaign targeting at 30, 60, 90-day milestones.
SELECT ssot__Individual__c AS individual_id, MAX(ssot__OrderedDate__c) AS last_purchase_date, DATEDIFF(day, MAX(ssot__OrderedDate__c), CURRENT_DATE) AS days_since_last_purchase FROM ssot__SalesOrder__dlm WHERE ssot__Status__c != 'Cancelled' GROUP BY ssot__Individual__c HAVING MAX(ssot__OrderedDate__c) IS NOT NULL -- Only customers who have purchased at least once
🛍 Insight 7 — Average Order Value (AOV)
Average spend per transaction per customer
Used for upsell targeting. High AOV customers get premium product recommendations. Low AOV customers get bundle offers.
SELECT ssot__Individual__c AS individual_id, AVG(ssot__TotalAmount__c) AS avg_order_value, MAX(ssot__TotalAmount__c) AS highest_single_order, MIN(ssot__TotalAmount__c) AS lowest_single_order, COUNT(ssot__Id__c) AS total_orders, -- Order value tier classification CASE WHEN AVG(ssot__TotalAmount__c) >= 10000 THEN 'Premium' WHEN AVG(ssot__TotalAmount__c) >= 3000 THEN 'Mid-Range' ELSE 'Value' END AS order_value_tier FROM ssot__SalesOrder__dlm WHERE ssot__TotalAmount__c > 0 GROUP BY ssot__Individual__c
🏆 Insight 8 — RFM Score Classification
Combined Recency, Frequency and Monetary classification
The gold standard for customer segmentation. Champions, Loyal, At Risk, Lost, New customers all classified in one insight.
SELECT ssot__Individual__c AS individual_id, DATEDIFF(day,MAX(ssot__OrderedDate__c),CURRENT_DATE) AS recency_days, COUNT(ssot__Id__c) AS frequency, SUM(ssot__TotalAmount__c) AS monetary_value, -- RFM Segment Classification CASE WHEN DATEDIFF(day,MAX(ssot__OrderedDate__c),CURRENT_DATE) <= 30 AND COUNT(ssot__Id__c) >= 5 AND SUM(ssot__TotalAmount__c) >= 50000 THEN 'Champions' WHEN DATEDIFF(day,MAX(ssot__OrderedDate__c),CURRENT_DATE) <= 60 AND COUNT(ssot__Id__c) >= 3 THEN 'Loyal Customers' WHEN DATEDIFF(day,MAX(ssot__OrderedDate__c),CURRENT_DATE) > 90 AND COUNT(ssot__Id__c) >= 3 THEN 'At Risk' WHEN DATEDIFF(day,MAX(ssot__OrderedDate__c),CURRENT_DATE) > 180 THEN 'Lost Customers' WHEN COUNT(ssot__Id__c) = 1 THEN 'New Customers' ELSE 'Potential Loyalists' END AS rfm_segment FROM ssot__SalesOrder__dlm WHERE ssot__Status__c != 'Cancelled' GROUP BY ssot__Individual__c
📍 Setting Up Calculated Insights Step by Step
The exact process for creating a Calculated Insight in Data Cloud
01

Navigate to Calculated Insights in Data Cloud

From the Data Cloud app go to Insights → Calculated Insights → New. This opens the Calculated Insight editor with a SQL editor, output field configuration and schedule settings.

02

Name and describe your insight

Give the insight a clear business name like Customer Lifetime Value or Email Engagement Score. The name appears in the segment builder so business users must understand what it means without technical knowledge. Add a description explaining what the metric measures and how it should be used.

03

Write your SQL query

Write your SELECT statement in the SQL editor. Reference DMOs by their API names. Include the Unified Individual ID as a dimension. Use aggregate functions for all measure fields. Add WHERE clauses to filter relevant records and date partitioning to limit data volume. Use the Query Validator to check for syntax errors before proceeding.

04

Define output fields as Dimensions or Measures

For each column in your SELECT, mark it as either a Dimension or a Measure in the output configuration. Dimensions are the GROUP BY fields — Individual ID, product category. Measures are the computed values — LTV, order count. This classification determines how the insight integrates with segment filters and Agentforce.

05

Preview the output

Run the Preview to see sample output from the SQL query. Verify the values look correct — LTV amounts are reasonable, order counts make sense, date calculations are accurate. Check that the Individual ID dimension is populated for all rows. Fix any logical errors in the SQL before activating.

06

Set the refresh schedule

Configure when the Calculated Insight recomputes. Most insights should run daily — after the overnight DMO refresh cycle completes. Resource-intensive insights like complex RFM scoring on 50M+ records might run weekly to manage credit consumption. Align the schedule to when fresh data is needed for campaigns and decisions.

07

Activate and monitor

Activate the Calculated Insight. Monitor the first full run in the job history. Verify results are stored on Unified Profiles by querying a sample of profiles and checking the insight values appear. Once confirmed, the insight is available as a filter criterion in the segment builder and accessible via the Profile API.

📍 SQL Optimization for Performance
Writing Calculated Insight SQL that runs fast at scale
Optimization TechniqueWhy It HelpsExample
Filter early with WHEREReduces records before aggregation — less data to processWHERE OrderDate >= DATEADD(month, -12, CURRENT_DATE)
Use date partitioningOnly scan relevant time range — avoids full table scanWHERE event_date >= DATEADD(day, -90, CURRENT_DATE)
Avoid SELECT *Only fetch columns needed — reduces I/O significantlySELECT individual_id, SUM(amount) instead of SELECT *
Use HAVING to filter aggregatesOnly store results meeting minimum thresholdHAVING COUNT(order_id) >= 1 filters customers with no orders
Pre-aggregate with subqueriesReduce rows before expensive JOIN operationsAggregate order data before joining to product table
Chain Calculated InsightsBuild simple insights first, reference them in complex onesLTV insight feeds into RFM insight instead of recomputing
Schedule off-peakLarge compute jobs at 2 AM avoid business hour latencyDaily schedule at 02:00 after DMO refreshes complete
Limit DISTINCT operationsCOUNT DISTINCT is expensive — use only when necessaryUse COUNT instead of COUNT DISTINCT where duplicates not a concern
⚠️ Performance Warning

A Calculated Insight running a full table scan on 500 million engagement event records without date partitioning can take hours and consume enormous Data Credits. Always add a date filter to high-volume DMOs. For email engagement insights use the last 90 days. For purchase frequency use the last 12 months. Only LTV genuinely needs all-time data — and even then HAVING clauses that filter out customers with zero orders reduce the result set significantly.

📍 Real-World Calculated Insight Scenarios
How actual companies use Calculated Insights to drive business outcomes
🌎 Real-World Scenarios
Calculated Insights Driving Real Business Decisions

🛒 Retail — Tiered Loyalty Program Automation

A large fashion retailer automated their entire loyalty tier classification using Calculated Insights. Previously a data team manually ran monthly SQL reports to classify customers as Silver, Gold and Platinum based on annual spend. This took 3 days and was always outdated. They built a Calculated Insight computing annual LTV and average order frequency daily. A second insight classified each customer into a tier based on thresholds. A third segment activated tier-classified customers to Marketing Cloud. The loyalty tier in the customer's email footer updated automatically every time they made a purchase that crossed a threshold. The 3-day manual process became a 0-day automated overnight job. Customer satisfaction with loyalty communications improved 34% because tiers were always current.

🏭 SaaS — Account Health Score for Customer Success

A B2B SaaS company built a composite Account Health Score Calculated Insight combining product usage events, support ticket frequency and contract renewal proximity. The SQL joined three DMOs — product usage events, case history and opportunity data — and computed a weighted score from 0 to 100. Accounts scoring below 40 were flagged automatically as At Risk. A Data Action fired for At Risk accounts creating a high-priority task in Salesforce for the Customer Success Manager. The Agentforce agent had access to the health score via the Unified Profile and could warn a customer success manager “Account ACME Corp health score dropped from 72 to 38 this week — recommend scheduling a call.” Early intervention reduced churn by 31% for accounts that were flagged by the insight before renewal.

💉 Healthcare — Patient Engagement Score

A health system built a patient engagement score to identify patients likely to miss appointments or stop treatment. The Calculated Insight combined appointment attendance rate (attended vs scheduled), medication refill compliance rate and portal login frequency into a composite score. The SQL used conditional aggregation — COUNT CASE WHEN attended = true THEN 1 END divided by total appointments — for each metric. Patients with engagement scores below 50 were segmented for proactive outreach — reminder calls, simplified telehealth options and care coordinator follow-ups. The engagement score insight ran weekly and was accessible via the Profile API so care coordinators saw it directly in their case management system. Treatment completion rates improved 19% for patients proactively engaged based on low scores.

📍 Common Calculated Insight Mistakes
What goes wrong with Calculated Insights in real projects

Mistake 1: Forgetting the GROUP BY clause

The most common SQL error. Writing a SUM or COUNT without a GROUP BY returns one aggregated value for all customers combined — not one per customer. The Calculated Insight either fails with an error or returns a single row with the sum of all 10 million customers' orders. Always verify your GROUP BY includes the Individual ID dimension as the first and most important grouping field.

Mistake 2: Not adding date filters to high-volume event DMOs

Running a Calculated Insight on an Email Engagement DMO with 2 billion records and no WHERE clause date filter. The query scans every single row. It takes hours. It consumes thousands of Data Credits. It may time out entirely. Always add date filters to any DMO that contains time-series event data. Ask yourself — does the business need all-time data or just the last 90 days? Most engagement metrics lose relevance after 90 days anyway.

Mistake 3: Not classifying output columns as Dimensions or Measures

Skipping the Dimension and Measure classification step in the Calculated Insight setup UI. Without proper classification, Data Cloud does not know which columns are the grouping keys and which are the computed values. The insight may not link correctly to Unified Profiles — making the computed metrics invisible in the segment builder. Always explicitly mark the Individual ID column as a Dimension and all SUM/COUNT/AVG columns as Measures.

Mistake 4: Scheduling all Calculated Insights at the same time

Setting 20 Calculated Insights to all run at 6 AM. They compete for the same compute resources, slow each other down and may all fail due to resource contention. Stagger schedules — LTV runs at 1 AM, engagement score at 2 AM, RFM at 3 AM. Group dependent insights so they run in sequence — a composite score that depends on LTV must run after LTV completes, not simultaneously.

Mistake 5: Division by zero errors crashing the insight

Computing orders per month as COUNT(orders) divided by DATEDIFF(month, first_order, today) without handling customers who are exactly 0 months old — i.e. new customers who ordered today. Dividing by zero throws an error and the insight fails entirely. Always use NULLIF or a CASE WHEN to handle division by zero. NULLIF(denominator, 0) returns NULL instead of crashing when denominator is zero. A NULL result is far better than a failed insight job.

🧠 Quick Knowledge Check
Test your understanding of Module 08 — answers are in the content above!
Question 01
A Calculated Insight computing Customer LTV is returning one single number for the entire customer base instead of one LTV per customer. What is the most likely cause?
A. The SUM function is incorrect — should use COUNT instead
B. The GROUP BY clause is missing — no grouping by Individual ID
C. The WHERE clause is filtering out too many records
D. The DMO is not mapped to the Unified Individual
Question 02
In a Calculated Insight SELECT statement, the Individual ID field is a _______ and the SUM(TotalAmount) field is a _______.
A. Measure / Dimension
B. Dimension / Measure
C. Primary Key / Foreign Key
D. Attribute / Metric
Question 03
A Calculated Insight on an Email Engagement DMO with 3 billion rows is taking 6 hours to run. What is the most effective single optimization?
A. Add COUNT DISTINCT instead of COUNT
B. Add a WHERE clause date filter limiting to last 90 days
C. Change the GROUP BY to include email address
D. Remove the HAVING clause to reduce filtering
Question 04
A purchase frequency insight divides order count by months as customer. For a customer who signed up today their months_as_customer is 0. What happens without proper handling?
A. Data Cloud automatically skips new customers
B. Division by zero causes the entire Calculated Insight job to fail
C. The customer receives a frequency score of 0
D. The insight runs but excludes the new customer from results
Question 05
Why are Calculated Insights pre-computed on a schedule rather than computed on-demand when a segment filter requests them?
A. Data Cloud SQL does not support real-time query execution
B. Pre-computing once and storing the result is far faster at scale than running expensive SQL aggregations on demand for every segment evaluation
C. On-demand computation is not supported in Data Cloud
D. Segment filters cannot access SQL query results directly
✅ Answers

Q1: B — GROUP BY missing | Q2: B — Dimension / Measure | Q3: B — Add date filter WHERE clause | Q4: B — Division by zero crashes the job | Q5: B — Pre-compute once, retrieve many times instantly

🎤 Interview Questions for This Module
Calculated Insight questions that come up in real Data Cloud interviews
Q1
What are Calculated Insights in Salesforce Data Cloud and why do they use pre-computation instead of real-time querying?

Calculated Insights are SQL-defined aggregation queries that compute business metrics like LTV, churn score and purchase frequency against DMO data and store the results directly on Unified Customer Profiles. They use pre-computation rather than real-time querying because the SQL aggregations are expensive — computing LTV across 500 million order records for 10 million customers would take hours if run on demand. Pre-computing on a nightly schedule means the computation runs once, the results are stored on profiles and every subsequent segment evaluation, API call and Agentforce query retrieves the pre-computed answer in milliseconds. This follow the compute once, retrieve many principle that makes Data Cloud viable at enterprise scale. Real-time on-demand recomputation of these metrics would make every segment refresh impossibly slow and consume enormous Data Credits repeatedly.

One-Liner: "Calculated Insights pre-compute expensive SQL aggregations on a schedule and store results on profiles. Compute once at night, retrieve instantly for every segment, API call and Agentforce query. Real-time recomputation at scale would be impossibly slow and expensive."
Q2
What is the difference between a Dimension and a Measure in a Calculated Insight? Why does this matter?

A Dimension is a grouping field that appears in the GROUP BY clause — it defines who or what the metric belongs to. The Individual ID is always a dimension because it tells Data Cloud which customer each row of computed data belongs to. A product category can also be a dimension if you are computing category-level insights. A Measure is an aggregated computed value — the actual number that represents the metric. SUM of order amounts is a measure. COUNT of orders is a measure. AVG order value is a measure. This distinction matters because Data Cloud uses it to correctly link computed metrics to Unified Profiles — dimensions are the keys that establish the link and measures are the values stored on the profile. Incorrectly classifying a dimension as a measure or vice versa breaks the profile linkage and makes the insight unusable in segment filters.

One-Liner: "Dimensions are the GROUP BY fields — who the metric belongs to, like Individual ID. Measures are the aggregated values — the actual metric like LTV or order count. Data Cloud uses this classification to correctly link computed metrics to Unified Profiles."
Q3
Write a Calculated Insight SQL that computes Customer Lifetime Value and classifies customers into value tiers. Explain each part.

The query selects from the Sales Order DMO using its Data Cloud API name. The Individual ID field is selected as the dimension — this links each computed row to the right Unified Customer Profile. SUM of the total amount field gives lifetime value. COUNT of order IDs gives total order count. AVG of total amount gives average order value. MAX of order date gives the last purchase date using DATEDIFF to compute days since last purchase. A CASE WHEN statement classifies each customer into Premium, Standard or Value tiers based on their computed LTV. WHERE clause excludes cancelled orders to avoid inflating LTV. GROUP BY Individual ID ensures one output row per customer. The dimensions are Individual ID. The measures are lifetime value, total orders, average order value, days since last purchase and value tier. The insight would be scheduled to run nightly after the Sales Order DMO refresh completes so LTV always reflects orders up to the previous day.

One-Liner: "LTV insight: SELECT individual_id as dimension, SUM(amount) as lifetime_value measure, CASE WHEN to classify tiers, FROM Sales Order DMO, WHERE not cancelled, GROUP BY individual_id. Schedule nightly after DMO refresh."
Q4
A Calculated Insight that previously ran in 20 minutes is now taking 4 hours after the email engagement DMO grew significantly. How do you optimize it?

A sudden performance degradation from DMO growth almost always means the query is doing a full table scan with no date partitioning. My optimization approach follows a priority sequence. First I add a WHERE clause date filter — for email engagement, the last 90 days is almost always sufficient for business purposes and eliminates 80 to 95 percent of historical rows from the computation. Second I review the SELECT list to ensure I am not using SELECT star — only selecting the columns actually needed. Third I check for any COUNT DISTINCT operations which are computationally expensive — replacing with COUNT where uniqueness is not critical. Fourth I check if the insight is joining multiple large DMOs and consider pre-aggregating the higher volume DMO in a subquery before the join. Fifth I reschedule to run at 2 AM to avoid contention with other workloads. Finally I check whether this insight can be split into two simpler chained insights — a base LTV insight and a tier classification insight — which is easier to optimize than one complex monolithic query.

One-Liner: "Performance fix sequence: add date WHERE filter first — eliminates 80-95% of rows. Then remove SELECT star, reduce COUNT DISTINCT operations, pre-aggregate in subqueries before joins, stagger schedule to off-peak, and consider splitting complex insights into chained simpler ones."
Q5
How do Calculated Insights power Agentforce personalization? Give a specific example.

Calculated Insights power Agentforce by providing pre-computed metrics on the Unified Customer Profile that the AI agent accesses via the Data Graph before generating any response. Without Calculated Insights the agent would need to run complex aggregation queries in real-time during a conversation — which is too slow. With pre-computed insights the agent retrieves the results in milliseconds. A specific example is a customer service Agentforce agent for an insurance company. When a customer contacts support the agent queries the Data Graph which includes a Customer Value Score Calculated Insight that combines years as customer, annual premium paid and claims history. If the customer's value score is in the top 20 percent the agent's guardrails activate a priority response mode — offering to waive a processing fee or expedite a claim review. The agent says “As a valued long-term customer I can expedite your claim review to 48 hours instead of the standard 5 business days.” This personalization is only possible because the value score was pre-computed by a Calculated Insight and is instantly available on the profile — not computed during the live conversation.

One-Liner: "Calculated Insights pre-compute metrics like Customer Value Score that Agentforce retrieves via Data Graph in milliseconds. The agent uses these scores for real-time routing decisions and personalized responses — impossible without pre-computation during a live conversation."