04.04 · Concept
Activation States & Re-engagement
Store activation as state on the user rather than recomputing it, and trigger re-engagement from that state without spamming.
Activation should be stored as user state, not rediscovered from raw events whenever messaging runs. A small set of fields can record where the user is, when they crossed key thresholds, and when contact is allowed, so re-engagement is consistent, inspectable, and protected against repeated sends.
What this lesson answers
- how should activation state be stored on users
- how to re-engage stalled users without spam
- why not recompute activation from events every time
Notes
Activation is a product state, not a report you recalculate every time you want to send a message. A user record should carry fields such as activation_status, activated_at, activation_step, or reengagement_eligible_at so the rest of the system can make simple, consistent decisions. The important shift is from asking “does this user look activated right now?” to recording “this user crossed the activation threshold at this time.”
A useful mental model is a small state machine on the user. A new user might move from signed_up to started_setup, then to activated, or to stalled if they stop…
References
Common questions
- Why store activation status instead of calculating it from events?
- Events are still the source of history, but stored activation state is the product’s current decision about the user. It avoids every caller inventing its own query, reduces expensive scans, and prevents repeated messages when the same condition remains true over time.
- What fields belong on a user for activation and re-engagement?
- Typical fields include an activation status, the time activation happened, the current activation step, and the next time the user may be contacted. You may also store message-specific sent flags, last contacted time, and unsubscribe status so campaigns can make simple decisions.
- How do activation states prevent spamming stalled users?
- Messages should be driven by state transitions and timers, not repeated broad scans. When a user becomes stalled, the system can mark eligibility, check cooldowns and previous sends, then update contact state after sending. That makes each message explainable and prevents the same prompt being sent repeatedly.
Short definition: what is Activation States & Re-engagement?