Use case
Re-engage inactive users automatically
Model win-back as a journey: a timer transition detects users who have gone quiet, then sends a re-engagement email or survey. Because AscendKit owns the user record and product events, the journey reads real inactivity directly rather than syncing it from a separate automation tool.
How it works
- 1. Define inactivityDecide what 'went quiet' means for your product and rely on the events you already emit to AscendKit.
- 2. Add a timer branchIn the journey graph, add a timer transition that fires when a user has not produced an activation event within a window.
- 3. Send and measureSend a re-engagement email or survey at that node and track win-back rate in journey analytics.
When should a re-engagement email actually send?
On inactivity measured from the user's own last meaningful action, not on a fixed schedule. "Thirty days since they last created anything" is a re-engagement trigger; "the first of the month" is a newsletter.
The distinction matters because a batch send catches people who are active alongside people who churned, and the message that works for one insults the other. Nothing damages a relationship faster than "we miss you" arriving to someone who used the product yesterday.
Because journeys trigger on your own product events and read the same user record as auth, the condition is evaluated against live state. There is no window in which the email tool believes someone is dormant while your product knows they are not.
| Signal | Good trigger? | Why |
|---|---|---|
| Days since last login | Weak | Login is not value; people log in and do nothing |
| Days since last core action | Strong | Measures whether they got value |
| Days since signup | No | That is onboarding, not re-engagement |
| Calendar date | No | That is a campaign |
What should the sequence contain?
Fewer messages than you think, and an exit. Two or three well-spaced emails outperform a long sequence, because someone who ignored the first two is unlikely to be won by the fifth and increasingly likely to mark it as spam.
Lead with a reason to return that is specific to them — something in their account, something that changed since they left — rather than a generic feature announcement. The generic version reads as marketing and is treated as such.
Build the exit into the journey. If they return, they should leave the sequence immediately; if they reach the end without returning, stop rather than looping. Continuing to mail people who have clearly gone damages your sending reputation, and the suppression that follows affects your transactional email too.
FAQ
How does AscendKit know a user is inactive?
It reads the product events you send and uses timer transitions to branch on whether an activation event happened within a window — no external sync required.
Can re-engagement include a survey?
Yes. A journey node can trigger a survey to ask why a user disengaged, with the response attached to their record.
Related guides
- Add a waitlist to your SaaS — the other end again -- people who never activated in the first place.
- SaaS onboarding email sequence — the other end of the lifecycle, built the same way.
- Journeys CLI reference — defining triggers, timers, and exit conditions.
- AscendKit vs Customer.io — when a dedicated lifecycle platform is the better fit.
Start with one API key
Auth, email, surveys, and journeys share one user record, so you ship this without stitching vendors together.
Start free