Understanding Next-Best-Action Designer components
The Next-Best-Action Designer user interface provides an easy to use, guided way to define, manage and monitor your next-best-actions across your inbound and outbound channels.
Next-Best-Action Designer lays out the set of steps that need to be completed to fully define your next best actions. Each tab contains a set of metadata that is used by the strategy framework to determine the personalized set of actions for customers.
The following tabs are available:
Use the Taxonomy tab to define the traditional issue and group hierarchy for decisioning. All issues and groups should be defined here instead of on the Proposition Management landing page.
A business issue is the purpose behind the actions you offer to your customers. For example, actions which started with the purpose of retaining existing customers should be grouped under the business issue of Retention. Actions started with the purpose of acquiring new customers belong to the business issue of Acquisition.
Business groups organize customer actions into categories. For example, as part of the business issue of Acquisition, you can create groups for products like Credit Cards, Mortgages, or Personal Loans, with the intention of offering these to potential new customers.
In addition to defining the issues and groups, you can add a short and long description for each issue and group that helps explain the intent and business purpose.
By default, Pega Marketing and Pega Customer Decision Hub refer to the recommendations that come out of the strategy framework as actions. If you would like to refer to these actions differently for a specific group of actions, you can do so under each group. For example, you can refer to actions in the group as Nudges, and to actions in the group as Promotions.
Saving the Business structure generates the appropriate Strategy Result (SR) classes. In addition to creating new issues and groups, you can activate existing issues and groups as well.
Use constraints to specify outbound contact limits (for example, one email per week, two SMS per month), as well as to limit overexposure to a specific action or group of actions through contact policies.
Customer contact limits
Limit the number of interactions which a customer can receive over a given period of time on a specific channel. For example, you can decide that you do not want your customers to receive more than two emails per week. When in Edit mode, you can open the contact limit rule directly and make any required changes. This rule is automatically saved into your implementation ruleset as part of the Context Dictionary generation process.
Contact policy library
Define suppressions, that is, automatically put an action on hold after a specific number of outcomes are recorded for some or all channels. For example, an action can be suppressed for a customer for seven days after the customer has seen an ad for that action for five times. Suppressing or pausing an action prevents over-saturation by limiting the number of times that a customer is exposed to the same action. This limit is enforced by the strategy framework and stored in a decision data record (DDR). Contact policies are associated with an action or group and enforced by the strategy framework. The check as to whether a customer has exceeded a specific limit is handled as part of the ProcessResponse mechanism.
Through the Next-Best-Action Designer user interface, you can select an outcome and indicate if this outcome applies to the individual action to any action within the same group and timeframe. After you specify these properties, you can add a suppression for a specific channel or one that applies to all channels.
Engagement policies allow users to define when specific actions or groups of actions are appropriate for customers. There are four types of engagement policies:
- Eligibility – The criteria which the customer must fulfill in order to qualify for the action or group of actions. For example, an action may only be available for customers over a specific age or living in a specific geographic location.
- Applicability – The criteria which determine if this action or group of actions is appropriate at this point in time. For example, a discount on a specific phone model may not be relevant for a customer who already owns a phone of this type.
- Suitability – The criteria which must be true in order for the action or group of actions to be deemed in the best interest of the customer. For example, a new credit card offer may not be appropriate for a customer who is likely to default on payments.
- Contact Policy – The policies which determine when an action or group of actions should be suppressed and for how long. For example, you can suppress an action after a specific number of promotional messages have been sent to customers.
The Engagement policy tab generates a number of artifacts, including a proposition filter for each policy type and a group level strategy. The strategy imports the actions, ensures that the action is active, and then applies a series of proposition filters. The output of the strategy is a set of eligible and appropriate actions to be evaluated by the strategy framework.
These generated artifacts are managed by Next-Best-Action Designer and should not be modified directly. Any manual changes will be overwritten the next time that the group configuration is saved.
Arbitration determines how the strategy framework prioritizes the list of eligible and appropriate actions that come out of each group. The configuration and metadata for your arbitration options are stored in several decision data rules (DDR) which are used by the strategy framework.
The Next-Best-Action strategy framework includes adaptive models that learn at the action as well as the treatment level. These models apply the principles of outcome optimization at the treatment level and can be extended if you wish to apply advanced techniques or challenge the default models.
The propensity used in arbitration can be applied from the treatment level or at the action level. It is recommended to use treatment-level propensity, since it provides the best treatment on the best channel for a particular customer.
Real-time contextual data is an important part of making highly relevant recommendations. Context weighting allows you to assign weighting for a specific context value to all actions within an Issue or the Group.
The contextual weighting definitions are stored in a decision data rule (DDR), which is managed by the Next-Best-Action Designer and used by the strategy framework.
You can specify the value of an action in the definition of that action. If more sophisticated calculations are needed, the extension strategy CalculateValueExtension can be customized to your specific requirements.
To highlight or push a particular action or group of actions, specify a weight on the individual action or add a business purpose weighting and selecting an issue only or group and then the weighting value.
These levers can be toggled on or off, which determines whether or not these weightings are applied to the final prioritization formula.
Next-Best-Action Designer comes with a full set of channels which are part of the strategy framework. These channels can be toggled on or off. If a channel is toggled off, its status is stored in a decision data rule (DDR) and the related part of the strategy framework is turned off. Setting the toggle to on reactivates the related part of the strategy framework.
To add additional channels, edit the ChannelSettings DDR, and then implement these channels in the channel extension strategies within the framework.
The Next-Best-Action strategy framework can be invoked by real-time channels through our Container REST API and Kafka event stream, as well as on a scheduled basis.
As you define one of these triggers, Next-Best-Action Designer generates a dataflow with a strategy based on the specified business structure. These generated dataflows can be seen on the Dataflows landing page if View system generated flows is enabled.