Conditions

Learn how to use conditions in the Loyalty Engine to control when a reactor fires or an event counts toward a mission — based on event payload data, audience membership, and user points history.

Conditions let you control when a reactor fires or whether an event counts toward a mission. They give you fine-grained control, so a reactor only reacts — or a mission only advances — when the exact criteria you define are met.

Conditions work the same way in both contexts:

• In a Rule Based campaign, conditions decide whether a reactor’s reactions fire for a given event.

• In a Goal Based campaign, conditions decide whether a qualifying event counts toward a user’s mission progress.

Conditions can be based on:

Event data

Conditions relating to data of the particular event being reported.

Audience data

Conditions relating to the audience(s) the user reporting the event has joined, left or is a member of.

Points data

Conditions relating to the points balance or earning history of the user reporting the event.

Conditions applied to a mission so that only events with the item 'Coffee' count towards the target.

---

Specifying conditions

By default, the Loyalty Console offers a graphical interface (GUI), known as ‘block mode’, to add conditions based on the selected trigger event.

For more complex conditions, or those involving properties not defined in the event type’s schema, you can switch to JSON input to configure them manually. Conditions must be specified using JSON Schema Draft 6.

Once you’ve entered custom JSON in a configuration, you cannot return to block mode unless you remove the complex conditions.

---

Event-specific conditions

Event-specific conditions tailor behaviour based on details specific to the trigger event, using data directly from the event payload.

Here are some examples of conditions you might expect with common events:

• Transaction events — total number of line items purchased, specific SKUs purchased, total amount spent, retail location, retail channel (e.g. online, in-store).

• Survey/quiz events — which questions were answered, percentage completed, whether the survey was abandoned or completed, ratings given, score.

• Promo code submission events — the code that was submitted.

• New subscription events — the selected plan, subscription term, whether it’s a new subscription or a renewal.

To use any of these data points as a condition, they must be included in the event payload and defined in the event type’s schema.

Remember, custom event types and their associated conditions are defined by you. It’s up to you to decide which customer behaviours you want to reward, determine the source of your event data, create custom event types with the appropriate payload schemas, and send these events to the Loyalty Engine via API. For more information, see Event types.

Event-specific conditions use case examples

• Only fire a reactor when a transaction exceeds £100.

• Only count purchases over £20 toward a spending mission.

• Award bonus points when a purchase includes specific product SKUs.

• Trigger a reward only when a user signs up for an annual subscription plan.

---

Audience conditions

Audience conditions relate to the audiences the user associated with an event is in. There are two types: user in audience and specific audience joined / left.

User in audience

The user in audience condition lets you choose one or more audiences the user must be a member of for the reactor to fire or the mission to advance.

This condition is available for any event type when you enable the Audiences event enhancer in the event type’s configuration. It’s essential for targeted campaigns where you want logic to apply only to specific segments of users. See Audiences for more information.

When using the Audiences event enhancer, the event being reported is enriched with the audiences that user was in before the event occurred. It does not take into account any audience changes that may occur as a result of that event being reported.

Specific audience joined / left

The specific audience joined / left condition is exclusive to configurations where the trigger is one of the Audience Joined / Left event types. It lets you specify the audience the user must have joined or left.

The key difference: user in audience checks membership at the time the event is processed, while specific audience joined / left is based on the user’s action of joining or leaving a particular audience.

One is for general targeting, the other for membership changes.

Audience condition use case examples

• User in audience — award VIP members a bonus when they make a purchase; run promotions for users in a certain region (e.g. double points for UK-based users during holidays).

• Specific audience joined / left — reward users when they join a “High Spenders” audience after hitting 1,000 points; re-engage users who leave the “Frequent Buyers” audience with a win-back offer.

---

Points conditions

Points conditions let you control behaviour based on a user’s points balance or earning history. For example, you can target users based on current balance or points earned in a given time period. This data is added to the event by the points event enhancer.

Example use cases

• Only fire a reactor when a user makes a purchase and has over 5,000 points.

• Only count an event toward a mission when the user has earned less than 1,000 points in the current calendar month.