Rule-based branching provides a powerful method to design personalized experiences for contacts based on the accumulated knowledge about that contact. It utilizes a rule-based approach to determine the experience that a contact should receive, and automatically makes sure that contacts will not be included in more than one variant or path of a journey.

Using segment membership to ensure a contact receives only one type of message can be difficult. Often, contacts will meet the criteria to be enrolled in multiple segments. To make segment membership mutually exclusive, definitions must take into account possible membership in other segments. This can cause segments to be overly complex, and make it challenging to identify all possible sources of overlap. With rule-based branching, a contact can only receive one variation of a message, and thus avoid over-messaging or conflicting experiences.

Define rules using segment membership

Segments can be used as a way to bundle complex sets of conditions in order to define an audience. The rules used to determine if a contact is eligible for a message variation can either (1) include segments or (2) exclude segments. This can be selected from the dropdown menu in the variation rules definition.

Mutual exclusivity

Simon Data’s rule-based approach creates a hierarchy that enforces mutual exclusivity between groups of recipients. Variants are evaluated from top to bottom, in order from A through Z. The first set of conditions that a contact meets will determine the message to be sent. If a contact meets the rules declared for multiple branches, they will be messaged with the first variant in the list for which they meet the conditions.

Default variant

The default variant will be sent to any contacts targeted by the flow who do not meet the conditions of another variant. The default variant is evaluated last and acts as a “catch all” to ensure that contacts not explicitly identified using rules can still be messaged. The default variant is always last in the list and is represented with the notation of “Z”.

Example
In this example, we use two segments to define who should receive each variation of a message. One segment is a group of High LTV contacts. Another segment is contacts without a purchase in the last week. Some contacts meet the conditions of both segments.

We decide to configure the flow as shown below, targeting High LTV contacts with Variant A.

Since the membership for Variant A is evaluated first, the contacts who are in both groups will be selected to receive Variant A. The group of contacts who will receive Variant B is defined as contacts who are in Branch B and not in Branch A.

Define rules using event properties

For event-triggered flows, there is the option for branching based on event properties. Certain event-triggered flows may not have the option for segment membership branching. This is for the case when the flow includes contacts that are not already present in the system.

Branching based on event properties takes into account the data coming in on the event that triggers the flow. For example, for a registration event, you could use different templates for international vs. domestic contacts. Using the data on the event, you can determine which branch to assign it to.

Below is an example of how this might look:

The same behavior applies to branching based on event properties as for segment membership when it comes to mutual exclusivity and default. If a property does not match any of the conditions, including if that property is not available on an event, it will be assigned to the default.

📘

Variant Maximum

Flows can have up to 13 variants.

Data types and conditions for event properties

There are four different data types for event properties:

Event property branching uses the same operators as the segment builder. The event properties that are available for branching can be set up by the Simon Data team based on the properties that are coming in on your events. Please contact us if you'd like to start using event properties for branching.