Calculated Insights and Segments: Catch Them Before They Cancel

The scenario

Arcline Mobile is a mid-size telco. Customers rarely call to complain before leaving — they just go quiet. Data usage drops for a month or two, then the porting request arrives. By the time churn shows up in a report, the customer is gone.

The retention team's ask is specific: "Give us a weekly list of accounts whose data usage is trending down hard, so we can hit them with a win-back offer while they're still customers."

Arcline already has the foundation from Part 1: daily usage records ingested into a Daily_Data_Usage__dlm DMO and identity resolution producing unified profiles. What's missing is the metric ("usage is declining"), the audience ("everyone whose metric crossed the line") and the delivery ("into the campaign tool, weekly"). In Data 360 those are exactly three features: a Calculated Insight, a segment and an activation.

What a Calculated Insight actually is

A Calculated Insight (CI) is a metric defined in ANSI SQL that Data 360 computes on a schedule and stores as its own queryable object. Think of it as a materialized view with rules:

• Every output column alias must end in __c.
• At least one column is a measure (a number you aggregate) and at least one is a dimension (what you group by — here, the customer).
• The result is stored and versioned per run, so segments and queries read precomputed values instead of re-scanning billions of engagement rows.

For beginners: a CI is to Data 360 what a roll-up summary field is to CRM — except it's SQL, it can span any DMOs, and it runs over lakehouse-scale data.

Write the insight

The metric Arcline wants: average daily data usage over the last 30 days, compared with the 60 days before that. In Data 360, open Calculated Insights → New → SQL Builder and define:

SELECT
    u.customer_id__c AS customer_id__c,
    AVG(CASE
        WHEN u.usage_date__c >= CURRENT_DATE - INTERVAL '30' DAY
        THEN u.data_used_mb__c
    END) AS avg_daily_mb_last_30__c,
    AVG(CASE
        WHEN u.usage_date__c <  CURRENT_DATE - INTERVAL '30' DAY
        THEN u.data_used_mb__c
    END) AS avg_daily_mb_prior_60__c
FROM Daily_Data_Usage__dlm u
WHERE u.usage_date__c >= CURRENT_DATE - INTERVAL '90' DAY
GROUP BY u.customer_id__c

Two measures, one dimension. A customer averaging 900 MB/day two months ago and 250 MB/day now is exactly who the retention team wants — and now that comparison is a stored fact, not a query someone has to remember to run.

Set the publish schedule to daily and run a preview before publishing — the SQL builder shows sample output, which is where you catch the classic mistakes: a missing __c on an alias, a dimension you forgot to group by, or a measure that isn't actually aggregated.

One more decision before publishing: batch or streaming. Batch CIs recompute on a schedule and suit metrics where "as of last night" is fine. Streaming insights compute continuously over engagement streams for signals that matter within minutes — a fraud flag, a cart abandoned mid-session. Arcline's churn signal moves on a weeks scale, so batch is the right call, and the cheaper one: streaming compute is metered continuously, and paying real-time prices for a slow-moving metric is a common early Data 360 mistake.

Build the segment

A segment is a saved audience definition over unified profiles. Once the CI has published, its measures appear in the segmentation attribute library like any other attribute. Arcline creates a segment on the Unified Individual:

1. New Segment → segment on Unified Individual, name it Declining Data Usage — Win-Back.
2. Drag in the CI attributes and set the rules: avg_daily_mb_last_30__c less than 60% of avg_daily_mb_prior_60__c, and avg_daily_mb_prior_60__c greater than 200 (so brand-new and dormant SIMs don't pollute the list).
3. Add guard filters from profile attributes: contract status is active, and the customer isn't in the last month of a fixed-term contract (those get a different journey).
4. Set the refresh schedule — every 24 hours here; segments can also refresh faster if the use case needs it.

Publish, and the count comes back: about 4,200 of Arcline's 1.9M subscribers currently match. That number alone told the retention team more than the quarterly churn report did.

Two habits make segments maintainable at scale. First, name them for the decision, not the mechanics — Declining Data Usage — Win-Back tells the next admin what it's for; Segment_CI_v3_final doesn't. Second, keep one segment per business action. When the same audience definition feeds an email journey, a call list and a service alert, resist forking it three times — one segment, three activations, so a threshold change happens in exactly one place.

Activate it

A segment sitting in Data 360 does nothing. Activation publishes its membership to an activation target — the system where action happens:

• Marketing Engagement: Arcline's primary path. The win-back journey (email + app push with a personalized data-pack offer) triggers on segment entry.
• File-based targets (Amazon S3): a weekly CSV for the outbound call vendor, with only the contact points the vendor needs.
• Back into the platform: segment membership and CI values can also drive CRM-side automation — Part 4 of this series wires a CI change to an Apex trigger for exactly that.

When you create the activation you choose which attributes ride along with each member — Arcline sends first name, preferred channel and the two usage averages, so the offer copy can say "your usage dropped from 900 MB to 250 MB a day" instead of a generic plea.

Did it work? Close the loop

Because the CI recomputes daily, measuring the campaign is one more query — no data science project required:

SELECT
    COUNT(ci.customer_id__c)              AS flagged_customers__c,
    AVG(ci.avg_daily_mb_last_30__c)       AS avg_usage_now__c,
    AVG(ci.avg_daily_mb_prior_60__c)      AS avg_usage_before__c
FROM Declining_Usage_Insight__cio ci
WHERE ci.avg_daily_mb_last_30__c
      < ci.avg_daily_mb_prior_60__c * 0.6

CI results live in objects with the __cio suffix and are queryable from the API, from Apex via ConnectApi.CdpQuery (shown in Part 1), and from dashboards (Part 5). Six weeks in, Arcline compared flagged customers who got the offer against a holdout group — the treated group's usage recovered at roughly twice the rate. That's the retention team's business case, generated by the same objects that run the campaign.

What you learned

• A Calculated Insight is scheduled ANSI SQL stored as a queryable object — measures, dimensions, __c aliases.
• Facts belong in the CI; thresholds and judgment belong in the segment, where they're cheap to change.
• Segments are audience definitions over unified profiles; activations publish them to targets with the attributes the target needs.
• CI outputs (__cio objects) are queryable, which makes measuring the campaign as easy as running it.

Next in the series: grounding Agentforce agents in Data 360, where unified profiles answer customer questions live in a conversation. The full series lives on the Data 360 track page.

Sources: Salesforce Help — Calculated Insights in Segmentation · Create Segments in Data 360 · Activation and Activation Targets