Journeys Logic, Best Practices, and FAQs

Journeys are powered by a series of Audiences and Computed Traits. This guide defines the logic used to create sequential campaigns.

By the end of this guide, you'll understand how and why users progress through your Journey. You'll also gain familiarity with the following key Journeys concepts:

• Journey entry conditions and step behavior
• How Segment evaluates Journeys step membership
• How real-time step membership works

Journeys begin with an entry condition that computes like standard Engage Audiences. This entry condition queries your customer data in Segment to find users who meet your specified criteria.

After users meet the Journey's entry condition, their progress through the Journey depends on satisfying the criteria of subsequent Journey steps.

Journey steps operate based on the following behaviors:

• Only the entry condition can backfill event data from before Journey publication.
• The entry condition requires no previous step membership.
• Post-entry condition step membership relies on users at some point entering the preceding step.
• When a user first joins a step, Segment adds a step_joined_time trait to their profile.
• Membership is calculated using Segment's Real-Time Compute System.
• Segment doesn't calculate Waits and Splits in real-time.

The combination of these traits, audiences, and business rules allows you to create an enforced funnel with the following implications:

• Users enter the Journey when they fulfill the entry conditions.
• Users can't re-enter the same Journey at an earlier step.
• Users can only move forward through a Journey.
• Users remain in a step indefinitely until they fulfill the next step's criteria.

To enter a Journey, users must satisfy the entry conditions.

To enter each subsequent step, three conditions must be true:

1. The user previously joined the parent step.
2. The user meets the next step's conditions.
3. The user satisfies wait conditions.

"Add a condition" steps operate like Engage Audiences. The defined conditions provide criteria for each step's membership.

When you add a "Wait" step to a Journey, Segment automatically includes wait times in the membership criteria of the next condition step. Journeys represents wait times in relation to the preceding_step_joined_time trait, which must be at least N time ago.

The following table summarizes the three step membership conditions and their equivalents in written logic:

For every step after the entry step, Journeys leverages the Engage real-time compute system.

When a user's traits change or they exceed time-based conditions (for example, "within 7 days"), they may no longer fulfill the conditions of a previously joined step. If a user joins a step but no longer meets its conditions, Journeys removes them from that step's preview and analytics. The user does, however, continue to progress through the Journey.

Consider the following example of Journey conditions for a cart abandonment campaign:

1. Entry Condition: User has clicked add to cart and purchases = 0 within the last 7 days.
2. Wait Time Condition: 5 days.
3. Step Condition: User is member of Example Audience A
4. Send to Destination

If a user makes a purchase during the wait time of 5 days, the system would automatically update membership to false for the audience created from the entry condition, Step 1. However, the user could still satisfy Step Condition 3 based on the three step membership conditions:

To maintain best practices and enforce your funnel, re-check or modify audience conditions that follow wait steps. For example, adding a purchases = 0 condition to Step 3 results in Segment not advancing users who made a purchase during the wait time:

1. Entry Condition: User has clicked add to cart and purchases = 0 in the last 7 days
2. Wait Time Condition: 5 days
3. Step Condition: User is member of Example Audience A and purchases = 0 in the last 7 days.
4. Send to Destination

Unless a Journey has an exit condition configured, Journey members permanently remain in Destination sync steps. Segment neither sends Audience Exit events to Destinations nor removes users from Destinations lists. Exit conditions will lead to users being removed from all Journey steps and Destinations.

When you create a multi-branch split, don't create overlapping conditions that might lead a user to qualify for more than one step at a time.

For example:

• In the case where a multi-branch split is based on the conditions registration form submitted and webinar attended, a user may satisfy both conditions, and therefore is eligible for both paths.
• To set a priority, branch 2 should then be who performed registration form submitted and did not perform webinar attended to ensure mutual exclusivity.

Add time windows when defining conditions to enforce funnel constraints in a journey, rather than using an unbounded event condition which operates on the entire history of the user profile. For example, to check if a user has completed an order since receiving an email triggered 7 days ago, use the condition "Order Completed at least 1 time within 7 days."

Unlike lists associated with Engage Audiences, users who are added to a journey list cannot be subsequently removed. Lists are typically associated with advertising campaigns, and you must take additional steps if you wish to ensure that users do not continue to be targeted with ads after they achieve some goal. A typical implementation pattern is:

1. Use a send to destination step to add users to the initial targeting list.
2. Create additional journey steps to model the conditions where a user should be removed from targeting. Create a second send to destination step for the removal list.
3. When configuring targeting conditions in the destination interface, use Boolean logic to include only those users who are in the initial list AND NOT in the removal list.

Save your journey in a draft state so that you can review before you publish it. Once you publish a journey, you cannot edit select portions of the journey and Journeys sends data to destinations.

Aside from the entry condition, all journey step conditions are triggered by future events and existing trait memberships. Event-based conditions only evaluate events that occur after the journey is published.

When you include historical data in a journey's entry condition, Unify identifies users who previously satisfied the entry condition and adds them to entry. For example, to evaluate if a user has ever used a discount code mid-journey, create and configure a Computed Trait to select for discount_used = true to use in your journey.

Including historical data doesn't impact any additional journey steps, however. To include historical data in post-entry conditions, use the following table to identify which conditions will automatically include historical data:

To include historical data based on custom traits or events that predate the journey, first build an Audience that includes the targeted data by following these steps:

1. Create a standard Engage Audience outside of the Journeys builder.
2. Add conditions that include the historical event or custom trait you want to include in the journey.
3. After you've created the Audience, return to Journeys and create a Part of an Audience condition that references the audience you created in Step 2.

For example, to include custom trait = ABC in a journey, create an Audience called ABC that includes that custom trait, then add the journey condition Part of Audience ABC.

Using the Part of Audience condition, Journeys then populates the custom trait as if it were using historical data.

Follow these best practices to test your journeys:

• While in the process of configuring a journey, use dev Spaces to model that journey without affecting production data.
• Connect a data warehouse to each step of the journey to test for success or failure of that step.
• For early version journeys, scaffold Send to Destination steps without connecting to your production advertising or messaging destinations.
• Verify individual users' progress through the journey in the Profile explorer view.

Segment recommends that the events configured as entry triggers for a journey aren't also emitted by actions performed within that same journey.

If you've set up a journey with the Re-enter every time event occurs setting, and a step in that Journey emits the triggering event, a profile might indefinitely re-enter the journey.

Regularly review your journey actions to ensure they don't re-trigger the journey's entry condition.

Segment deprecated classic Journeys on June 25, 2026. Users continue to move through existing classic Journeys until mid-2027, when Segment plans to deprecate them.

Segment recommends recreating your classic Journeys as Journeys v2, which start automatically when users perform specific actions on your website or app, prior to the planned deprecation.

Journeys run in real time, like real-time Audiences in Engage. This means that users will progress through Journeys as Segment receives new events.

Yes. Users must first exit a journey, however, before entering it again. To learn more about journey re-entry, read the journey re-entry section of the build a Journey page.

Journeys supports all Engage destinations, including Destination Functions. Read more in Send data to destinations.

When building a journey, if you check Use historical data, you can see the estimated number of users in the initial cohort.

Once published, Journeys displays the number of users in each step of the journey at any given time.

The data type you send to a destination depends on whether the destination is an Event Destination or a List Destination.

For Engage customers, users with either the Engage User or Engage Admin roles can create, edit, and delete journeys. Users with the Engage Read-only role are restricted to view-only access.

Journeys triggers audience or trait-related events for each email external_id on a profile. If a profile has two email addresses, you'll see two Audience Entered and two Audience Exited events for each journey step. Journeys sends both email addresses to downstream destinations.

It may take up to five minutes for a user profile to enter each step of a journey, including the entry condition. For journey steps that reference a batch audience or SQL trait, Journeys processes user profiles at the same rate as the audience or trait computation. Visit the Engage docs to learn more about compute times.

When you publish a journey, the entry step begins evaluating users in real time while the historical data backfill runs separately. If a user's events or traits span both real-time and historical data, they might qualify for the journey immediately, even if their full historical data would have disqualified them.

To prevent inconsistencies, you can manually create an audience that includes the same conditions as the journey's entry step. This ensures that it evaluates both real-time and historical data. You can then use this pre-built audience as the journey's entry condition. This approach guarantees that Segment evaluates users consistently across both data sources.

Each step's membership conditions evaluate in real time, which means that users remain in a step until the immediate next step's conditions become true.

Yes. To allow users to re-enter Journeys that they've exited, enable re-entry during initial Journey setup.

Deleting a Journey removes its underlying audiences from profile views in the Profile explorer. However, the Journey's True/False traits remain in the user's last recorded state.

True/false splits enforce mutual exclusivity by ensuring that once users enter either side of a split, they can't enter the other.

Multi-branch splits don't enforce mutual exclusivity. Users can enter multiple branches of a split if they satisfy the split conditions.

Use Historical Data backfills the entry condition to "prime" the Journey. Future events and existing trait memberships trigger all Journey conditions, except for entry. As a result, event-based conditions only evaluate events that occurred after you published the Journey.

If you want to check for events that occurred before you published your Journey, base your conditions on computed traits instead.

For example, to evaluate if a user already in a Journey has ever used a discount code, create a Computed Trait for discount_used, and set it to true or false.

With time windows within step conditions, you can designate a timeframe for Segment to evaluate whether or not a user has met the condition. Segment calculates the time window from the current point in time, not relative to any other steps in your Journey.