Decision splits and other filter based activities in Journey Builder

Data Extensions

The sendable relationship in the Entry Source Data Extension is the starting point when implementing Journey Builder. The field selected as the sendable relationship (e.g. Subkey[your field name] relates to Subscribers on Subscriberkey) will be the field used when finding the record in your Contact model. This will also be the field used for ContactKey/Subscriberkey (these mean the same thing) when the record is added to All Contacts. It is important to use a consistent value so as to not create duplicate records within your account.

Journey Data

Journey Data is a set of static values passed into the Journey for each contact that is injected. The values passed come from the Entry Source Data Extension. If the Entry Source Data Extension used in a Journey has Subscriberkey, EmailAddress, First Name, and Last Name, all four of these fields will exist in Journey Data. These values will never change. They represent the “instance” of a contact in a Journey. If a given contact is injected into a Journey multiple times, each instance of this contact will have their own unique, static attribute values. Journey Data is useful when all you need is a snapshot of a contact and its related fields at the time of injection. It is important to note that using Journey Data instead of Contact Data will always perform faster. It is also critical to understand that it is unchanging even if a Data Extension row is overwritten or updated.

Contact Data

Contact Data is data that is fetched from Data Designer. The sendable relationship field for the Data Extension used in the Entry Event is the field used to traverse the contact model. Using that field as the lookup value for the various relationships configured within Data Designer, Contact Builder can retrieve values for various related attributes. While the values retrieved are dynamic, they are also more costly to Journey Builder processing. Limit the use of Contact Data where possible, especially if Journeys are time sensitive.

Relationships in Data Designer

Data Designer allows you to link Data Extensions to the root Contact. This root Contact is the record you will find in your All Contacts list. Data Extensions linked in Data Designer can be used for Contact Data within Journey Builder. When linking these Data Extensions, you choose the field to link back to Contact Key. It is important to use the same field that is used for the Sendable Relationship so that the Contact can be found. If your Subscriberkey field in your Entry Source is a Salesforce ID, but you are using a Data Extension that is linked to Contact Key on Email Address, you will not be able to return values because the fields don't match.

Note: You can link on Email Address, but be aware of these limitations: 

When linking Data Extensions in Data Designer, the relationship is assigned a unique ID in the database. This unique ID is used as a reference point when Contact Data is used in decision splits and filters within Journey Builder. If you were to delete the relationship and reconnect the Data Extension, it would be assigned a new ID. This will cause any old decision splits or filters that used the previous ID to fail to evaluate properly. Do NOT delete relationships in Data Designer before checking your Journeys. If you mistakenly delete a relationship in Data Designer that is used in Journey Builder, you will need to recreate the filter in a new version of the journey. 

Channel Address Order

NOTE: Channel Address Order was deprecated as part of the April 2019 Release.

Channel Address Order (CAO) was previously required when sending emails in Journey Builder through the legacy Contact Event. Recent upgrades to the Entry Events have removed this dependency altogether. However, CAO is still used when generating the filters used for decision splits and filters. As such, the more CAO records you have, the more complex and generally less performant lookups to the Contact Model become. Unless you have journeys that are actively using CAO as part of the legacy Contact Event, you should remove them. To determine if your journey is using CAO, follow the steps below.

• Journey Builder > Click on a running or finishing Journey
• If there is no email activity, this journey is not impacted. If there is, continue
• Click Journey Settings
• Is 'Use email attribute from Entry Source' or 'Use email attribute from Contacts' configured with an email address?
• If yes, it is not using CAO.
• If no, the Journey is using CAO.

Populations

Much like Channel Address Order, Populations (formerly named 'Root' Objects) were previously required components when using Journey Builder. Previously, in order to inject a subscriber into a Journey they had to exist in your All Subscribers list OR belong to a Population. That is no longer the case with the Data Extension Entry Event. Like CAO, these are also added to every lookup to the Contact Model by default. The more Populations you have in your account, the more complex and generally less performant these lookups become. As our documentation notes, have 3 or less Populations. Realistically, you can use Journey Builder without a single Population and never run into issues.

With the new Data Extension Entry Event, you no longer need a Population. This entry event type establishes a contact on your behalf so you do not need to maintain a Population.

Synchronized Data Sources

It is important to note that Data Sync creates relationships automatically when you sync CRM objects.

When new objects are synchronized, object relationships are prioritized in this order:

• System-defined standard object relationships.
• Standard reference ID fields, in alphabetical order.
• Custom reference ID fields, in alphabetical order.

When selecting attributes from synchronized objects, it is important to note the relationships between these objects. You will want to ensure the relationship you pick makes sense for your use case. For example, if I want to use a Contact_Salesforce field, I would not want to find a path through the User_Salesforce object.
 

One to Many Relationships

When using Contact Data, it is important to note that the lookup checks for the existence of a record that meets criteria. An example of where this can cause confusion is illustrated below.

In Data Designer, I have a Data Extension named "Subscribers" linked to Contact Key on Subscriberkey. Linked to the "Subscribers" Data Extension is the "Orders" Data Extension. The link used is Subscriberkey to Subscriberkey. The primary key in Orders is OrderID, not Subscriberkey, so that a subscriber can order more than one time.

Let's say I now make a decision split that looks for Orders.OrderDate = Today

If every subscriber can only be found in the "Orders" data extension one time, everything will process normally.

If a subscriber is in the "Orders" data extension more than one time, each record will process down the "Yes" path if one or more of the subscriber rows has a OrderDate = Today.

There are several ways to resolve this issue.

• Only use one-to-one relationships so that a contact can only be found in the lookup one time. 
  • For the example above, this would limit the subscriber to only order one time, which would not be optimal.
• Further define your filters using attribute to attribute comparison.
  • For the example above, you can use Order ID to compare between the entry source DE (Journey Data) and the Orders Data Extension (Contact Data)

Note: Regardless of cardinality, decision splits have a limit of 1000 contacts per search. If a contact exists 1001 times in a Data Extension that is being used for a decision split, only the first 1000 are returned. These 1000 are then ran through the filter you've specified to determine what path the contact should traverse. Also, the 1000 contacts pertain to a single ContactKey. 

Additional Resources

Contact Builder Best Practices
Journey Builder Best Practices
Optimizing Sending Through Journey Builder
Connect a Data Extension for Decision Splits