The Journey That Looped Overnight
A subscription service builds a re-engagement journey: event trigger on 'app_open' → wait 3 days → condition (opened in last 7 days?) → if no, send push → wait 2 days → send email. Re-entrancy is set to 'allow re-entry' with a 7-day window. During a promo week, app_open volume triples. Overnight, the email provider reports 9x normal volume, and some users receive the same email 4 times in 48 hours. The condition node uses a segment membership check that refreshes every 24 hours. Journey analytics show entry counts far exceeding unique users.
1. Explain the mechanism producing duplicate emails, separating the re-entry cause from the condition-staleness cause.
Read the worked answer
Two independent multipliers. (1) Re-entry: 'allow re-entry' with a 7-day window means every app_open re-enters the journey. With app_open tripling, the same user enters many times, each entering a fresh copy of the flow. (2) Condition staleness: the condition checks a segment that refreshes every 24h, so a user who did open recently may still be evaluated against a stale segment and pass the 'hasn't opened' branch. Together: many entries per user × stale condition that fails to filter them = duplicate sends. The 4 emails in 48h is consistent with multiple entries clearing the wait and hitting the stale condition. Neither cause alone explains 9x; it's the product.
2. What configuration changes stop the duplicates while preserving the re-engagement intent?
Read the worked answer
Fix re-entry first: change to 'no re-entry' or a window that exceeds the full journey duration (journey is ~5 days, so a 7-day window is too short given tripled volume - set it to at least the journey length plus buffer, or disable re-entry entirely for this flow). Second, make the condition evaluate recent activity, not a 24h-refreshed segment - use an event-based or near-real-time check so 'opened in last 7 days' reflects reality at evaluation time. Third, add a frequency cap on the push/email channel as a backstop. Validate with a controlled cohort before re-enabling. The intent (re-engage lapsed users) is preserved; you're removing the amplifiers, not the purpose.