# Journeys Logic, Best Practices, and FAQs

* FREE: x
* TEAM: x
* BUSINESS: ✓
* ADDON: ✓

Engage Foundations requires a Business tier account and includes Unify.

See the [available plans](https://segment.com/pricing), or [contact Support](https://segment.com/help/contact/)

## Journeys logic

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](#entry-conditions-and-step-behavior)
* [How Segment evaluates Journeys step membership](#step-membership)
* [How real-time step membership works](#real-time-step-membership)

## Entry conditions and step behavior

Journeys begin with an entry condition that computes like standard [Engage Audiences](/docs/segment/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 the Segment [Real-Time Compute System](/docs/segment/engage/audiences/#real-time-compute-vs-batch).
* 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.

## Step membership

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.

### Condition steps

"Add a condition" steps operate like [Engage Audiences](/docs/segment/engage/audiences/). The defined conditions provide criteria for each step's membership.

### Wait times

When you add a "Wait" step to a Journey, Segment 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:

| Semantic logic                                     | Written logic condition                                |
| -------------------------------------------------- | ------------------------------------------------------ |
| Has the user ever joined the previous step?        | Does `preceding_step_audience_member` trait exist?     |
| Does the user meet the specified step conditions?  | Defined conditions in "Add a condition" step           |
| Has the user met preceding N wait time conditions? | Trait `preceding_step_joined_time` at least N time ago |

## Real-time step membership

For every step after the entry step, Journeys leverages [the Engage real-time compute system](/docs/segment/engage/audiences/#real-time-compute-vs-batch).

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 updates 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:

| Semantic logic                                     | Written logic condition                                |
| -------------------------------------------------- | ------------------------------------------------------ |
| Has the user ever joined the previous step?        | True; `preceding_step_audience_member` remains true.   |
| Does the user meet the specified step conditions?  | True; assuming user is member of `Example Audience A`. |
| Has the user met preceding N wait time conditions? | True; once 5 days has passed from initial entry.       |

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

### Send to Destination steps

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.

## Best practices

### Enforce exclusivity in multi-branch splits

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 whenever possible

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."

### Suppress targeting with journey lists

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 want 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.

### Review your journey in drafts first

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.

### Know how to incorporate historical data

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](/docs/segment/engage/journeys/v1/#using-historical-data-for-the-entry-step) 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](/docs/segment/unify/traits/computed-traits#conditions) 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:

| Condition Type     | Automatic Historical Data Inclusion |
| ------------------ | ----------------------------------- |
| Audience Reference | Yes                                 |
| Computed Trait     | No                                  |
| Event              | No                                  |
| Custom Trait       | No                                  |

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.

### Use dev spaces and data warehouse destinations to test journeys

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.

### Don't repeatedly emit entry trigger events

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.

## FAQs

### Why can't I create, edit, or clone my classic Journeys?

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](/docs/segment/engage/journeys/v2/event-triggered-journeys), which start automatically when users perform specific actions on your website or app, prior to the planned deprecation.

### How often do Journeys run?

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

### Can a user re-enter a journey?

Yes. Users must first exit a journey, however, before entering it again.

### What destinations does Journeys support?

Journeys supports all Engage destinations, including Destination Functions. Read more in [Send data to destinations](/docs/segment/engage/journeys/v1/#send-to-destinations).

### What are the reporting capabilities of Journeys?

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.

### How are users sent to downstream destinations?

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

### Which roles can access Journeys?

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.

### Why am I seeing duplicate entry or exit events?

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.

### How quickly do user profiles move through Journeys?

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](/docs/segment/engage/audiences/#understanding-compute-times).

### How can I ensure consistent user evaluation in journey entry conditions that use historical data?

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.

### What happens when a user reaches a single or Multi-Split Condition step and the conditions evaluate to `false`?

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.

### Can users exit and re-enter a Journey?

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

### What happens to traits and audiences when I delete a Journey?

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.

> \[!NOTE]
>
> Cloning a Journey generates new, unique traits and sync keys. Deleting the original Journey won't impact any cloned Journeys.

### Are splits mutually exclusive?

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.

### How does "Use Historical Data" backfill work?

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`.

### How do time windows within step conditions work?

With time windows within step conditions, you can designate a time frame 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.