Lifecycle Experiments
Part of Lifecycle message rules and exclusions
Testing exclusion rules with sample customer histories
Use sample customer histories to verify sends, skips, holds, exits and unintended exclusions before a lifecycle journey goes live.
For each sample customer history, write the expected decision before comparing it with the configured workflow. Include one case where the message should send and cases where it should be withheld. An exclusion that blocks everyone can leave customers without useful help.
Build a decision table
For a proposed message, state the entry trigger, recipient, task, permission requirement, exclusion and the point at which the send is checked. Change one important fact at a time.
| Sample history | Expected decision | What it checks |
|---|---|---|
| Eligible recipient; task still open | Send if the message remains accurate | Over-broad exclusion. |
| Task completed before entry | Do not enter the reminder path | Entry rule. |
| Task completed during a delay | Skip the waiting reminder | Check near dispatch. |
| Completion event arrives late | Hold or reassess; do not assume failure | Occurrence and processing times. |
| Recipient opts out before a commercial send | Withhold that send | Current recipient permission. |
| Support issue opens during a wait | Hold or replace the routine message | Handover and expiry. |
| Same trigger arrives twice | Avoid an unintended second instance | Repeat-entry rule. |
| New, distinct task starts | Evaluate a new instance | Over-broad once-only block. |
Add cases that fit the product, such as a cancellation, another account member completing the task, or an order corrected after entry. For each case, state the expected send, skip, hold, replace or exit outcome and who resolves uncertain records.
Compare policy with configuration
First inspect source facts: identifiers, status and occurrence time. Apply the written rule to the history. Then compare the result with configured triggers, filters, delays, message conditions, exits and other sending queues. If they disagree, identify whether the record, rule or implementation needs correction.
A test email has a narrower purpose than a journey check. Customer.io’s test email uses selected sample-profile data to check rendering and substitutions. Event-triggered email previews require a profile with the relevant event.
Send events manually by uploading a CSV or from inside an automation with the Send Event action. Events can trigger automations, so control test identities and downstream sends. A content preview does not prove exclusions work.
Inspect the result
Check the journey log and the queued or delivered message for each case. In Customer.io, a failed action condition skips that action and continues the automation, so inspect later steps rather than treating the skip as an exit. Include other campaigns and sales or service tools when they can contact the same recipient.
Include a case where permission changes during a delay, then check it against the written rule and configuration.
Record expected and observed outcomes, configuration version, mismatch and owner of any fix. Repeat affected histories after changing a rule. After launch, inspect wrong sends and unexpectedly withheld help.
