The Next-Best-Action strategy framework provides the best practice for implementing enterprise-level Next-Best-Action. The strategy framework is applied to the top, issue or group level of the business hierarchy after you define a trigger in the Channels tab of the Next-Best-Action Designer. Each trigger generates a strategy which first references the correct level of the business structure, and then imports propositions and applies the Eligibility, Relevancy and Suitability rules. The strategy then passes these results to the strategy framework for processing.
Note: This article describes the Next-Best-Action framework shipped with Pega Marketing™ 8.4 and Pega Customer Decision Hub™ 8.4. For Pega Customer Decision Hub 8.5, see the Pega Customer Decision Hub User Guide on the Pega Customer Decision Hub product page.
The configuration information managed by the Next-Best-Action Designer interface is stored in a set of decision data rules (DDRs). The strategy framework references the RealtimeControl sub-strategy and pulls in the appropriate DDR based on the strategy. These DDRs should not be updated directly because they are managed by Next-Best-Action Designer. If you use the Revision Management functionality, these DDR rules are automatically packaged as part of the change request.
Realtime Controls strategy
When referencing this sub-strategy, an individual DDR may be specified as a single component within the strategy to avoid retrieval of unneeded controls.
Many of the settings are in the form of key / value pairs using the properties below:
SettingName - the key, or name of the setting
SettingValue - the value of the setting
You can obtain individual setting values by using a Filter shape based on the SettingName property.
The RealtimeControls strategy
Trigger strategy
A trigger strategy is generated after you define a trigger within Next-Best-Action Designer and specify the business structure to apply. This strategy is referenced by a data flow, which is also generated and managed by the system.
A separate trigger strategy is generated for each business structure specified as part of a trigger configuration and the strategies are named based on the business structure as shown in the following table:
Issue
Group
Trigger strategy name
Example
All issues
All groups
Trigger_NBA_TopLevel
Select <issue>
All groups
Trigger_H_NBA_<issue>
Trigger_H_NBA_Retention
Select <issue>
Select <group>
Trigger_H_NBA_<issue>_<group>
Trigger_H_NBA_Retention_Cards
The layout of the strategy depends on the configuration of the context dictionary. The following example shows an implementation of multiple Subscribers within an Account, for example, for a telecoms application. Note that this example is for all issues and all groups.
The Trigger strategy
NBA TopLevel strategy
This strategy combines references to the sub-strategies for each Business Issue defined in the NBA Taxonomy; it is generated by Next-Best-Action Designer and is not modifiable. The example below is for a configuration with three business issues: Selling, Retention and Acquisition.
Sample configuration of the NBA TopLevel strategy
Issue-level strategies
A separate strategy is generated for each issue in the taxonomy, each of which is included in the NBA_TopLevel strategy. These strategies are not modifiable.
The example below is for a Retention issue and named H_NBA_Retention.
This strategy combines the sub-strategies for each group in the issue defined in the taxonomy. The example below contains two groups: Bundle and Discount.
Sample issue-level strategy
Group-level strategy
A group-level strategy is generated by Next-Best-Action Designer for each active group within your business structure. If a trigger is defined for all groups or issues, multiple group strategies are invoked.
These strategies filters actions by the pyIsActive property, process any All Issues and Groups functionality, and then apply the generated engagement policy filters for Eligibility, Applicability and Suitability.
There is an extension point sub-strategy for the issue and group after all filtering has occurred, named NBA_<Issue>_<Group>_Ext, where <Issue> and <Group> are the names of the issue and group respectively.
The example shown is for the Retention issue and Discount group.
Sample group configuration
NBA_AllIssues_AllGroups Strategy
This is similar to a group-level strategy, but with no action import and without the all issue and group processing (which is this strategy). In this strategy the proposition filters contain only default conditions.
The Proposition Filter shapes referenced in this strategy are generated from the Eligibility, Applicability and Suitability rules defined in the Next-Best-Action Designer under the Engagement policy for all groups. If no such Engagement policy is defined, then the proposition filters will pass all actions.
The extension point sub-strategy for this strategy is named NBA_AllIssues_AllGroups_Ext.
NBA Strategy framework
This is the second strategy executed by any of the trigger strategies.
The strategy framework is shipped with Pega Marketing and is managed by Next-Best-Action Designer. There are several extension points within the framework. To ensure upgradeability, avoid overtaking any part of the framework that is not a designated extension point. If you cannot implement the functionality you require using the extension points and feel that you need to overtake any part of the framework, please reach out to the Pega team before doing so.
The figure below shows the whole strategy framework. The following sections describe individual components of the framework in more detail.
The NBAStrategyFramework strategy
External Input through to Constraints
External input includes imported active actions that have already had individual group-level and All Group level engagement policies applied.
The first component within the strategy framework is an extension point named NBAPreProcessExtension that is used for any action pre-processing which you might need to perform.
Customer states
The CustomerStates strategy filters actions based on the customer’s current journeys. This capability is a placeholder and will be implemented in a future release of Next-Best-Action Designer.
Constraints
The Constraints strategy enforces any actions which need to be suppressed based on the associated contact policies. The strategy imports the suppression records, known as Action Insights, and filters out any groups or actions which have matching suppression records.
These constraints are only applied to non-transactional actions. Transactional actions are passed straight through.
Constraint components
Action scoring through to control group handling
Components: action scoring, treatments and channels, control groups
Action Scoring (ActionLevelPropensity) strategy
The ActionLevelPropensity strategy is responsible for applying an adaptive model for each action and calculating the propensity across eligible channels.
ActionLevelPropensity strategy
This strategy first expands the number of actions by the number of active and eligible channels using the CreateEligibileChannels strategy.
Actions can be designated as transactional in nature, i.e. they are always intended to be delivered and do not require any arbitration. Transactional actions are filtered out and bypass analytics processing.
Non-transactional actions are directed to the PredictActionPropensity Prediction strategy, and then to the ActionLevelPropensityExt extension point sub-strategy.
Finally, the actions are divided into adaptive and non-adaptive streams based on the ApplyAnalytics property, and the non-adaptive stream sets the propensity based on the action starting propensity, whereas for the adaptive stream these values are calculated by the PredictActionPropensity strategy.
The Expand Actions by Active Channels (CreateEligibileChannels) strategy
This strategy determines the active channels as specified in Next-Best-Action Designer, as well as the active channels designated on the treatment tab of the action. If the trigger is from an inbound channel, then only that specific channel is eligible and processed.
The CreateEligibileChannels strategy
The top section of the strategy evaluates each of the real-time controls that determine which channels are active, and also checks the “Channel treatment processing” control setting. The Filter shapes that select these settings are then referenced by other components in the strategy to evaluate which actions are eligible for each eligible channel.
Actions by eligible channels
NBA Actions are fed in through the External Input shape and are split into Outbound and Inbound streams for further processing based on the value of Primary.ContainerPayload.Direction. They are then further subdivided based on whether Channel treatment processing is required – if it is not required, default treatment settings are applied, otherwise pyChannel and pyDirection are set for each eligible channel.
An extension point is provided by the CreateEligibleChannelExtension sub-strategy, in which additional eligible channels may be added.
The Outbound section is shown below, and the inbound section follows a similar pattern. Note that there is provision for including any non-standard channels (Add Other Outbound Channels) so long as they have been defined within the real-time controls.
Outbound section
Predict Action Propensity Prediction Strategy
PredictActionPropensity is a Prediction strategy that is accessible for modification from Prediction Studio.
It starts by executing the OmniAdaptiveModel that is applicable to all actions and channels. The context for this model is issue, group, name, channel, and direction.
PredictActionPropensity strategy
To improve the overall model performance, this strategy applies several techniques to the propensity calculation as described below.
Random Control Group
By default, 2% of the actions receive a random propensity between 0 and 1. A certain amount of randomness is always important to ensure the models continue to learn new patterns.
This is achieved by calculating a CustomerHash value between 0 and 100 based on the Customer Id (pySubjectId) and the month name, and selecting 2% for a random “Control” group, and the remaining 98% for the “Test” group (using the Select Treatment Switch rule). Including the month name in the hash string provides each customer with a value that will remain constant for one month such that the customer remains part of the same control group for that month.
Outbound Model Maturity
For Outbound interactions, if the Outbound model maturity real-time control is true, the HandleModelMaturity sub-strategy is invoked.
HandleModelMaturity strategy
The purpose of this strategy is to exclude Actions (and Treatments at a later stage) that have recently been introduced and for which there is little evidence on which the models can be trained.
Actions that are deemed to be already mature bypass this process via the Mature actions Exclusion rule. For Actions that are less mature, an analytical method is used to filter out a portion based on their maturity (the less mature, the higher the proportion), and then the remaining Actions have their propensity adjusted using Thompson sampling.
Propensity Smoothing
Finally, propensity smoothing is applied, resulting in AdjustedPropensity. Adjusted propensity uses a weighted average, taking into account StartingPropensity (at a weight of 1) and StartingEvidence (at a weight of 25) to ensure that new actions have a high initial propensity, which gives them a fighting chance against existing actions. After enough responses are received, the strategy shifts towards to using the model propensity.
Treatments and channels
The Treatments & Channels (TreatmentsChannels) strategy first checks if treatment processing is enabled based on the Channel treatment processing real-time control setting via the Handle Treatment Processing Switch rule. If treatment processing is disabled, actions are not joined with their associated treatments for the purpose of running analytics.
If Treatment Processing is enabled Outbound and Inbound channels are prepared separately prior to Treatment level scoring.
The TreatmentsChannels strategy
Outbound Channels
The OutboundChannels sub-strategy links actions with the treatments for all of the outbound channels; a separate sub-strategy is called for each of Email, SMS, Push, Paid, Assisted and Other (custom channel). After the action is linked to one or more treatments, the customer contact limits (outbound limits) are applied by the OutboundLimits sub-strategy to ensure that you do not over-communicate with a customer on a particular channel.
An extension strategy OutboundChannelPreferences is available to implement any customer preference filtering, for example, that the customer does not wish to be contacted through SMS. This is a placeholder strategy and needs to be implemented if you wish to take advantage of this.
This strategy only applies when the Primary direction is Outbound or has not been specified (which implies it is a batch run). The individual channels must also be active on each action.
The OutboundChannels strategy
Email channel strategy
The EmailChannel strategy links actions with email treatments from the EmailTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.
The EmailChannel strategy
SMS channel strategy
The SMSChannel strategy links actions with SMS treatments from the SMSTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.
The SMSChannel strategy
Push channel strategy
The PushChannel strategy links actions with push treatments from the PushTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.
The PushChannel strategy
Other treatment strategy
The OtherTreatmentStrategy links actions with other treatments from the OtherTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.
The pyTreatment property is then used to access the OtherTreatments library DDR and retrieve the metadata for the treatment (PlacementType, ImageURL, ContentFormat, ClickThroughURL). Individual metadata values that are defined at the treatment level will override their action-level equivalents. Note that the join conditions for the DDR are slightly different for outbound and inbound and are selected via the Switch join based on direction Switch rule.
The OtherTreatment strategy
Assisted channel strategy
The AssistedTreatmentStrategy handles the treatments for both the Call Center and Retail channels from the AssistTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.
The pyTreatment property is then used to access the AssistTreatments library DDR and retrieve the metadata for the treatment (ImageURL, WhyRelevant, Benefits, EligibilityDescription). Individual metadata values that are defined at the treatment level will override their action-level equivalents.
The AssistedTreatment strategy
Paid channel strategy
This strategy checks if Paid is enabled and allows you to implement additional channel-specific logic.
The PaidChannel strategy
Outbound limits
The Constraints tab of Next-Best-Action Designer provides a default outbound contact limit of one email and SMS per week. This can be changed within Next-Best-Action Designer. The OutboundLimits strategy enforces these outbound limits for non-transactional actions. Transactional actions, such as compliance-related communications, bypass these outbound limits to ensure they go out to the customer.
There is an extension point strategy ContactPolicyExtension for any implementation-specific outbound limits.
The OutboundLimits strategy
ContactPolicyImpl strategy
The ContactPolicyImpl strategy is auto-generated and managed by the Context Dictionary generation process. This strategy must reference all context entities defined in the dictionary and add the contact limit rule to the primary context. Note that the example below is for a context of one Account to many Subscribers.
The ContactPolicyImpl strategy
Outbound channel preferences
Th OutboundChannelPreferences sub-strategy is a placeholder strategy to implement any customer preferences, for example, that the customer does not want to be contacted through SMS. It contains a single extension point sub-strategy OutboundPreferencesExtension.
The OutboundChannelPreferences strategy
Inbound channels
The InboundChannels sub-strategy links actions with the treatments for all of the inbound channels; a separate sub-strategy is called for each of Web, Mobile, Assisted (Call Center and Retail), and Other (custom channels).
This strategy only applies when the Primary direction is Inbound. The individual channels must also be active on each action.
The InboundChannels strategy
Web treatment strategy
The WebTreatmentStrategy links actions with the treatments from the WebTreatmentsJoin DDR. As a result, pyTreatment value is set on the action.
The pyTreatment property is then used to access the WebTreatments library DDR and retrieve the metadata for the treatment (PlacementType, ImageURL, ContentFormat, ClickThroughURL). Individual metadata values that are defined at the treatment level will override their action-level equivalents.
The WebTreatment strategy
Mobile treatment strategy
The MobileTreatmentStrategy links actions with the treatments from the MobileTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action.
The pyTreatment property is then used to access the MobileTreatments library DDR and retrieve the metadata for the treatment (PlacementType, ImageURL, ContentFormat, ClickThroughURL). Individual metadata values that are defined at the treatment level will override their action-level equivalents.
The MobileTreatment strategy
Assisted treatment strategy
This is a common strategy for both Inbound and Outbound and is described under the Outbound section.
Other treatments strategy
This is a common strategy for both Inbound and Outbound and is described under the Outbound section.
Treatment-level scoring strategy
The TreatmentLevelPropensity strategy is responsible for applying an adaptive model for each Treatment and calculating the propensity across eligible channels.
Actions can be designated as transactional in nature, i.e. they are always intended to be delivered and do not require any arbitration. Treatments for Transactional Actions are filtered out and bypass analytics processing.
Treatments for Non-transactional Actions are directed to the PredictTreatmentPropensity Prediction shape, and then to the TreatmentLevelPropensityExt extension point sub-strategy.
The TreatmentLevelPropensity strategy
AI models strategy
The AIModels strategy uses the outcome optimization approach which provides a different model configuration and outcome for each channel. This strategy filters out treatments based on channel to ensure that the correct model is applied. As with the action level strategy, 2% of treatments are given a random propensity to ensure that the models have the opportunity to discover new patterns.
The AIModels strategy
Finally, the Treatments are divided into Adaptive and non-Adaptive streams based on the ApplyAnalytics property, and the non-Adaptive stream sets both the AdjustedPropensityTreatment and pyPropensity properties based on the Action StartingPropensity, whereas for the Adaptive stream these values are calculated by the PredictTreatmentPropensity strategy.
Predict treatment propensity strategy
The PredictTreatmentPropensity Prediction strategy uses the outcome optimization approach which provides a different model configuration and outcome for each channel. This strategy filters treatments based on channel to ensure that the correct model is applied. As with the action level PredictActionPropensity strategy, Random Control Group, Outbound Model Maturity, and Propensity Smoothing techniques are applied to optimize statistical robustness.
The strategy is shown below split into two sections for easier viewing; the first portion separates the treatments into inbound or outbound, and then further splits them based on channel before executing the appropriate Prediction strategy for the channel. They are then merged to the AIModelsExt extension point sub-strategy for any additional processing (if required) before proceeding to control group processing.
The PredictTreatmentPropensity strategy
Each channel except for Paid has a separate Prediction strategy assigned which contains the actual reference to the adaptive model followed by some property settings, an example for the web channel is shown below (PredictWebPropensity).
PredictWebPropensity strategy
The second portion of this strategy is ostensibly the same as the right portion of its Action equivalent, i.e. the PredictActionPropensity Prediction Strategy, where the Random Control Group, Outbound Model Maturity, and Propensity Smoothing processes are applied.
PreditctTreatmentPropensity strategy
Control Group Processing
This is the section in the Next-Best-Action strategy framework where a universal control group can be configured.
Control group processing
The Non-Control result is the entry point to this section and at present does not set any properties.
The Is in Control Group (ControlGroupImpl) sub-strategy is where presence in a control group can be established – this could be using a Segment Filter or some other statistical method, but by default it simply returns false – i.e. there is no control group.
The Handle Control Group (InControlGroup) sub-strategy is where any control group processing should be defined, e.g. defining properties that can be persisted to Interaction History and / or setting conditions such that no actions are delivered. By default, the strategy returns an empty page list.
Arbitrate through NBA Post-Process extension
This is the last portion of the NBA Strategy Framework and includes arbitration and final channel processing, followed by an option to use an alternate strategy (the NBA Kill Switch) and the final extension point NBAPostProcessExtension sub-strategy.
The “NBA Kill Switch” is actually the “Next-Best-Action active” setting in the NBADesignerSettings DDR; if this is set to false, the FallbackNBAStrategy strategy is invoked instead of using the NBA framework. This fallback strategy is provided with no logic, but can be extended to include any default actions to be presented in case NBA is switched off.
Components: Arbitrate to NBA Post-Process Extension
Arbitration strategy
The arbitration strategy is responsible for setting up the attributes that will be used in the final priority calculation (P * C * V * L). These settings are managed within Next-Best-Action Designer and saved into decision data rules (DDRs).
A high-level view of the strategy is shown first, and then each section will be described in more detail.
The Arbitration strategy
The strategy first sets the FinalPropensity property to be based on the action or treatment propensity. Then the strategy sets the business value. By default, the action-level business value is used. Modify the business value extension point strategy to change this.
Business value extension point
After that, if the Business levers are enabled, the strategy determines business purpose weighting, first at the issue level and then the group level. These weightings are added together and then normalized. For example, a total weighting of 55 sets a final weighting of 1.55.
Business levers
The strategy then applies context weighting by looking at the Container and Event payloads and searching for a matching Key and Value pairs for each Issue and Group. If a match is found, the weighting is added to the weight for the specified issue and group. This weighting is also normalized, so a total weighting of 55 sets a final weighting of 1.55.
The next step is to calculate Q & A related context – if any. By default, there is none, but it can be added via the QnAContextWeightingExt extension point.
After the properties are calculated and normalized based on the settings configured in Next-Best-Action Designer, the Priority property is set using the following formula:
Then all actions and treatments are prioritized based on Priority in descending order.
Prioritization component
The Calculate Business Value Strategy
The CalculateBusinessValue strategy uses the business value property of the action. An extension strategy CalculateValueExtension is provided for more sophisticated value calculations.
The CalculateBusinessValue strategy
The Question & Answer (QnA) Context Weighting Strategy
The QnAContextWeighting strategy simply contains a call to the QnAContextWeightingExt extension point sub-strategy. This can be used to add any Q & A related context weighting. Any weighting calculated here should be added to the ContextWeight property.
QnAContextWeighting strategy
Channel processing
Now that priority has been assigned to the actions and treatments, they must be ranked by priority and filtered based on the specific channel. The channel processing strategy handles this for inbound and outbound channels.
The ChannelProcessing strategy
Inbound channel processing
The InboundChannelProcessing strategy handles all inbound channel processing; a separate sub-strategy is called for each of Web, Mobile, Agent Assisted (Call Center or Retail), and Other (everything else).
For treatments for the Web and Mobile channels, you can specify the placement type, for example Hero or Tile. You can also specify the number of placements per page, either as part of a real-time container call or as defined in a PagePlacement DDR. The Web and Mobile strategies pick the top treatment based on the requested placement types.
The InboundChannelProcessing strategy
The ProcessWebChannel strategy
The ProcessWebChannel strategy determines if the Channel treatment processing switch is on, and if so calls the WebTreatmentPlacements sub-strategy for web placement processing, otherwise this processing is skipped.
An extension point WebChannelExt sub-strategy is provided for any custom treatment placement processing.
WebChannelExt sub-strategy
The WebTreatmentPlacements strategy
The WebTreatmentPlacements strategy ranks treatments by priority based on the selected Propensity method in the Arbitration tab of Next-Best-Action Designer. The strategy then matches the placement types provided in the Container or in the PagePlacements DDR and the prioritized treatments by rank. For example, if a container requested a Hero, Tile, Tile, Tile, this strategy ensures that the top Hero treatment and a ranked set of Tile treatments are selected.
WebTreatmentPlacements strategy
The ProcessMobileChannel strategy
The ProcessMobileChannel strategy determines if the Channel treatment processing switch is on, and if so calls the MobileTreatmentPlacement sub-strategy for web placement processing, otherwise this processing is skipped.
An extension point MobileChannelExt sub-strategy is provided for any custom treatment placement processing.
MobileChannelExt sub-strategy
The MobileTreatmentPlacement strategy
The MobileTreatmentPlacement strategy ranks treatments by priority based on the selected Propensity method in the Arbitration tab of Next-Best-Action Designer. The strategy then matches the placement types provided in the Container or in the PagePlacements DDR and the prioritized treatments by rank. For example, if a container requested a Hero, Tile, Tile, Tile, this strategy ensures that the top Hero treatment and a ranked set of Tile treatments are selected.
MobileTreatmentPlacement strategy
The AssistedInboundChannel strategy
The AssistedInboundChannel strategy splits the actions into Call Center and Retail channels to allow for any additional channel specific processing, and then prioritizes by descending Priority, returning All actions.
An extension point strategy AssistedInboundChannelExt is provided after prioritization to allow for any additional assisted inbound processing.
AssistedInboundChannel strategy
OtherInboundChannel strategy
The OtherInboundChannel strategy simply contains a call to the OtherInboundChannelExt extension point strategy.
OtherInboundChannel strategy
Outbound channel processing
The OutboundChannelProcessing strategy handles all outbound channel processing. The Paid channel is unique in that we want to send all actions to be processed by Paid Media Manager, so those actions pass through. For the other outbound channels, a separate sub-strategy is called for each of Email, SMS, Push, Call Center, Retail and Other (anything not in this list but not Paid). Each of these sub-strategies is intended as an extension point for including any additional channel specific processing.
The first three contain no logic and are simply extension points that are then merged into the ProcessOutboundChannels strategy, which includes a call to the TopOfferOrBundleForOutbound sub-strategy.
The next three just contain a call to the TopOfferOrBundleForOutbound sub-strategy (i.e. they are identical to the ProcessOutboundChannels strategy), and can also be used as extension points.
The OutboundChannelProcessing strategy
ProcessOutboundChannels strategy
The ProcessOutboundChannels strategy contains a call to the TopOfferOrBundleForOutbound sub-strategy.
The ProcessOutboundCallCenterChannel, ProcessOutboundRetailChannel, and ProcessOutboundOtherChannel strategies are identical to this.
ProcessOutboundChannels strategy
TopOfferOrBundleForOutbound strategy
The TopOfferOrBundleForOutbound strategy separates out bundled and non-bundled actions and picks the top bundle or treatment based on priority. If a bundle is selected, the bundle members are also selected and pass through. Essentially this strategy produces the best bundle or treatment.
TopOfferOrBundleForOutbound strategy
The NBA Post Process Extension Strategy
The last functional component within the strategy framework is the NBAPostProcessExtension extension point strategy for any post-processing which must be performed.
