Customer Journey Optimizer Rules Overview

About Customer Journey Optimizer Rules

Rules in the Customer Journey Optimizer are the building blocks for your journey. They are composed of various “if” and “then” statements that determine the path for your journey. This page will cover how to build rules, where rules are used, and how rules get evaluated as a traveler moves along the journey.

Rules Basic Overview

Generally, a rule is composed of one or more pairs of “if” and “then” statements. You can think of the “if” statement as the rule’s condition, while the “then” statement is the rule’s action.

The condition is the criteria for something to happen, while the action is what should happen if the condition is met.

Types of Rules

Rules are used in many places in the Customer Journey Optimizer. Sometimes, rules will only have a condition, since in those instances you are trying to filter the data for your journey by selecting the right travelers and event data.

Rules in the areas listed below only have conditions:

• Journey entry criteria: these rules determine what event data or travelers can enter a journey.
• Milestone entry criteria: these rules determine if a travelers will enter a specific milestone within a journey.

Rules in the areas listed below have both conditions and actions:

• Global rules: these rules are evaluated at the beginning of the journey and are applied to all travelers who enter your journey.
• Milestone rules: these rules determine what happens as a result of a given milestone in your journey.

Rule Evaluation Order

When creating your journeys, you have different types of rules at your disposal that determine how events are processed. Rules are executed in the following order each time a new event is received:

1. Journey entry criteria
2. Global rules
3. Milestone entry criteria
4. Milestone rules

When evaluating a given set of rules, they are evaluated from top to bottom. You should make sure to place your most exclusive rule last to avoid accidentally disqualifying travelers from fulfilling your rule conditions.

Building Rules

This section covers how to build rules. Note that while we’ll be building rules for a milestone journey, rule building works the same way in the other areas of the platform.

1. In the Rules section, give your rule a name so you know what the rule does.
2. Click the plus sign (+) and choose the integration you want to base your condition on. When choosing an integration, think about which integration has the data you need for the journey.
3. Choose the object that contains the data you want to use in your condition.
   
4. Choose the field to base the condition on.
5. Select the operator for the condition (e.g., “does not equal”). See Operators for more information.
6. Choose the value for the condition.
   Qtip: You can add multiple values by typing additional values in the Add another value field. When you have multiple values, they are separated by an “or” operator, meaning only 1 of the values must be found for the rule to be true.
7. To add additional conditions, click and if +. Follow the steps above for creating additional conditions. Note that if you add multiple conditions, all conditions must be met for the action to take place.
8. To add an action to your rule, click then +.
   Qtip: The remaining steps are for adding outbound actions to global and milestone rules. You cannot add actions in entry criteria rules.
9. Choose the integration where you’d like the action to take place.
10. Select the action that should take place (e.g., send an email). Depending on the type of action you select, you may need to define different values for the action (e.g., the “to email” for sending an email).
    Qtip: See the documentation for the integration you’re interested in to find specific instructions on configuring actions for that integration.
11. You can add additional actions by clicking and then +. If you add multiple actions, all actions will trigger if the conditions are met.
12. When finished, click Save.

Operators

This section covers the different types of operators and their availability based on the field type. Operators describe how a field should be evaluated.

The operator available for a given condition will depend on the field type. The table below compiles all available field types for conditions and their possible operators.

The following field types are available in the Customer Journey Optimizer:

• Text (“Downloaded App”, “Premium Account”)
• Boolean (True or False)
• Number (230, 4.2)
• Date / Time (2017-08-11 09:23 UTC)
• Duration (“7 days”, “1 day”)
  Qtip: Duration fields can only be in days.

Date / Time fields cannot be used after operators, so they are excluded from the table below:

Time Based Rules

Time based rules function differently from other rules in the Customer Journey Optimizer. This section will cover how time based rules are evaluated and some best practices for building time based rules.

1. Time based rules are evaluated not only when a new event is processed by the Customer Journey Optimizer, but also on a continuous basis, even in the absence of new events. A simple analogy is that of an alarm timer. These rules are evaluated on a recurring basis to see if travelers meet the criteria. If they do, the actions will be triggered.
2. Time based rules use the current moment as a reference point. An example of a simple time based rule is “If SiteVisit is older than 5 days ago.” If a Traveler has a value for the SiteVisit field and that value is more than 5 days in the past, then this rule will be evaluated as true.
   • If you’d like to target a specific time range (e.g., more than 5 days from now but less than 2 weeks), then you can use multiple rule conditions to target that time range.
   • If a new event comes in that moves the traveler to a new milestone before the traveler fulfills the time based rule, then the timer will be disregarded, and the rule will be evaluated as false.
3. Dates are saved in a Date / Time format. If the time or timezone is not specified, then it will automatically be set to 00:00:00,000 and the UTC timezone.
   Example: For example, “2020-12-31T16:00:00,444-08:00” stays “2020-12-31T16:00:00,444-08:00”, whereas “1975-01-30” is converted to “1975-01-30T00:00:00.000Z” before being stored in the Customer Journey Optimizer.
4. You can only base rules on the number of whole days (i.e., 1 day, 30 days, 365 days, etc). Do not use any other time frames or partial days. Using non-integer days will result in the rule being invalid.
5. If using a time based rule, we suggest setting the fetch schedule to the most frequent option so you have the most up-to-date data.
6. The “is older than” operator should be considered > not >=. The “is newer than” operator should be considered a < not <=.