Treasure Data CDP's Journey Orchestration re-randomization assigns a profile to a new variant when the profile re-enters a batch Journey and reaches a configured A/B Test step. This capability helps recurring Journeys refresh Control and Treatment cohorts instead of keeping a profile in the same variant indefinitely. Re-randomization is configured separately for each A/B Test step, so other A/B Test steps in the Journey can continue to use Sticky assignments.
Re-randomization applies only when re-entry is permitted and the profile reaches the configured A/B Test step again. It does not move profiles that are already progressing through the Journey.
Re-randomization is best suited for recurring batch Journeys where refreshing cohort composition matters more than keeping individual profiles in the same variant across cycles.
Use re-randomization when you want to:
- Refresh the composition of Control and Treatment groups in a recurring Journey.
- Give profiles another opportunity to receive a Treatment on a later Journey cycle.
- Prevent a profile from remaining in the same variant indefinitely.
- Reassign profiles across all variants at each eligible re-entry.
Use Sticky assignment instead when profiles must remain in the same variant for the life of the Journey or when you need stable cohorts for winner selection or capped traffic.
Treasure Data CDP Journey Orchestration performs a new variant draw only when a profile is eligible to re-enter and reaches the configured A/B Test step again.
- A profile meets the Journey’s entry criteria.
- The profile reaches the A/B Test step and is assigned to a configured variant.
- The profile exits or completes the Journey according to the Journey’s configured logic.
- The profile becomes eligible to re-enter.
- The profile reaches the same A/B Test step again.
- Journey Orchestration performs a new assignment across all variants when Re-randomize on re-entry is enabled.
A new assignment is not guaranteed to be different from the previous assignment. For example, a profile assigned to Control in one cycle may receive Treatment in the next cycle, or may receive Control again by chance.
Before enabling re-randomization, verify the following:
- The Journey is a Batch Journey.
- The Journey’s re-entry setting allows profiles to return for the intended number of cycles.
- The Journey has exit, goal, suppression, or completion logic that releases profiles for re-entry as intended.
- A stable and unique profile identifier is available, such as
cdp_customer_id. - Cooldown, suppression, and frequency rules prevent excessive or conflicting communications.
- The A/B Test step does not use Profile Cap or Declare Winner.
Use the following steps to configure re-randomization for an A/B Test step in Treasure Data CDP Journey Orchestration.
- Open Treasure Console.
- Navigate to Audience Studio.
- Select the parent segment and open a batch Journey, or create a batch Journey.
- Open the Journey in draft mode.
- Select the A/B Test step, or create an A/B Test.
- Specify a stable Unique ID Field for the assignment, if one is not already configured.
- Define the variants and their allocation percentages.
- Select Re-randomize on re-entry as the assignment behavior.
- Connect each variant to the appropriate downstream action or activation.
- Save the A/B Test.
- Verify that the selected assignment behavior is displayed.

Variant percentages define assignment probabilities rather than fixed quotas. For example, a 20% / 20% / 60% split can produce different observed counts in each Journey cycle, especially with a smaller audience.
Treasure Data CDP Journey Orchestration supports two assignment behaviors for A/B Test steps: Sticky and Re-randomize on re-entry. Sticky preserves a profile's existing variant, while re-randomization performs a new draw across all configured variants on each eligible re-entry.
| Assignment behavior | First entry | Later eligible re-entry |
|---|---|---|
| Sticky | Assigns the profile to a variant | Keeps the profile in the previously assigned variant |
| Re-randomize on re-entry | Assigns the profile to a variant | Performs a new draw across all configured variants |
Re-randomization is full re-randomization. Control participates in the new draw; the capability is not limited to refreshing the Control group.
Treasure Data CDP Journey Orchestration supports re-randomization only for batch Journeys. Profiles already progressing through a Journey are not reassigned mid-Journey.
- Profile Cap is not supported on a re-randomized A/B Test step.
- Declare Winner is not supported on a re-randomized A/B Test step.
- Re-randomization does not provide a calendar-based reset policy; use the Journey’s re-entry cadence or a separate scheduling design when calendar boundaries are required.
- Existing Sticky A/B Test steps remain Sticky unless they are configured separately.
A profile can receive a different Treatment or offer on a later cycle. Add appropriate suppression, cooldown, and frequency controls before using re-randomization with customer-facing activations.
Validate re-randomization with a non-customer-facing observation activation before enabling customer-facing activations.
- Test with a non-customer-facing observation activation.
- Run at least two eligible Journey cycles.
- Confirm that the profile reaches the A/B Test step again after re-entry.
- Compare assignments using the stable profile identifier.
- Confirm that profiles already in the Journey are not moved mid-Journey.
- Review variant counts by cycle; do not expect exact percentages in every cycle.
- Confirm suppression and cooldown behavior before enabling customer-facing activations.
If Re-randomize on re-entry is not available in the A/B Test configuration, contact Treasure AI to request enablement for the relevant account and environment.