Program Administration Guide¶

Welcome to the ReactorCX Program Administration Guide.

This guide provides detailed information regarding ReactorCX (RCX) program administration and set up which enables end users to configure and manage a wide range of features to implement a loyalty program using a simple point-and-click interface.

Intended Audience¶

The intended audience includes administrators, marketing managers, or individuals responsible for the setup, configuration, and maintenance of ReactorCX.

Overview of Programs¶

A loyalty program offers rewards to customers based on how they interact with a company. Customers purchasing goods and services represent the most common type of interaction, however, ReactorCX can execute rules on a variety of non-purchase behaviors, as long as they can be sent to ReactorCX from the point of interaction via one of the supported ways to integrate with RCX.

A well designed loyalty program is not just about rewarding your repeat customers, but it is also a channel that can strengthen customer relationships, as it generates actionable data. This data can be used to implement sophisticated relationship marketing, segmentation and targeting, as well as ways to capture and incentivize different types of customer behaviors.

Program Definitions¶

A Program Definition (or Program for short) is the top-level configuration object governing the execution mechanics of a loyalty program. Typically a business will have a single Program, however, ReactorCX supports multiple Program Definitions in the same instance, which is useful in cases where a company operates several programs, usually separated regionally or divided in some other way.

Adding a New Program¶

To add a new program:

1. Navigate to the Programs item in the menu panel on the left.
2. Click on the Add Program button in the top right corner of he Programs view.
3. Enter the name and description for your program, and press OK.

Using Program Policies¶

Policies capture the structure, and basic parameters of what the program is tracking (e.g. Point Types, Tiers, etc.) and is also used to configure the behavior of discounting rules within Rewards.

Policies govern how the program deals with Rewards, Purses, and Tiers.

These policies and their configuration will be further described in later sections of this manual.

Using Rules and Rule Folders¶

Rules are the main building block of the RCX loyalty execution system. A rule is generally a set of conditions and actions to be executed when those conditions are satisfied.

Rules are organized in Folders usually based on some logical hierarchy such as divisions of business, base program promise vs. bonus promotions, etc.

Conditions – The Rule evaluates its conditions and if all the conditions are satisfied, the associated Action is executed.

Actions – Actions are quite diverse in what they can do, but usually involve adding points, upgrading tiers, or loading reference data of an Activity, etc.

Folders – Folders are Rule containers organized hierarchically to manage program complexity and logical separation.

From a programming standpoint, a rule can be thought of as an if-then statement; if all of its criteria are met, then one or more actions may take place.

Flow¶

In RCX, the execution path of an Activity through the Rules is known as the Flow. The Flow Composer in RCX is a tool that allows fine-grained visual control over the Flow.

While all Rules can be just placed in a single top-level Folder and arranged in a Flow by the engine automatically, in some cases, it is possible to obtain performance and execution logic improvements by outlining a path to major parts of the system. The way to think of Flow is that it applies a high-level workflow engine on top of the RCX rule engine to give extra control and flexibility.

The Flow Composer is described in detail in later sections of this manual.

Common Eligibility Criteria¶

In RCX there are two primary tactics for delivering loyalty benefits:

• Rules - enables giving points, tiers, and other attributes to members.
• Reward Policies - enables giving direct discounts.

In order for RCX to decide whether a particular Reward Policy of Rule should apply to a situation, it needs to first determine if these tactics are eligible to be applied in a particular transaction.

This eligibility is expressed in several dimensions:

• Audience - audiences are created by grouping members in segments and targeting promotions to these segments.
• Location - where a transaction occurs in terms of location will drive whether a tactic is applicable.
• Time - when a transaction occurs in terms of both dates, day of week, or time of day will drive whether a tactic is applicable.
• Products - what a transaction contains in terms of products/services purchased will drive whether a tactic is applicable.

It should be mentioned that applicability manifests itself in transaction processing as well as in calls to the API to get personalized lists of discounts and promotions available for a specific member:

• Transactions will apply rules and discounts based on eligibility.
• Calls to the API for Get Member Offers and Get Member Promos will be filtered based on eligibility.

The sections below describe how these eligibility criteria are specified in both Rules and Reward Policies as they are very similar or identical in most cases between the two types of tactics.

Audience¶

In RCX, to express audiences, it is possible to associate members with multiple segments. It is also possible to specify several segmentation criteria that drive eligibility.

The following settings are available in the Rule's General tab:

Figure 1. Rule Segmentation

• Tier Levels - specifies which Tier Levels this rule applies to.
• Segments - specifies which Segments this rule applies to.
• Mandatory Segments - specifies which Segments the member must be a member of in order for this rule to apply.
• Control Groups - specifies which Segments will specifically be excluded from this rule as a control group to measure promotion effectiveness.
• Member Status - specifies what status the member may be in to obtain this discount.

The following settings are available in the Reward Policy Eligibility tab:

Figure 2. Reward Policy Segmentation

• Tier Levels - specifies which Tier Levels this rule applies to.
• Segments - specifies which Segments this rule applies to.
• Mandatory Segments - specifies which Segments the member must be a member of in order for this rule to apply.
• Control Groups - specifies which Segments will specifically be excluded from this rule as a control group to measure promotion effectiveness.
• Member Status - specifies what status the member may be in to obtain this discount.
• Eligibility Query - specifies specific criteria using JSON query language (advance use only). This type of query is documented separately in the API specification.

Location¶

To enable location-specific offers, each Rule or Reward Policy has a location filter. This can be specified in the Details Tab for Rules and in the Eligibility tab of Reward Policy.

Figure 3. Add Locations Button

When the ... button is pressed, you will enter the Location filter which allows selecting multiple locations, or choosing a pre-saved list of locations which are available.

Figure 4. Location Filter

Please refer to the User Interface Guide for more information on using filters and named lists.

By default all locations are selected for a rule if no location filter is specified.

Time¶

Each Rule or Reward Policy has an effective and expiration date which are listed on the General Tab and Availability Tab respectively.

Figure 5. Effective Dates

In addition, adjacent to effective dates, you will find the effective days of week and times for a tactic as in the below screenshot.

Figure 6. Days of Week and Times of Day

By default all days of week and all times are selected.

Product¶

Generally a program rewards the consumption of products and/or services. Therefore, both Rules and Reward Policies allow specifying product groups, which allow filtering, exclusions, and grouping of discount/rule behavior by product.

There are up to three general product groups associated with any Rule or Reward Policy, named Primary, Secondary and Tertiary Products. Additionally you can specify Mandatory Products, which always ensures that a Rule or Reward Policy won't apply unless the required quantity of Mandatory Products is available in the Activity.

Figure 7. Product Groups

These groups behave differently depending on what type of promotion or discount is specified in the Rule Type or Discount Type field. The table below lists all the different types of discounts/rules nad how product groups are used in relation to them.

Authoring Rules¶

Rules can be configured by supplying parameters within the Rule tabbed dialog box and/or by directly specifying detailed Conditions/Actions using the RCX Rule Editor.

Creating a New Rule¶

To create a new Rule:

1. Navigate to the Programs>Your Program Name>Rules menu option from the sidebar on the left.
2. Select the folder where you want to create the new rule
3. Click on the New Rule button

Figure 8. Creating a New Rule

Copying an Existing Rule¶

To copy an existing Rule:

1. Navigate to the Programs>Your Program Name>Rules menu option from the sidebar on the left.
2. Select the folder where the rule you want to copy resides, for example Base Rules.
3. Click on the clipboard button next to the rule in the list.
4. Rename the rule to something unique.

Figure 9. Copying an Existing Rule

Configuring Rule Parameters¶

To configure Rule Parameters:

1. Navigate to the Programs>Your Program Name>Rules menu option from the sidebar on the left.
2. Select the folder where the rule you want to configure resides, for example Base Rules.
3. Click on the pencil button next to the rule in the list.

Figure 10. Configuring Rule Parameters

The following parameters are available for configuration on the General tab:

• Name - unique Rule name.
• Description - a longer text describing the purpose of the Rule.
• Can Preview - a flag indicating whether the Rule can participate in the Preview process.
• Add to Result Log - whether to record detailed execution log for this Rule.
• Folder Gate Rule - allows a rule to become a gate-keeper for a folder. If the rule does not trigger, no other rules in the folder will execute.
• Priority - allows ordering the execution of Rules within a Folder.
• Bonus Type - allows configuring a Bonus Point rule via either a Multiplier or Bonus value.
• Bonus Value - specifies bonus or multiplier value.

The following parameters are available for configuration on the Availability tab:

• Cool Off Period - allows throttling the execution of a rule by controlling the frequency (in minutes) of rule execution. If a member qualifies for the rule, but the last time this rule fired for this member is within the cool off period, the rule will be suppressed automatically.
• Per Day Limit - allows restricting how many times a rule can execute per day for a member.
• Per Week Limit - allows restricting how many times a rule can execute per week for a member.
• Per Offer Limit - allows restricting how many times a rule can execute for a member during its effectivity.
• Count Limit - allows restricting the total number of times this rule will fire across all members during its effectivity.
• Budget - allows restricting the total number of points that can be issued by a rule across all members during its effectivity.

Rules also support the Common Eligibility Criteria described in this manual for Rules and Reward Policies.

Configuring Conditions and Actions¶

You use the Rule Editor to configure the Conditions and Actions of a Rule. The RCX Rule Editor allows almost unlimited flexibility in configuring the behavior of rules within the program.

Each Rule defines a group of Conditions, followed by a set of Actions to take if those conditions are satisfied.

The figure below shows all the RCX Rule Editor elements, and the table below explains each element.

Figure 11. Rule Editor

Execution Context¶

In RCX, each incoming transaction is described by an Activity object, which is submitted for execution via the RCX API. When an Activity is first received for processing, RCX automatically creates an Execution Context (or just Context) which is a per-request work area, where the incoming activity is stored, and additional data is added as processing runs.

Figure 12. High-level Context Structure

The Context contains these important areas:

Activity Model¶

Activities consist of a general attribute section which covers the main aspects of the Activity, such as type, date and time of occurrence, location where it occurred, etc.

Figure 13. High-level Activity Structure

The Activity (as well as any other entity in RCX) is extensible and able to accommodate any number of additional attributes, depending on the use case needed. The structure (data model) of the Activity is listed here with explanation for each field.

Member Model¶

Members consist of all attributes relevant to a Membership, including all Purses, Tiers, Segments, Badges, etc. It is important to remember that in RCX a Member is not the same as a Person. While we often refer to this data as Member, it is in fact a Membership, and can also represent entities other than people - such as businesses, charities, etc.

Figure 14. High-level Member Structure

The structure (data model) of Member is listed here with explanation for each field.

Rule Conditions¶

Conditions compare attributes of the Context (e.g. Member or Activity attributes) to specific values or other attributes. For example, we could compare the current Member's tier level to see if they are Gold or Platinum and decide to give bonus points for the Activity based on that condition being true.

Figure 15. Conditions

Adding Rule Conditions¶

To add a condition to a Rule:

1. Navigate to the Rule in its parent Folder
2. Click on any field of the Rule other than the area where the buttons are located.
3. The Rule Editor opens and shows the Conditions/Actions applets.
4. Click on the Add Condition button at the top of the Conditions applet.

Using Aliases to Access Attributes¶

In RCX, the LHS or RHS of a Condition, as well as any parameter to an Action, can be set to an Alias. An Alias is a piece of text starting with @ that identifies an attribute of the Context or any of it's sub-objects.

Some examples are listed in the table below:

The Alias describes how to navigate the object hierarchy in the context to get to the piece of data you want to use for the Rule.

Using Expression Builder¶

To define your own custom Aliases and to examine the available Aliases in detail, you can enter the Expression Builder by clicking on the fx button next to an LHS, RHS or Action parameter.

Figure 16. Opening the Expression Builder

The Expression Builder UI is shown below, along with the explanation of its main features:

Figure 17. Expression Builder

Using Constants¶

A fixed value such as a number or string is known as a constant. Generally, the LHS, RHS and Action parameter boxes can contain constants in the form of Strings and Numbers. Strings must be quoted to be interpreted as constants.

Figure 18. LHS and RHS

Removing Rule Conditions¶

You can remove a rule condition by selecting the red X button next to the rule.

Figure 19. Delete Condition

Enabling and Disabling Rule Conditions¶

You can temporarily disable a Condition by using the toggle (yes/no) on the right of the rule as shown in the figure below. This can be very useful in debugging a rule where you are not sure which Condition is causing your rule not to work properly.

Figure 20. Enable or Disable Rule

Adding and Removing Condition Groups¶

Conditions can be grouped by creating inner groups using the Add Group button at the top of the Condition applet. Groups inside of groups are treated as individual conditions by the parent group.

Each group carries its own Grouping Method (All/Any) allowing complex nested conditions to be expressed.

To remove a condition group, use the Remove Group button displayed to the right of it.

Figure 21. Condition Groups

Condition Operator Types¶

The rule editor provides the following logical operators and events using which you can create Conditions:

• Equals
• Not Equals To
• Exists
• Does Not Exist
• Greater or Equal To
• Greater Than
• Less Than
• Less Than or Equal To
• Like
• Not Like
• Length Equals
• Length greater or equal to
• Length greater than
• Length less or equal to
• Length less than
• Length Not Equals
• Starts With
• Ends With
• Does Not Start With
• Does Not End With
• Is in list of
• Is not in list of
• Is substring of
• Is not substring of
• Is TRUE
• Is FALSE

The highlighted block of the figure below shows the location of the operators in the rule editor.

Figure 22. Operators

Rule Actions¶

Actions are the doers of a rule. A rule action informs RCX what to do when the rule Condition is matched. They make changes in response to an incoming Activity such as adding points, setting tiers, redeeming points, etc.

Use the Add Action button to add actions to a Rule.

Figure 23. Actions

Please refer to the Rule Action Reference for the full list of actions, their parameters and behavior.

Action Parameters¶

Actions have parameters, which vary depending on the action you want to use. These parameters are similar to the RHS/LHS of Conditions, and can accept Aliases, or expressions created with Expression Builder as needed.

Enabling and Disabling Actions¶

You may temporarily Enable/Disable actions using the blue toggle on the right-hand side of each action. This works the same way as with Conditions.

Changing Action Order¶

You may use the up/down arrow handle on the left side of each action to drag it up or down in order to place it before or after other actions.

Copying and Pasting Objects¶

You can copy and paste Conditions and Actions between Condition Groups, or between separate Rules.

To copy an Action or Condition object:

1. Click on the green clipboard button to the right of the object.
2. You should see a Paste button appear in all possible places where the copied object may be pasted.
3. Click on the Paste button to paste the copied object.

Figure 24. Copy and Paste

Testing Rules¶

ReactorCX provides several levels of testing capabilities to ensure quick iteration and validated learning.

Rule Editor Testing¶

Inside the Rule Editor there are three types of tests that can be done:

• Condition Testing
• Action Testing
• Expression Testing

We will briefly introduce each type of test and how it can help troubleshoot rules. But before we can discuss testing methods, we need to cover how to create sample test data to run tests on.

Creating Sample Data Sets¶

In order to simulate rule execution, we need to create a sample Activity and pick a sample Member for whom this activity will be executed.

To create test data, follow these steps from the Rule Editor view:

1. Click on the ... button at the top right corner of the Condition or Action applet, next to the Test Data dropdown.
   Figure 25. Test Data Button

2. The Test Data dialog box opens, with two tabs Member Data and Activity Data. Use the Search button under Member to identify a test member to use. You may use several criteria to identify a good test member or pick one at random.

   
   Figure 26. Test Data Dialog Box

3. Once you have selected a Test Member, you will see the data for that Member in the Tree pane under the Search button.

   
   Figure 27. Member Test Data

4. Switch over to the Activity tab and press the Generate Activity button to generate a sample activity.

   
   Figure 28. Generating Activity

   Tip

   For more information on how to create an Activity via the Generate Activity dialog box, please review the Manual Activity Processing section of the Member Care Guide.

5. Fill out the transaction details as needed in the Generate Activity dialog box and press OK.

6. The Activity will be filled out in the Tree pane under the Generate Activity button similarly to how Member was populated.

7. To save your Member and Activity test data set, click on the Save or Save As button at the top of the Test Data dialog box:

   
   Figure 29. Save Test Data

8. Once saved in this way, the test data set is reusable for testing and available in the Test Data drop down box.

   
   Figure 30. Test Data Dropdown

Testing Conditions¶

To test conditions:

1. In the Conditions Applet select a Test Data set from the Test Data dropdown box.
2. Press the Test button next to the Test Data set dropdown. This will run your conditions on your Test Data set.
3. To view the result look at the Result box next to the Test button. If the condition passed, that Result box will turn Green and read 'Passed'. If your conditions failed, then the Result box will turn red and read 'Failed'.

4. To understand which condition is failing use the toggles on the side of each condition to turn them off and find out which one is failing by process of elimination.

   
   Figure 31. Failed Condition

   
   Figure 32. Passed Condition

Testing Actions¶

Actions can be tested to see how the member changes as a result of the Actions. To test actions:

1. In the Actions Applet select a Test Data set from the Test Data dropdown box.
2. Press the Test button in the Actions Applet.

3. To see how the actions changed the member, press the Diff button. The system shows the before/after snapshot of the member.

   
   Figure 33. Action Test Results

In the example above, the results show that there was an accrual of 10 points which changed the balance and availBalance of the Points purse.

Testing Expressions¶

If you are authoring Aliases in the Rule Editor and would like to test them, or you simply want to check what a specific Alias returns, you can use expression testing. To do this:

1. Click on the fx button next to any of the LHS, RHS or Action parameters. This opens the Expression Builder dialog box.

2. From the Expression Builder, select your test data set from the Test Data dropdown.

3. Press the Test button next to the Test Data dropdown.

4. The result of evaluating the expression will appear in a green box next to the View All button.

   
   Figure 34. Testing Expressions

In the example above, the Test Data Set One contains an Accrual activity. So when we try to evaluate the @Activity.type alias, we see the result is Accrual.

Admin Console Testing¶

Once you have tested your rule Conditions, Actions and Expressions, you can do a real transaction against a member to see that the rule in action and inspect the saved results from such an activity.

To perform console testing, do the following:

1. Navigate to Members from the ReactorCX sidebar menu.
2. Search for the member you'd like to test on. Please refer to Member Care Guide for more information on how to search for Member records.
3. Drill-down into the Member and switch to Activities tab.
4. Click on the Process Activity button and fill out the details of your activity.

5. Click on the Process Activity button inside the Process Activity dialog box.

   
   Figure 35. Testing from Console

After the test, results will be visible in the Process Activity dialog box under the Log tab. In addition, the Activity history will show Accruals, Redemptions, Rewards, updated Purse balances, etc. as would happen in a real-world transaction.

Field Testing via Preview¶

Once Rules are tested and migrated to Production it is still good to be able to test them before they become available to all eligible members.

The RCX system offers a Preview feature, which works as follows:

• Each Rule or Reward Policy has a Can Preview toggle.
• Each Member also has a Can Preview toggle.
• If a Member with Can Preview = Yes, and they submit a transaction such that it is eligible for a Rule/Reward Policy which also has Can Preview = Yes, then that Rule will fire even if the transaction is submitted before the Rule effective date.

What this functionality allows us to do is have field testers (Can Preview members) who are able to experience Rules and Discounts before they are officially active.

Using Flow Composer¶

Every program has a Flow that orchestrates how various groups of Rules are executed or even how individual Rules are executed. The RCX Flow Composer is a visual tool that allows drag-and-drop editing of the Flow.

The Flow is a diagram that describes the Flow of Activities from when they are received. There are three types of blocks that can be in such a diagram:

• Start Block - there is always one Start element in a Flow, and it specifies the entry point for Activities as they are received by the RCX API, Event or Batch channels.
• Rule Block - represents individual Rules can be depicted in the Flow, although that is not done for many Rules.
• Folder Block - represents a Folder and all its contents, including Rules and sub-Folders. The RCX Rule Engine will be applied to the Folder and rules will be selected automatically from all sub-folders based on their criteria.

You can think of Flow Composer as a traffic control tool, where blocks such as Folders and Rules are instances of the Rule engine that evaluate that part of the program.

Editing the Program Flow¶

To edit the Program Flow:

1. Navigate to the Programs menu item in the menu panel on the left.
2. Select and Expand the program where you want to edit the Flow.
3. Click on the Flow Composer menu item in the menu panel under the program.

Figure 36. Editing the Program Flow

Connecting up Blocks¶

Elements in the flow have a single input, and up to three outputs. The following table describes the possible outputs.

Adding Blocks¶

You can add new blocks by:

1. Clicking on the Add Block button.

2. In the Add Blocks dialog box select any Rules and Folders from the left-hand-side panel. This will add them to the Selected Elements list on the right-hand side.

   
   Figure 37. Adding Blocks to the Flow

3. Once you have all the blocks you want listed in Selected Elements, click OK.

Removing Blocks¶

To remove a block right click on the Block and click on the Delete pop-up menu.

To clear the entire Flow use the Clear Flow button located at the top right corner of the Flow Composer view.

Icons and Color-coding Glossary¶

There are several icons and colors used to depict different kinds of blocks. Below is a quick glossary of those:

Icon	Description
	Represents the single starting point of the Flow.
	Represents a rule that has both conditions and actions.
	Represents a Folder that may contain Rules and sub-Folders.
	Represents a Rule that only has Conditions and no Actions. Usually this is used to route traffic.
	Represents a Rule that only has Actions. Usually this is used to load additional data into the Context for every activity, or provide exit append data for all activities.

Validating and Saving the Flow¶

Use the Validate Flow button at the top right corner of the Flow Composer view to validate the Flow. The validation ensures that all blocks are connected correctly.

Use the Save Flow button at the top right corner of the Flow Composer view to Save the Flow. Changing the Flow requires re-publishing the program to ensure changes take effect.

Modeling Streaks¶

The RCX rule system can be used to model complex promotions which run over a long period of time, tracking the achievement of one or more goals over a span of Activities for a member. These types of promotions are often referred to as streaks, multi-step or long-running promotions.

For example, we could have a streak that provides a bonus when the customer purchases one drink, one pastry, completes one mobile order, and leaves one review - all in a specific period of time.

Common Streak Types¶

The most common streak types are listed below:

Streak Policies¶

A Streak is goverened by a Streak Policy which controls various aspects of streak behavior. The Streak Policy configuration ties together several types of rules which govern how different stages of a streak will operate. It also specifies how many goals the streak contains, and allows for goal configuration to be performed on these goals to define their behavior.

Once the Streak Policy is defined, you can deploy the streak in a Rule folder to instantiate its rules and configure them with any additional eligibility criteria.

About Streak Rule Types¶

A Streak is a group of rules, which together work to implement the behavior of the streak. The streak generally consists of several stages, each of which can be handled by a different rule. Below is a summary of the purpose of each type of rule in the streak rule group:

Adding a Streak Policy¶

To add a new streak policy:

1. Navigate to the menu panel on the left, to Programs -> Your Program -> Policies
2. Click on the Streak Policies tab.

3. Click on the Add Streak Policy button on the top left of the screen.

   
   Figure 38. Adding a Streak Policy

   • Name - A unique name across the system to identify the streak.
   • Description - Description of the purpose and summary of operation of the streak.
   • Template - A folder from where template rules will be selected for this streak.
   • Effective Date - Effective date of the streak (will become effective date for all component rules)
   • Expiration Date - Expiration date of the streak (will become expiration date for all component rules)
   • Cool Off Period (minutes) - The minimum number of minutes before a new instance of this streak can be launched, if the streak allows multiple instances.
   • Time Limit - Time limit from the time a member begins streak for it to be complete, or else it will be considered expired.
   • Instance Limit - How many times a member can execute this streak within the effective/expiration period.
   • Optin Rule - The rule which will be used to handle the opt-in for this streak.
   • Accumulation Rule - The streak accumulation rule used in this streak.
   • Evaluation Rule - The streak evaluation rule used in this streak.
   • Bonus Rule - The streak bonus rule for completing this streak.
   • Expiration Penalty Rule - Streak expiration rule to govern what to do in case of expiration.
   • Progress Rule - Streak progress rule to govern how progress is reported.

Editing Streak Policies¶

To edit details of a streak policy:

1. Navigate to the menu panel on the left, to Programs -> Your Program -> Policies
2. Click on the Streak Policies tab.
3. Use edit action button on the policy you want to edit.

Adding Goal Policies to a Streak Policy¶

The Streak Policy contains configurations for each goal, known as Goal Policies. They are similar to a Streak Policy and govern the behavior of the streak with respect to each goal.

To add a Goal Policy to a Streak Policy:

1. Navigate to the menu panel on the left, to Programs -> Your Program -> Policies
2. Click on the Streak Policies tab.
3. Click on the row of the Streak Policy where you want to add goals.

4. Click on the Add Goal Policy button to above the Streak Goals applet

   
   Figure 39. Adding Goal Policies

   
   Figure 40. Add Goal Policy

   • Name - goal name - e.g. Parfait Purchases.
   • Description - goal description indicating what the goal is tracking.
   • Time Limit - if the goal is time-consrained, the number of minutes in which the goal needs to be achieved.
   • Time Limit Snap To - how the time limit is measured. It could be from Start of Streak or from Start of Goal.
   • Cool Off Time - minimum time (in minutes) between goal advances. This throttles how frequently the goal can be updated.
   • Target - the numeric target which when achieved or exceeded will lead to goal completion. This could be something like number of purchases, or total amount spent, etc. The target is compared to the value accumulated by the Accumulation rule.
   • Accumulation Rule - The goal accumulation rule to use for this goal.
   • Bonus Rule - The bonus rule to use for this goal.
   • Expiration Penalty Rule - The expiration rule to use for this goal.

Editing Goal Policies¶

To edit details of a streak policy:

1. Navigate to the menu panel on the left, to Programs -> Your Program -> Policies
2. Click on the Streak Policies tab.
3. Select the Streak Policy.
4. Click anywhere on the Goal Policy to edit it.

Deploying a Streak Policy¶

Once a Streak Policy is configured, it can be deployed within a folder in the Rule flow. To deploy a streak:

1. Navigate to the folder where you'd like to deploy the streak.
2. Use the Deploy Streak button on the top-right of the rules view.

Figure 41. Deploying a Streak Policy

When a Streak Policy is deployed, a sub-folder is created with the name of the Streak Policy. All the component rules configured in the policy will be present in that folder.

Figure 42. Streak Rules

The rules for the streak are placed in the folder. Additional configuration can be done on the rules, such as:

1. Select products for each goal - using the Goal Acc rules.
2. Select any specific elgigibility for goal accumulation - again using the Gaol Acc rules.
3. Specify bonus actions or point values on the bonus rules (either for goal completion or streak completion)

Once the deployed rules for the streak are fully configured, publish the program to make the streak active.

Setting up Common Eligibility¶

A streak usually comprises several rules. It is often the case that there are eligibility criteria that will be common across all rules, such as segments, effective dates, locations, etc.

It is recommended to bulk-edit the entire rule-set and change all these settings together for all the rules, in order to ensure they are the same across the rules of the streak. See the Working on Multiple Records of the User Interface Guide for instructions on how to change parameters on multiple records in bulk.

Discounting Engine¶

RCX includes a powerful real-time discounting engine, which can apply discounts on an incoming Activity, and can also determine the best combination of available rewards, offers and global offers that would give the highest discount to the customer. This process of determining the best discount combination is also known as discount arbitration.

The discounting engine in RCX is configured through the Reward Policy objects in the system. They govern all aspects of discounting, including:

• Discount Eligibility based on Segment, Location, Products, Time of Day, Effective/Expiration Dates, etc.
• Discount Limits - for example, per Member, per Offer, per Week, per Month usage limits, set dollar or count budgets, etc.
• Discount Types - for example, Ticket-level, Mix & Match, Combo, BOGO, etc.

Configuring Discounts through Reward Policies¶

To configure discount behavior, you need to configure a Reward Policy for the given discount.

1.Navigate to Programs>Policies. By default, the Reward Policies tab is opened in the Policies tab.

Figure 43. Reward Policies Window

2.Click on the Add Reward Policy button provided in the top-right corner of the policies window.

3.A Reward Policy dialog box is displayed.

Figure 44. Reward Policy Window

5.Enter all the required attributes. And Click OK to confirm or Cancel to discard your changes.

• Name: Give the Reward name.

• Description: Describe the purpose of the Reward.

• priority: Enter the priority of the policy.

• Can Preview: Select this option to true to use the policy in arbitration before the effective date.

• Activity-based Expiration: Select this flag to expire the points of any accrual item expire based on the last activity date of the Member.

• Appeasement: Select this flag to true to restrict the support team to give Offers/Rewards only to certain loyalty members by filtering just Appeasement marked offers and Rewards. this is only applicable to Offers and Rewards.

• Effective Date: The date from which a Reward, Offer, or the Global Offer is active or effective.

• Expiration Date: The date that a Reward, Offer, or the Global Offer expires once it becomes ineffective.

• Expiry warning days: A notification will be sent to the member before the Specified number of days here, notifying about the expiration date of the Reward Policy.

• Reward Image URL: It is a text field that accepts an image URL, Representing Reward, Offer, and the Global offer.

Three different types of Rewards or Coupons can be configured in RCX:

Rewards

Rewards are earned coupons through the program rules, such as free items, discounts, etc. They are usually generated by redeeming points from a redemption catalog. The Rewards are stored in a member's Reward Wallet and are available for use during discounting.

Offers

Offers are similar to Rewards, but are kept in a separate Offer wallet, and are usually not earned directly via rules (although they can be). Usually these offers are loaded externally from companies which provide clippable coupons and other types of items that need to be dynamically loaded into a specific member's account.

Global Offers

Global offers are similar to Offers, however, they do not get loaded in a member's wallet. Rather they are available to members (subject to eligibility criteria), and can be used by members without the need to first be loaded into an Offer wallet. The best use case for Global Offers is when large numbers of members (or all members) are eligible for offers, and it is impractical to keep loading Offers in wallets, especially if the redemption rate is low.

When Global Offers are used by members, the system loads the Offer in the member's wallet on the fly, and marks it used, all in the same transaction, thus saving the need to store these Offers before they are used.

Reward Policy Eligibility¶

Please see the section on Common Eligibility Criteria for a detailed discussion on all eligibility parameters for Reward Policy eligibility.

Discount Methods¶

A discount is the reduction of the regular price of goods or services, or something being sold at a price lower than the item is usually sold for.

1.Navigate to Programs>Policies>,Reward Policies, click on the Discounts tab and select the type of discount from the drop-down.

Figure 45. Discounts Tab

There are four different types of discounts that can be configured in the Reward Policies using RCX:

• Mix and Match
• Combo
• Combo List
• Ticket

Mix and Match

A Mix-and-Match discount allows a discount to be applied when the member purchases one or more products from a pre-specified group. Typically, Mix-and-Match discounts are offered by sellers or manufacturers to encourage customers to purchase in larger quantities.

Combo

A Combo discount gives customers a fixed, reduced price when purchasing a pre-defined bundle of products.

Matching products in different groups (i.e., primary, secondary, or tertiary) takes place here, and setting a Total Price for the entire package is configured.

The purpose of a Combo discount is to increase the number of items sold or to bundle popular items together with less popular items or to get customers to try different products.

Combo List

A Combo List discount allows a bundle of products to be discounted by discounting the individual items in the bundle with separate discount parameters.

Ticket

A Ticket discount gives the customer a fixed-amount discount on the total amount of an entire purchase. In some cases, the total amount will exclude the price of certain products (e.g., Alcohol) for a Ticket discount.

Ticket discounts are an excellent way to boost repeat business.

• Discount UPC: When the offer is applied, the UPC (A Unique Code) code given here gets auto-populate to the products selected.

Pricing Types in Discount Methods¶

The discounts on Reward Policies have the reduced price being applied in three different ways as described below:

Figure 46. Discounts Tab

• Package Percent Off: A percentage off the price of a product, bundle, or bundle item

• Package Amount Off: Cash amount off the price of a product, bundle or bundle item

• Package Price: Selling bundled products for a fixed price

To configure the pricing, you will also need to specify:

• Value: Enter the number of units to specify the maximum discount percentage or dollar value.

• Maximum Discount Value: Allows for specifying the maximum discount amount for one application of the offer. It is only applicable when the pricing type is Package Percent Off.

The different pricing types that are supported for each discount method is as mentioned below:

Discount Limits¶

Discounts limits are configurations used to restrict the usage and define the period of expiration of Rewards, Global Offers, and Offers.

1.Navigate to Policies>Reward Policies, Click Discounts tab to view the Discount limits.

Figure 47. Discount Limits

Below are some of the limits which apply to various discount methods in ReactorCX:

• Uses Left: The remaining number of a Reward, Global Offer, or Offer that is still available to a member for a single instance or utilization of Reward Policy.

• Transaction Limit: Indicates the number of times a Reward Policy can be used within a transaction.

• Per Day Limit: A Global Offer / Offer can be configured to have a use limit per customer per day.

• Per Week Limit: A Global Offer / Offer can be configured to have a use limit per customer in a week.

• Per Offer Limit: Indicates the maximum transactions use count for each customer for Global Offer / Offer.

Typical Use Cases¶

• Combination of per day limit and per week limit

If the Global Offer / Offer is limited to three (3) per customer per day and two (2) per customer per week, then the offer can only be used twice in a day or two times a week by the customer.

Figure 48. Per day and per week Offer Combinations

• Combination of per week limit and per offer limit:

If the Global Offer / Offer is limited to five (5) per customer per week and three (3) per customer per offer, then the offer can only be used thrice in a day or three times in a week by the customer.

Figure 49. Per week and per Offer Combinations

• Combination of per Day limit and per offer limit:

If the Global Offer / Offer is limited to one (1) per customer per day and 30 per customer per offer, then the offer can be used daily for 30 days.

Figure 50. Per day and per Offer Combinations

• Combination of per day limit, Per week limit, and per offer limit:

If the Global Offer / Offer is limited to five (5) per customer per day, ten (10) per customer per week, and twenty (20) per customer per offer, then the offer can be used five times in a day or ten times in a week, till the maximum count is reached mentioned in per offer limit.

Figure 51. Per day per week and per Offer Combinations

• Count Limit: The maximum number of redemptions that a Global Offer or Offer or Reward is allowed.

• Budget: The total discount amount disbursed for a Global Offer / Offer.

Tier Policies¶

The tier policies are configurations to define the classification of members based on the milestones they have been awarded. There is a certain criterion to achieve these milestones.

Tiers¶

Tier is an attribute associated to a member to define an order between Levels to rank them in order of achievement and to categorize based on the achievements of the member.

Any number of tiers can be created and used. By default, all the Tiers configured in the Tier Policies of the program are assigned to the member when the member enrolls for the program. After reaching a certain number of points, The member is upgraded to the next tier level and receives exclusive benefits from that tier.

Tier Levels¶

Tier level is a grouping based on the achievements of the member. A tier can have multiple levels, and one level is marked as default level, which gets assigned to the member when the member enrolls for the program.

The member qualifies for a gold level change by accumulating greater than or equal to the 1000 purse points reflecting in the accrual applet.

Figure 52. Upgrade tier level in Rules Window

Configuring Tier Policies¶

1.Navigate to Programs>Policies, By default the Reward Policies tab is opened in Policies tab.

Figure 53. Policies Window

2.Click Tier Policies tab.

Figure 54. Tier Policies Window

3.Click on the Add Tier Policy button provided in the top-right corner of the policies window.

4.A Tier Policy dialog box appears as shown, Enter the name of the tier and click on Add Level tab. Tier Customization dialog box is displayed.

Figure 55. Tier Customization Window

• Name: Enter the name of the tier.

• Level Name: Enter the name of the tier level.

• Threshold: Set the number of qualifying points required to reach this level.

• Expiry warning days: Specify the number of days before expiration to notify the member.

• Color: Choose a color to represent this tier.

• Expiry Unit: Select the unit of time that defines the tier's validity duration — choose from Hours, Days, Months, or Years. This determines the type of time measurement used for expiration.

• Expiry Value: Enter the number of time units (as selected in Expiry Unit) after which the tier will automatically expire from the date it was assigned.

• Expiration Snap To: Defines the starting point from which the expiration period will be counted.

• Default Level: Enable this option to set this tier as the default level assigned to members upon enrollment.

5.Click OK to confirm or cancel to discard your changes.

Tier Change Rules¶

In the RCX Rule Engine, the rules which control how Tiers are assigned are called Tier Rules and usually reside in a separate Folder. The Tier Rules are not very different from any other type of rule in RCX:

• The Conditions of a Tier Change rule check to see if a member qualifies for a tier, based on achieved balance of points or other criteria.
• The Set Tier or Upgrade/Downgrade Tier Actions can be used to move Tier levels for a member if the conditions for such moves are met.

Below is an example rule, from the Southwest Airlines Rapid Rewards Program, which sets the tier of a member to A-List if they either completed 25 or more trips or had a balance in their Qual Points purse equal to or greater than 35,000 points.

Figure 56. Tier Change Rule

Purse Policies¶

The purse policies are configurations to define the different categories of virtual currencies tracked for a member of the program. A Purse is an object that holds the balance and other earn statistics for a specific virtual currency. Purses can be used to track not just points, but just about any kind of metric which can be expressed numerically - for example, there could be a Purse that tracks the number of Lifetime Transactions, or a purse that acts as a punch card and resets every X transactions.

Purse Policy Configuration¶

1.Navigate to Programs>Policies.

2.Click Purse Policies tab.

Figure 57. Purse Policies Window

3.To add a new policy, click on the Add Purse Policy button provided in the top-right corner of the policies window. ALternatively, use the edit action button to the left of the policy name to edit an existing policy.

4.A Purse Policy dialog box appears as shown.

Figure 58. Purse Customization Window

General Settings¶

Enter all the required attributes and Click OK to confirm or Cancel to discard your changes.

• Name: Specifies the name of the purse - e.g. Points, Cashback, Drinks, Lifetime Transactions, etc.
• Description: Describes the purpose of the Purse.
• Point Multiplier: Defines the factor by which points are multiplied.
• Overdraft Limit: The maximum overdraft amount allowed for the purse - this means negative balances are possible.
• Reverse Sign: Option to reverse the sign of the transaction amounts.
• Primary: Specifies if this purse policy is the primary one, meaning it will be more prominent in various types of UIs.

Escrow Settings¶

Escrow allows a purse to hold points earned for a specified period of time, after which they can become available for redemption.

• Escrow Unit: This is the drop-down to select the measure of units for escrow.
• Escrow Value: Enter the number of days after which purse points are available for redemption.
• Escrow Snap To: Defines the period when the purse points are available for redemptions. Calculated from the date the Activity (qualifying accrual of points) is processed for the member plus the value specified in the Expiry Unit and Expiration Snap To. The duration calculated as part of the Escrow Snap To is used to define the Escrows On field value in accrual items for Accrued Points for this activity.

Qualification Period Settings¶

If a purse is tracking a qualifying currency, then the qualification period settings can be used to define the qualifying period, and a series of purses is used to track periods over time. To allow these purses to be recognized as a group, we use the Group attribute. For example, if we could have a group called Tier Credits and 3 purse called Tier Credits - P1, Tier Credits - P2 and Tier Credits - P3 all marked as the same group. This basically means that Tier Credits is a qualifying currency and for each qualifying period a different purse will be used to track it.

• Group: Defines the group that the purse policy is associated with.
• Period Start Date: The starting date of the period for the purse policy.
• Period End Date: The end date of the period for the purse policy.
• Period Close Date: The date when the period officially closes.
• Period Time Zone: The time zone to be used for the period dates.

Configuring Purse Aggregates¶

Purse aggregates are used to define tracking of purse balances for different periods - e.g. daily, monthly, weekly, etc. Selecting this option automatically creates an aggregate with the same name as the purse for the specified periods.

• Aggregates: Allows selection of aggregates if applicable.

Configuring Color-coded Balance Ranges¶

You can enter balance ranges that can be color-coded in the UI. To do that, for a purse policy, click the Add Range button and enter the following:

• Start Range: Enter the lowest value of the points that need to be color-coded.

• End Range: Enter the highest value of the points that need to be color coded.

• Color: Select the required color to set the range.

Expiration Settings¶

A purse can be configured to expire after a specified period of time. This expiration can be set up as a sliding window expiration. If the expiration is activity-based, depending on the option selected in the Expiration Type, the entire purse balance will expire after a set period of inactivity.

• Expiry Unit: Use either hour (s) or days (s) for the expiration of purse policy.
• Expiry Value: The number of units to expire the purse policy.
• Expiration Snap To: Defines the starting point from which the expiration period will be counted.
• Expiry warning days: Allows specifying number of days before expiration to issue an ExpirationWarningEvent. There could be multiple such numbers separated by a comma. For example, specifying 5,10,15 means that the system will send an ExpirationWarningEvent 15, 10 and 5 days before the points expire.

Figure 59. Purse Policy Default Expiration Window

Automatic Expiration Settings¶

These settings define how and when a purse should automatically expire, based on the Expiration Type. Automatic expiration is triggered through backend processes and controlled by the scheduling configurations below.

• Expiration Type: Specifies the method by which expiration is determined.
  • Activity-Based: Expiration is triggered when a member has been inactive for a defined period.
  • Time-Based: Expiration occurs when the accruals in the purse reach their expiration date.
  • Custom: Custom expiration logic defined according to specific business requirements.This will not support auto expiration on purse.
• Automatic Expiration: Enables or disables auto-expiration for the purse. If enabled, expiration is triggered automatically by a backend Apache NiFi flow.
• Inactive Days: Defines the number of days a member must remain inactive before their purse balance expires. This is applicable only when the Expiration Type is set to Activity-Based. Inactivity is based on the transaction types specified in the Activity-Based Expiration Filter.
• Schedule Starts From: Sets the date when the auto-expiration scheduling begins. This is applicable only if Automatic Expiration is enabled.
• Schedule Effective To: Defines the end date for the auto-expiration schedule. Defaults to the expiration date in the associated pursePolicy if not specified. This is applicable only if Automatic Expiration is enabled.
• Repeat Interval: An integer value that determines how frequently the expiration process is repeated. This is applicable only if Automatic Expiration is enabled.
• Frequency: Defines the time unit for the Repeat Interval. Accepts Days, Weeks, or Months. This is applicable only if Automatic Expiration is enabled.

Figure 60. Purse Policy Expiration Window with Auto Expiration

Figure 61. New Purse Policy added Window

Configuring Purse Rules¶

There are many ways to affect the balance of a Purse - from simple base point rules, to bonus points promotions, to combinations of Rules that drive long-running promotions also referred to as streaks.

In addition, all eligibility criteria specified in the Rule can be used as shown in

Sample Accrual Rule¶

Below is a basic accrual rule, which does the following:

• Checks to see if the Activity.type submitted to the system is Accrual.
• If that is true, add the number specified in Activity.value field to the Points purse of the member.

Figure 62. Sample Accrual Rule

Sample Redemption Rule¶

Below is a basic redemption rule, which does the following:

• Checks to see if the Activity.type submitted to the system is Redemption.
• If that is true, decrement the number specified in Activity.value field from the Points purse of the member.

Figure 63. Point Redemption Rule

Program Migration¶

A program is typically developed in a separate environment from the one which actually executes the rules in Production. Program Migration refers to the process of exporting the program from a non-Production stage environment and importing it into Production and making it operational.

ReactorCX offers a simple and straightforward approach to doing these migrations via export/import of program definitions.

Exporting the Program¶

Full Export¶

To export the Program Definition:

1. Navigate to Programs in the menu panel on the left.
2. In the list view find the program you want to export and click on the export button as shown below.
3. The system will export a JSON file and download it.

Figure 64. Program Export

Program Selective Export¶

Use "Selective Export" to choose specific data elements for export, providing flexibility and efficiency by exporting only what is necessary.

1. Navigate to Loyalty Programs: Click on the "Programs" menu item in the left-hand menu to access the Loyalty Programs view.

2. Select the Program: In the list view, locate the program you wish to export.

   

   • After clicking the "Selective Export" button, a popup will appear where you can proceed to select entities for export.

   

3. Choose Specific Entities for Export: There are three methods to select the entities to export:

   • Multi-Select Dropdown: Choose any number of entity names from the dropdown.
   • Entity Names Input Field: Enter a list of entity names separated by commas.
   • Upload a Text File: Upload a text file with each entity name on a separate line.

4. Export the Program: Click "OK" to initiate the export.

5. Download the JSON File: The system will generate and download a JSON file containing the selected entities.

Importing the Program¶

After creating a Program Definition export file, it can be imported into the next environment in its entirety or selectively, incorporating only specific components as needed.

Full Import¶

To fully import the program from a Program Definition export file:

1. Click on the Programs menu item in the left hand menu to navigate to the Loyalty Programs view.
2. Click on the Import button on the top-right corner (refer to the image above) of the screen to bring up the "Import A Program" dialog box.

3. Click on the Browse button and navigate to the Program Definition export file you want to import.

   
   Figure 65. Program Import

4. Choose whether you want to immediately publish changes imported using the toggle at the bottom of the Import Program dialog box.

5. For each object comprising the Program Definition, you can select options on how to import it.
   • Import - whether or not to import the program element.
   • Match Mode - if importing, whether to update matching elements in the target environment, or just resolve them without changing them.
     • Resolve - this setting does not update matching elements in the target environment.
     • Update - this setting updates matching elements in the target environment.
   • Delete Mode - if importing, and the element of the program is not present in the import but present in the target environment.
     • Leave - this setting does not delete any objects in the target environment that are not present in the import.
     • Delete - this setting deletes anything that is not present in the Program Definition export file but is present in the target environment.
6. Click OK to initiate the import job.

An import could take a minute for large programs, so the system initiates the import in the background. To check on the status of this job, use the Status button located at the top-right corner of the Loyalty Programs view.

Figure 66. Program Import Job Status

Selective Import¶

Using "Selective Import", we can control the changes to be migrated to the next envrionment.

1. Click on the Programs menu item in the left hand menu to navigate to the Loyalty Programs view.
2. Click on the Selective Import button on the top-right corner of the screen (refer to figure "Program Export") to bring up the "Import A Program" dialog box.

3. Click on the Browse button and navigate to the Program Definition export file you want to import.

   
   Figure 67. Program Selective Import

4. There are three distinct methods for choosing the specific entities to import. For each of the entities listed,

   • Choose any number of entity names using the multi-select dropdown.
   • Enter a list of entity names separated by commas in the "Entity Names" input field.
   • Upload a text file that includes the entity names, each on a separate line.
5. For Named Lists import, you can use either the Named Lists toggle or the Named Lists dropdown, but not both simultaneously.
6. You will find a checkbox labeled Refresh Selected Named Lists, which is checked by default. You can uncheck it if needed. This checkbox allows you to refresh the named lists included in the import. This checkbox takes effect only when the Named List Toggle is checked or when a named list is included in a Named List Dropdown. Only newly inserted or updated named lists are affected by this refresh operation.
7. To import Named Lists, you can either enable the toggle to import all Named Lists, or use the dropdown to select specific Named Lists. Both options cannot be used at the same time.
8. Click OK to initiate the import job.