Optimizing Journey Performance

Journeys work hard for you—sometimes, a little too hard. 😅 Maybe you’re noticing a lot of users stuck in one tile, or some of your journey campaigns are sending more slowly than expected.

Here are some tips and tricks for making your journeys run as efficiently as possible.

# In this article

# What causes slow journey performance?

The great thing about journeys is that they let you automatically engage many users at once. However, if your journey setup is overly complex, you could end up with long processing times.

If users enter a journey faster than it can process them, you may see users build up on individual journey tiles. The user badge on a tile represents the number of contacts who are currently finished with that tile and are waiting to move on to the next one. However, this doesn't necessarily mean that the tile is processing slowly.

You may see a user count on delay tiles as contacts wait for the delay to expire. If a significant number of contacts are added to a journey at the same time, you may see a user count until the journey finishes processing the queue.

If you continue to see user counts that do not decrease after refreshing the journey page, it may be a sign that your journey is processing contacts more slowly than expected.

There are a few factors that can contribute to slower journey performance:

• The number of filter tiles in the journey
• How your filter tiles are set up
• The size of the lists you may be using in the Start or filter tiles
• Whether you're using static or dynamic lists in the Start or filter tiles
• Whether you're searching custom events or user profile fields in filter tiles

Here are some tips on how to keep your journeys running smoothly.

# Add entry rules to the Start tile

It's really important to only add the users who should go through the journey (and no one else). One of the best things you can do to speed up your journey's processing times is to prevent ineligible users from entering the journey in the first place.

Instead of adding a filter tile right after the Start tile, set up Additional entry rules in the Start tile settings to prevent ineligible users from entering the journey.

This is much faster than adding ineligible users to the journey and then filtering them out afterwards.

# Simplify your filter tiles

Filter tiles are incredibly powerful—but if they're not set up efficiently, they can take a lot of processing time and slow down your journey's performance.

# Choosing the right comparator

When you add a filter to a journey, you'll want to pay attention to the types of comparisons you set up in your segmentation query.

There are six different options for setting up comparisons:

• Is Set: A value has been set for the field (the field is not blank)
• Equals: The field must exactly match the value you select
• Does Not Equal: The field must NOT match the value you select
• Starts With: The field must start with a certain word or phrase
• Contains: The field contains a certain word or phrase
• Matches Regex: Compares the field to a regular expression (RegEx) to find every instance of the same value (including all formatting variations)

Some of these comparators work better than others for building efficient queries:

Use these	Avoid these
✅ Is Set	❌ Starts With
✅ Equals	❌ Contains
✅ Does Not Equal	❌ Matches Regex

For example, to search for users whose email addresses match a particular domain, use the Equals operator, like this:

Email Domain Equals domain.com

Don't use the Contains operator. This query takes longer to run and could slow down your journey performance.

# Setting up event-based searches

Refining an event-based search (for example, searching for exactly 1 SMS open) adds to the intensity of your segmentation query. If you decide to do this, be strategic about how you set it up.

Let's say you want to search for users who have opened an email at least twice. Instead of setting up a query that checks for 2-5 opens, check for 2-infinity.

It may seem counterintuitive, but this is actually a shorter search—this tells Iterable to stop checking as soon as it finds 2 opens for a user. If you search for 2-5 opens, Iterable will keep searching until it can tell if the user opened the message 2, 3, 4, or 5 times.

# Searching custom events vs. user profile fields

Segmentation queries that search user profile fields generally run faster than queries that search for custom events. When possible, set up queries to search user profile fields instead of custom events.

If you need to filter by a custom event, your segmentation query will run faster if you use the Only the event that triggers this journey option. If you select All user properties and events, your query will search every past event in your project, which may take longer.

# Check what kind of lists you're using (if applicable)

If you're noticing slow performance in one of your journeys, it could be because of a list you're using in the Start tile or a filter tile. In the Start tile, you can select a list to add users to the journey (using the List Subscribe, List Unsubscribe, or Schedule entry source). And in filter tiles, you can check whether or not users belong to a particular list by searching for Contact Property > List Membership. If you're using a large or complex list in one of these places, it could cause slower processing times.

When you use Iterable's Segmentation tool, you can save your results as either a static or dynamic list.

Static lists include all users that match the segmentation query when the list is saved. Dynamic lists periodically refresh the results of the segmentation query, providing an up-to-date set of users. You can also build dynamic lists from other dynamic lists (this is called a nested dynamic list).

Just like filter tiles, dynamic lists are a powerful tool. But if your segmentation queries use overly complex search/filter logic, it can lead to performance slowdowns.

For optimal journey performance:

• Use static lists whenever possible.
• Avoid dynamic lists and nested dynamic lists.
• Keep the segmentation queries that build your dynamic lists simple, especially for lists that will be used in journeys that run frequently. For example, if you have multiple groups of criteria in your segmentation query, remove any that may be repetitive.

To learn more about using dynamic lists in journeys, see Optimizing Dynamic User Lists.

# Optimize your project data storage

How efficiently your journeys run depends on how much data you're storing in Iterable. If you're storing a lot of unnecessary data, it could cause some of your journeys to process more slowly.

Before you decide to send a particular kind of data to Iterable, make sure you really need it. The smaller your data set, the faster Iterable can search it—so it's best to avoid sending any data that your project doesn't really need.

Your project may be storing large quantities of some events for which you really only need the most recent instance for each user. In these cases, instead of storing the events themselves, you can store this data as user profile fields. This reduces the amount of data stored in your project, and you can still segment and filter on the user profile fields. It's a win-win!

See Monitoring Custom Event Usage to learn more about how to manage the custom events stored in your Iterable project.

# Questions?

For help troubleshooting one of your journeys, see Journeys: Frequently Asked Questions or reach out to your customer success manager.