Behavioral email connects a product event to a message decision. A useful trigger has an event source, eligibility rule, timing window, suppression rule, and success metric. Without those controls, event-driven email turns into noisy automation that users learn to ignore.
last updated 2026-05-074 sections
section 01
Trigger types
Most lifecycle triggers fall into five groups: did, did-not, threshold, sequence, and inactivity. Naming the trigger type makes the send rule easier to test.
trigger type
example
common suppression
Did
User invited a teammate.
Do not send if account is already activated.
Did-not
User signed up but did not connect data.
Stop after the action completes.
Threshold
Usage passed a limit or dropped below a floor.
Cap to one send per window.
Sequence
Trial day or onboarding step changed.
Exit when lifecycle stage changes.
Inactivity
No meaningful action in a defined period.
Suppress recent support contacts.
section 02
Timing windows
Immediate sends work for security and transactional flows. Lifecycle sends often need a delay so the user can finish the action naturally. The delay should match the behavior, not a generic drip schedule.
trigger
timing rule
reason
Abandoned setup
Delay until the normal setup window has passed.
Avoid interrupting active users.
Feature adopted
Send after first successful use.
Reinforce the next logical step.
Usage drop
Wait for a full usage cycle.
Avoid false positives from weekends or holidays.
Trial expiration
Send before access changes.
Give the buyer time to act.
section 03
Suppression and caps
A trigger should declare who must not receive it. Suppression is not only unsubscribe handling. It includes recent sends, lifecycle state, account role, plan type, support status, and known deliverability risks.
okCap repeated triggers per user and per account.
okExit the user when the target action completes.
okSuppress users with recent complaints or hard bounces.
okDo not send lifecycle prompts to users who cannot perform the action.
okPrefer account-level caps when several teammates can trigger the same email.
section 04
QA before launch
Behavioral email should be tested with synthetic events and real staging accounts. The test is not only whether the email renders. It is whether the right user gets one message at the right time.
okFire the event twice and confirm one send if dedupe is expected.
okComplete the target action before the delay expires and confirm no send.
okTest account-level role rules.
okTest unsubscribe, suppression, and bounced-recipient paths.