Segment count far below expectations because of refresh dependencies
Marketing built a high-value lapsed segment: customers with calculated insight Lifetime Value of at least 750, no purchase in 90 days, and at least one consented email. The LTV insight reads from the Sales Order DMO and refreshes weekly on Sunday. The segment refreshes daily at 06:00. Identity resolution runs weekly on Saturday. The source order stream is near real-time. Segment preview shows 11,800 members, but finance's list of high-value lapsed customers is 46,000. Analysts notice that many known high-value customers are missing, and some members have no order in the last 90 days because the order date field is blank in the unified profile.
1. Diagnose the 11,800 versus 46,000 gap. List the most likely causes in order of impact and how you would confirm each.
Read the worked answer
The largest cause is likely the calculated insight refresh. LTV is computed weekly, so customers who crossed the 750 threshold after Sunday do not qualify until the next run. The segment refreshes daily against stale LTV values. The second cause is identity resolution running weekly: new source records and new order linkages are not unified until Saturday, so the segment sees incomplete profiles. Third, blank order dates create null behavior. A condition phrased as no purchase in 90 days may exclude records whose date is blank, depending on how the segment builder evaluates nulls. Fourth, the consent filter may be removing customers whose consent records are not linked to the unified profile.
Confirm in order: run the calculated insight manually and compare the segment count; run identity resolution and compare again; query a sample of missing customers and inspect their order date and consent records; compare segment preview with the published activation count. Fixing the first failing stage and re-measuring isolates the contribution of each cause.
2. Redesign the refresh chain. What order and cadence would you set for ingestion, identity resolution, calculated insight, segment, and activation?
Read the worked answer
Use a dependency chain, not independent schedules: ingestion, then identity resolution, then calculated insight, then segment, then activation. Near-real-time ingestion can stay as is, but identity resolution should run at least daily, ideally more often if new records matter for the segment. The calculated insight must run after identity resolution and before the segment, and its cadence should be at least daily for a daily segment. The segment should run after the insight completes, with a buffer for processing. Activation should run after the segment publishes.
Do not schedule everything at 06:00. Stagger the jobs and make the segment dependent on successful insight completion. If the business needs faster response to new high-value customers, increase insight frequency before increasing segment frequency; a faster segment over stale LTV values only produces the same wrong answer more often.
3. What would you change in the segment definition to avoid blank order dates and consent issues?
Read the worked answer
Make the lapsed condition explicit rather than relying on a null-sensitive date comparison. Decide whether never-purchased customers belong in a lapsed segment, and encode that decision. If they do not belong, require at least one completed order before evaluating recency. If they do, separate them into their own segment. Fix the DMO mapping that leaves order date blank, and validate that the field used by the segment is populated for the source records that should qualify.
For consent, require an active email consent record linked to the same unified individual, and verify that the consent data stream is mapped to the consent DMO and refreshed. Test the segment with a small known cohort: high-value customers with known consent, known opt-outs, and missing consent. The count should reconcile to that cohort before the segment is activated.