Segments and Enrichment for a B2B Equipment Manufacturer
Tailspin Equipment sells industrial parts to 60,000 business accounts. Segments are built from unified account profiles that include industry code, annual revenue band, and last purchase date. The marketing team wants a segment of 'high-value accounts at risk of churn' defined as revenue band A or B, no purchase in 180 days, and at least three support tickets in the last 90 days. A separate enrichment subscription appends firmographic data, but the vendor's industry codes do not match Tailspin's internal taxonomy, and about 15 percent of accounts receive no enrichment match. The team also wants to suppress accounts currently in an active sales opportunity, which lives in a separate system refreshed weekly.
1. How should the churn-risk segment be constructed, and what data dependencies must be resolved first?
Read the worked answer
The segment combines attributes from unified profiles (revenue band, last purchase date) with an activity signal (support tickets) and a suppression list (open opportunities). Resolve dependencies in order:
- Unify the activity data. Support tickets must be associated to the unified account profile; if ticket records lack a reliable account key, they must be matched or the rule will undercount.
- Confirm the date logic. 'No purchase in 180 days' should be evaluated against the segment refresh date, not a hardcoded date, so the segment stays correct as it refreshes. 'Three or more tickets in 90 days' needs a rolling window aggregation, not a lifetime count.
- Stage the suppression list. Load open opportunities into a table keyed by account and apply it as an exclusion in the segment. Because it refreshes weekly, align the segment refresh to run after the suppression load so the segment never includes accounts that just entered an opportunity.
- Build the rule as an AND of the qualifying conditions plus a NOT IN suppression, and validate counts against a manual sample before publishing.
Document each dependency so the segment is reproducible and its freshness is understood.
2. The enrichment vendor's industry codes conflict with Tailspin's taxonomy, and 15 percent of accounts get no match. How do you handle both issues in the segment design?
Read the worked answer
Treat the taxonomy mismatch and the unmatched population as separate design problems.
For the taxonomy: build an explicit mapping table from vendor codes to Tailspin's internal codes, owned and reviewed by the business, and apply it during enrichment ingestion. Do not attempt fuzzy string matching on industry labels - it produces silent misclassification. Where a vendor code has no sensible internal equivalent, map it to an 'unmapped' value rather than guessing.
For the 15 percent unmatched: decide the fallback explicitly. If internal industry and revenue data already exist for those accounts, prefer internal values and use enrichment only to fill gaps - this makes enrichment additive rather than authoritative. If internal data is missing too, those accounts fall into an 'unknown' bucket and should be excluded from the high-value segment or reported separately, never assumed into band A or B.
Finally, surface enrichment coverage as a segment quality metric so marketing understands that the segment covers a known subset of accounts, and revisit the vendor contract if the unmatched rate stays high.
3. Marketing wants the segment to refresh daily, but the suppression source is weekly. What do you recommend and why?
Read the worked answer
Align the effective refresh cadence to the slowest critical dependency, or decouple the two with explicit semantics.
Option A - refresh the segment daily but keep the weekly suppression snapshot: the segment's qualifying attributes update daily, while suppression may be up to seven days stale. That means an account could enter an active opportunity and still receive outreach for several days. If the business can tolerate that lag, document it; if not, it is unacceptable.
Option B - refresh the segment weekly, immediately after the suppression load: simplest and safest, but reduces responsiveness for the other criteria.
Option C - split the logic: refresh qualifying attributes daily and reapply suppression whenever it updates, so the published audience is always filtered by the latest suppression snapshot. This is the best balance if the pipeline can trigger a suppression reapplication on load.
Recommend Option C, with monitoring that alerts if the suppression load fails or is late, since a stale suppression list is the highest-consequence failure here. Whatever is chosen, record the freshness guarantee in the segment definition so downstream teams know what they are getting.