Lifecycle Experiments
Part of Lifecycle experiments and holdouts
Testing journey timing without changing the offer
Compare two journey schedules fairly while keeping the offer fixed, using one assignment clock and a shared customer-outcome window.
To test timing, randomly assign eligible customers to two delivery schedules while keeping the offer, audience rule, channel and message content the same. Compare customer outcomes from a common starting event.
If the later group is measured only after its message arrives, progress made during its wait is lost from the timing comparison.
Define both schedules
Name the trigger and specify each planned delay, including the time zone and treatment of weekends or quiet hours. Choose times that answer a customer question: is help more useful immediately, or after the customer has had time to try the task?
Use the same approved offer and message version in both branches. If an offer expires before the later send, the branches no longer receive the same offer. Keep the landing experience and other eligibility rules consistent.
Record any necessary correction made during the test and assess whether it changes the comparison.
For example, an account-setup test could assign accounts at creation to an earlier or later prompt with the same instruction. If setup is confirmed before either send, that prompt can be skipped under the same rule in both branches. Record the skip; it is part of what that schedule delivered.
Journey Timing Test: Two Branch Schedules with Common Starting Event
- 0Trigger Event (Account Creation)
- 0minutesEarly Send (Branch A)
Use one outcome clock
Start the primary follow-up window at the qualifying event or assignment for both branches. Keep every assigned unit in its original timing group, including customers who finish before the later prompt is due. Report attempted sends, deliveries and skips separately.
Choose an outcome that timing could plausibly affect, such as verified task completion by the end of the shared window. A click counted for a set period after each message can diagnose engagement, but answers a different question and uses different calendar periods.
Inspect the actual time from assignment to attempted send. Quiet-hour settings or time windows can produce different waits for people entering near a boundary. Check whether another campaign or service contact fills the gap in one branch; if it does, the test no longer varies timing alone.
Key Elements of a Fair Timing Test
- Offer & Message Content
- Identical in both branches
- Assignment Clock
- Starts at trigger event for all customers
- Skip Logic
- Same rule applied if task completed before send
- Channel & Compliance
- Email/SMS compliant with ACMA spam guidelines
Check the paths and readout
Before launch, set the primary outcome, follow-up period, sample plan and decision rule. At readout, show assigned units, sends, skips and verified outcomes by schedule. Investigate materially different missing outcome data or unintended eligibility rules before crediting a schedule.
Messaging tools may offer random branches and delay controls; verify that each branch assigns the intended group and applies its planned delay. Customer.io can use a random-cohort branch to route people through different delays. Its related-object option can keep people linked to one object on the same path; a person linked to multiple objects of the selected type exits that automation at the cohort branch.
Check that this behaviour fits the assignment unit. Also confirm whether re-entry or changed allocation can move a customer between timing paths; do not assume a branch stays fixed across every journey instance.
For commercial email or SMS, check both schedules against ACMA guidance on avoiding spam.



