Customer Insights — Data segments recompute when their source tables refresh. If your refresh schedule is hourly and your segment count is in the hundreds, you spend most of your compute budget rebuilding membership that did not meaningfully change. The capacity meter ticks up, the refresh window stretches, and downstream activations get stale. The platform calls this normal. It is fixable.
What a segment actually does
A segment is a saved query over the unified customer table. On every refresh of the unified table, every segment re-evaluates. The output is a membership list materialized into a segment-specific table. Downstream consumers — Customer Insights — Journeys, ad platform exports — pull from that materialized list.
The cost model:
- Refresh cost is roughly proportional to (segment count × unified table size × predicate complexity).
- Activation cost is proportional to changed membership rows.
- Storage cost is proportional to total segment membership across all segments.
When refresh frequency is too high or unified data churns on irrelevant fields, you pay full refresh cost for near-zero membership change.
Detect thrash
Pull the segment refresh log from the audit endpoint. For each segment, compute:
- Average rows in membership.
- Average rows added or removed per refresh.
- Churn ratio: (added + removed) / total members.
A healthy segment churns less than 5% per refresh in a stable customer base. Segments above 30% churn are either definitionally noisy or sitting on a thrash source.
import pandas as pd
def churn_analysis(refresh_log):
df = pd.DataFrame(refresh_log)
df['churn'] = (df['added'] + df['removed']) / df['members']
summary = df.groupby('segment_id').agg(
avg_members=('members', 'mean'),
avg_churn=('churn', 'mean'),
refresh_count=('refresh_id', 'count'),
compute_seconds=('duration_s', 'sum')
).sort_values('compute_seconds', ascending=False)
return summary[summary['avg_churn'] > 0.3]The output is your thrash hit list.
Three patterns of thrash
Pattern 1: time-window predicates that re-slice constantly. A segment “active in last 7 days” recomputes membership at every refresh because the window slides. Every refresh, yesterday’s edge cohort drops out, today’s edge cohort enters. Fix: lock the window to a day boundary so the segment changes only once per day.
Pattern 2: predicates on high-churn source columns. A column like last_session_timestamp updates every web hit. A segment that filters on it touches everyone. Fix: derive a stable column upstream — active_today boolean — that changes once per day, and filter on that.
Pattern 3: composite segments referencing each other. Segment B = members of A plus condition X. When A refreshes, B refreshes. If you have ten such dependents, A’s refresh costs 10x what it should. Fix: flatten dependencies or use measures instead of nested segments.
The fix is upstream, not in the segment
Most teams try to fix thrash by changing the segment definition. That helps only when the predicate itself is wrong. The deeper fix is upstream — stabilize the source columns so the segment has nothing new to react to.
The upstream pattern: add a derived column in the data unification step that snapshots high-churn signals onto daily boundaries:
{
"transformations": [
{
"name": "snapshot_activity",
"type": "computed_column",
"target": "active_today",
"expression": "iff(date(last_session_ts) = date(now()), 1, 0)",
"refresh_policy": "daily_at_00_05"
}
]
}The segment now filters on active_today instead of last_session_ts. Refresh cost drops by an order of magnitude because the column does not change within a refresh interval.
Refresh schedule is a budget, not a default
Customer Insights defaults to a refresh every few hours for many sources. The defaults assume your downstream needs the freshest data. Most segments do not. Marketing activations are typically daily. Sales prioritization is hourly at most. Set refresh per source, not globally.
The right pattern is tiered refresh:
- Transactional sources that drive sales prioritization: every 60 minutes.
- Behavioral sources that drive marketing: every 12 hours.
- Slow-changing sources (subscription state, demographics): daily.
If a segment references multiple sources, the segment runs at the union of their refreshes. So co-locating segments with their refresh tier matters.
Activation throttling
Even when membership genuinely changes, you do not always want to fire activations. A daily-batch ad platform export does not benefit from hourly refresh updates — it only reads once. For each activation destination, set a minimum interval. The activation runs at most every N hours, regardless of underlying refresh frequency.
activation:
destination: meta_ads
segment: high_value_engagers
min_interval: 24h
policy: latest_membershipThis pattern recovers a surprising amount of capacity in busy tenants.
Measures vs segments
When you want a number, use a measure, not a segment. Measures aggregate without materializing membership. If your stakeholders ask “how many customers are at-risk this week”, a measure beats a segment. The trap is using a segment because the UI surfaces it first.
See also
Read Customer Insights data unification pitfalls for upstream unification choices that determine segment cost — though that article focuses on Dataverse elastic tables, the unification step that feeds Customer Insights is shaped by the same kind of decisions. We have a dedicated unification piece scheduled.
Pixel notes
Build a “segment economics” view: rows are segments, columns are refresh-cost percentile, churn ratio, members, and a sparkline of recent membership trends. Sort by cost. The view is a forcing function for ownership; nobody owns the meter until they can see what each segment costs.
Key takeaways
- Segment thrash is upstream column churn meeting time-window predicates.
- Track churn ratio per segment; anything above 30% is suspect.
- Fix the upstream column, not the segment definition.
- Tier refresh schedules per source; do not default to global cadence.
- Throttle activations independently of underlying refresh.
