Conditions

Learn how to use payload conditions in the Loyalty Engine to control when reactors trigger based on event-specific data, audience membership, and user points history.

Payload conditions allow you to control when a reactor is triggered, based on specific data within the event’s payload. This gives you more flexibility to create highly targeted responses, ensuring that reactors only fire when specific criteria are met.

By using payload conditions, you can fine-tune your loyalty program to reflect the exact behaviours and actions you want to reward or react to.

Conditions can be based on:

Specifying conditions using block mode, and switching to JSON

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. Payload conditions must be specified using JSON schema draft 6.


Event-specific conditions

Event-specific conditions allow you to tailor reactor behaviour based on details specific to the trigger event. These conditions use data directly from the event payload, providing more control over when reactors are triggered.

Here are some examples of conditions you may expect to find with some common events.

  • Transaction events may include conditions like total number of line items purchased, specific SKUs purchased, total amount spent, retail location (i.e. store #372), retail channel (i.e. online, in-store).

  • Survey/quiz events may include conditions like which questions were answered, percentage of survey completed, if the survey was abandoned or completed, ratings given, score.

  • Promo code submission events may include conditions like the code that was submitted.

  • New subscription events may include conditions like 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 schema.

Remember, event types and their associated conditions are entirely 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 Get started with Events.

Event-specific conditions use case examples
  • Only run a reactor when a transaction exceeds £100

  • Award bonus points when a purchase includes specific product SKUs

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

  • Filter out generic events to ensure actions only happen when specific event data is present


Audience conditions

Audience conditions relate to information about the audiences the user associated with an event is in. There are two types of audience-related condition available: user in audience and specific audience joined / left.

User in audience

The user in audience condition allows you to choose one or more audiences the user must be a member of for the reactor to activate.

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 running targeted campaigns where you want reactors to apply only to specific segments of users based on available Audience query builder.

See Limit a reactor an audience for more information.

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

Adding 'User in audience' payload condition

Specific audience joined / left

The specific audience joined / left condition is exclusive to reactors 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 for the reactor to activate.

This is used when you want the reactor to trigger when a user changes their audience membership.

The key difference between these two conditions is that user in audience checks for audience membership at the time the reactor is triggered, while specific audience joined / left is based on a user’s action of joining or leaving a particular audience.

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

Audience condition use case examples

User in audience

Use when you want the reactor to apply only to users currently in a specific 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

Use when you want the reactor to respond to users entering or exiting an audience:

  • Reward users when they join a “High Spenders” audience after hitting 1,000 points

  • Re-engage users who leave the “Frequent Buyers” audience by triggering a win-back offer


Points conditions

Points conditions let you control reactor behaviour based on a user’s points balance or earning history. You can target users based on current balance, points earned in a given time period, or data from the points event enhancer.

Example use cases

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

  • Only run a reactor when a user makes a purchase and has earned less than 1000 points in the current calendar month

Last updated

Was this helpful?