NBA Strategy framework extension points
The Next-Best-Action strategy has a number of predefined extension points that you can use to add your own business logic to the framework. For example, you can use extension points to apply additional contact policies, or adjust model propensities. For a list of available extension points, see below.
Understanding the naming convention for extension points
Component names for extension points use the following notation:
- AllIssues
- Includes all issues from the Next-Best-Action Designer taxonomy.
- AllGroups
- Includes all groups within one or all issues from the Next-Best-Action Designer taxonomy.
- <Issue>
- The name of an issue in the Next-Best-Action Designer taxonomy.
- <Group>
- The name of a group in the Next-Best-Action Designer taxonomy.
- <Hierarchy_Level>
- Specific issues and groups from the Next-Best-Action Designer taxonomy. Not all of the
below combinations are available for all strategies.
- TopLevel - all groups within all issues
- <Issue> - all groups within the issue
- <Issue>_<Group> - a specific issue and group
- <Issue>_AllGroups - all groups within the issue
- AllIssues_AllGroups - all groups within all issues
- <Context>
- The name of a context entity from the Context Dictionary, for example Customer, Account, or Subscriber.
- <Channel>
- The name of a channel, for example Web, Email or SMS. Both built-in and custom channels are supported.
- <Direction>
- Inbound or outbound.
- <Triggering Strategy>
- Depending on the combination of issues and groups to be processed, and the method of
initiation, for example, real-time container, outbound schedule, or event trigger, the
Next-Best-Action Designer strategy can be invoked from the following strategies:
- H_NBA_<Issue>
- NBA_<Issue>
- NBA_<Issue>_<Group>
- NBA_TopLevel
- Trigger_H_NBA_<Issue>
- Trigger_NBA_<Issue>
- Trigger_NBA_<Issue>_<Group>
- Trigger_NBA_TopLevel
- ->
- Indicates the calling strategy hierarchy for the parent strategy. Each successive strategy is called from the previous one in the list.
Extension points in a multilevel implementation
In a multilevel context implementation, the Trigger strategy will include embedded sub-strategies that iterate over each context instance within the parent context, e.g. for a telecommunications implementation this may be Device within Subscriber within Account, whilst for a financial implementation it may be Customer within Account.
The next-best-action strategy framework is invoked for separately for each such context, so that Subscriber context actions will be processed separately from Account context actions, etc.
This needs to be borne in mind when using the extension strategies that are subordinate to the next-best-action strategy framework, since only actions from a single context will be processed during execution. If any logic is required that spans action context - that is, requires the actions from different contexts to be in the same SR, then use one of the two FinalLimitsAndBundlingPreExt and FinalLimitsAndBundlingPostExt strategies that are invoked after all action contexts have been merged.
Required strategy extensions
Required extension points must always be configured.
| Extension point strategy name | Parent strategies | Purpose | Business use case |
| AuthorizedContact | <Triggering Strategy> <Triggering Strategy> | In a multilevel context implementation, insert logic to only select primary context records that are authorized contacts, that is, eligible to receive actions related to any context level. When executed from the triggering strategy, the property IsPrimaryContact will be set to true for each of these. | Use this to designate contacts as being the preferred or authorized contacts
within a parent entity such as Household or Account, e.g. head of household, or
primary account holder. IsPrimaryContact may be used in Engagement Policies to select actions only for these contacts, and the Communicate To property on the action form may be used to redirect actions to these contacts. |
Optional strategy extensions
For extension points listed in this section, the strategy is empty, and you can configure it as needed to suit your requirements, or leave it blank.
| Extension point strategy name | Parent strategies | Purpose | Business use case |
| NBA_PostActionImportExtension | <Triggering Strategy> | Used to implement any logic required after actions have been imported but prior
to any further processing such as the engagement policies. For example, additional properties may be calculated here for use within the engagement policy conditions, or additional data may be imported and used to augment action data, which is especially useful if such data is common to actions in multiple issues or groups. The same logic is executed for actions of any context level, so if action context is significant, this needs to be accounted for within the logic. | This is useful if there is a need to augment action data with properties that
are common to actions across Issue and Group boundaries. For example it could be used to add data from a product catalog to actions where actions in different issues and groups share the same product data. This is easily achieved by creating a DDR containing the product data, and another DDR that joins actions (via Issue, Group and Name) to the product data DDR. |
| NBA_<Issue>_<Group>_Ext | Various | Apply any additional logic to all actions in the named <Issue> and <Group> after the Eligibility, Applicability and Suitability conditions have been evaluated. This logic is executed at the highest context level in the Context Dictionary, regardless of action context, and before the context specific engagement policies. | When migrating to Next-Best-Action Designer, any existing issue or
group-specific action eligibility strategies or proposition filters may be included
here to augment the default proposition filters. This allows existing artifacts to
be re-used and gradually phased out new engagement policies are built in
Next-Best-Action Designer. Typically an engagement policy created within Next-Best-Action Designer will not require any additional logic. |
| NBA_<Issue>_<Group>_<Context>_Ext | NBA_<Issue>_<Group> <Triggering Strategy> H_NBA_<Issue> | Apply any additional logic to all actions for the named <Context> in the named <Issue> and <Group> after the Eligibility, Applicability and Suitability conditions have been evaluated. This logic is executed only in the context of the named <Context>, but not the primary context. | When migrating to Next-Best-Action Designer, any existing issue or group-specific action eligibility strategies or proposition filters may be included here to augment the default proposition filters. This allows existing artifacts to be re-used and gradually phased out as new engagement policies are built in Next-Best-Action Designer. Typically an engagement policy created within Next-Best-Action Designer will not require any additional logic. |
| NBA_AllIssues_AllGroups_Ext | Various | Apply any additional logic to all actions in all issue and group combinations after the Eligibility, Applicability and Suitability conditions have been evaluated. The same logic is executed for actions of any context level based on the context of the parent strategy, so if action context is significant, this needs to be accounted for within the logic. | When migrating to Next-Best-Action Designer, any existing generic action
eligibility strategies (that apply to all issues and groups) may be included here to
augment the default proposition filters. This allows existing artifacts to be
re-used and gradually phased out new engagement policies are built in
Next-Best-Action Designer. Typically an engagement policy created within Next-Best-Action Designer will not require any additional logic. |
| NBA Pre-Process Extension Point | Various | Logic can be inserted at the start of the Next-Best-Action strategy framework
before any other logic is executed. This is after all engagement policies and any of
the above extensions have been executed, and actions from all issues, groups, and
contexts have been merged. This is a catch-all extension point to allow any global logic to be applied to all actions after the initial engagement policies have been evaluated. | This effectively achieves the same purpose as the
NBA_AllIssues_AllGroups_Ext extension, except that it is
executed only once after actions from all issues and groups have been merged, rather
than separately for each issue or group. Use this to augment action data - e.g. from one or more DDRs, or derive any calculated properties that may be required later in the Next-Best-Action Designer logic. However, note that if the data is not required as part of the scoring, treatment processing, arbitration or channel processing sections, then this may be better done later in the Next-Best-Action Framework after the number of actions has been reduced. |
| Create Eligible Channel Extension | <Triggering Strategy> | Used for additional channel processing or validation. Note that this will be in addition to the default channel validation - it does not replace it, i.e. it is intended only to process channels that would otherwise not be selected by the default logic. | The Create Eligible Channels strategy that calls this extension validates and assigns available default channels to actions. If additional channels need to be defined, it is recommended that these are added to the Other category to allow the default logic to also validate and assign these. However, if more granular control is needed for the additional channels than is provided by the default Other channel, then additional logic may included here. Use the logic in the Create Eligible Channels strategy as a template for building the extension logic. |
| ActionLevelPropensityExt | <Triggering Strategy> | Logic can be inserted after action scoring has occurred, for example, to include addition models or adjust the model propensity. Note that this extension is not executed for transactional actions. | This extension is largely redundant for model related changes since the concept
of modifiable Predictions was introduced and model related logic can be managed
within these predictions. However, this could be used to introduce A/B testing or Champion Challenger functionality at the action level if required. |
| OutboundPreferencesExtension | <Triggering Strategy> | Addition logic can be inserted after the treatment data has been retrieved, but before treatment scoring is performed. | This extension applies to all outbound channels except for Paid and is executed
after treatments for all outbound channels have been merged. It can be used to apply channel preferences or arbitration across channels, e.g. using an adaptive model or customer preferences to prioritize channels. |
| AIModelsExt | <Triggering Strategy> | Logic can be inserted after treatment scoring has occurred, but prior to outbound model maturity processing, for example, to include addition models or adjust the model propensity. | This extension is largely redundant for model-related changes since the concept
of modifiable predictions was introduced and model related logic can be managed
within these predictions. However, this could be used to introduce A/B testing or Champion Challenger functionality at the treatment level if required. |
| TreatmentLevelPropensityExt | <Triggering Strategy> | Logic can be inserted after treatment scoring and outbound model maturity processing has occurred, for example, to include addition models or adjust the model propensity. | The only difference between this and the above extension point is that it executed after outbound model maturity has been evaluated, and so some immature actions may have been eliminated. |
| ControlGroupImpl | <Triggering Strategy> | Logic can be inserted to determine whether the contact is part of a custom control group. If yes, the additional InControlGroup extension strategy is executed instead of all of the prior next-best-action processing, including action imports and validation. | Use this strategy to identify customers in universal control groups and to use a custom strategy InControlGroup (see below) to generate the output for such customers. |
| InControlGroup | <Triggering Strategy> | This strategy is provided as an alternative action selection mechanism if the ControlGroupImpl extension strategy identifies the current contact (customer) as being in a control group. | Used in conjunction with ControlGroupImpl above. Use this strategy to generate
the output required for customers identified in the ControlGroupImpl strategy, e.g.
in a universal control group, or requiring some other alternative processing. For example, for a control group this could be a dummy action that will be persisted to Interaction History in order to identify the customer as being in the control group, but that is not emitted to the channel. It could also include an alternative set of actions and treatments required by a specific group of customers. |
| CalculateValueExtension | <Triggering Strategy> | This strategy can be modified using the Action value feature from the Arbitration tab in Next-Best-Action Designer. It allows the Action Value property to be calculated for all actions, where V = Value in the P x C x V x L calculation. | Typically, the Value property assigned to the action would be used as V in the P x C x V x L arbitration calculation. Use this strategy to adjust or derive the Value property based on customer or other Strategy Result properties. |
| QnAContextWeightingExt | <Triggering Strategy> | Add any QnA-related logic in this extension strategy to update the .ContextWeight property. Changes should be additive to this property, that is, they should take the form of ContextWeight + myContextWeight. | This extension is intended to cater for any Question and Answer data obtained from inbound interaction dialogs where the responses may be used to adjust the context weighting. |
| ArbitrationPostExtension | <Triggering Strategy> | Add any logic required to change the Priority value calculated by the Arbitration strategy using the formula P x C x V x L. | NBA Designer uses the formula P x C x V x L to
calculate the Priority of each action where: |
| FallbackNBAStrategy | <Triggering Strategy> | This strategy is provided as an alternative action selection mechanism if the Next-Best-Action active switch in the Next-Best-Action Designer Settings DDR is set to false - in other words, if Next-Best-Action is turned off. | Use this to provide a default set of actions and treatments in the event that the regular next-best-action strategies need to be disabled temporarily. |
| NBAPostProcessExtension | <Triggering Strategy> | This is the final stage of the Next-Best-Action Strategy Framework, after all context level action processing has occurred and before actions from different contexts are merged. | While the channel extension strategies described above are useful for
implementing any channel specific custom logic, this extension point allows
additional logic to be included that spans all channels. However, note that this will only be applied to actions from a single context at a time - if actions from multiple contexts need to be considered, then use one of the Final Limits extension points described below. |
| FinalLimitsAndBundlingPreExt | <Triggering Strategy> | This is executed before actions for all contexts have been processed by the Next-Best-Action Designer framework, and before any outbound bundling or final action limits are imposed. | There is no specific use case for this extension point, but it is provided to allow for any additional logic to be inserted after all actions for all contexts have been processed and merged and before final limits and bundling processing is performed. |
| <Channel>ChannelExt | <Triggering Strategy> | For inbound Web and Mobile channels only. These strategies allow for additional logic to be applied after all processing of default channels has occurred. | It is understood that the default logic for these channels may not fully meet
local requirements, and so these strategies are provided to augment the default
functionality. The Final Action Limits DDR described in Setting Limits on the number of Actions will obviate any need to directly set output limits in these strategies, but these extension points can be used for applying custom logic or setting additional channel specific properties for output. |
| <Channel>InboundChannelExt | <Triggering Strategy> | For inbound Assisted and Other channels only. These strategies allow for additional logic to be applied after all default channel processing has occurred. | The Final Action Limits DDR described in Setting Limits on the number of Actions will obviate any need to directly set output limits for these channels, but these extension points can be used for applying custom logic or setting additional channel specific properties for output. |
| OutboundChannelProcessing ExtensionControl | <Triggering Strategy> | A configurable strategy to allow the Process<Direction><Channel>Channel strategies to be executed for a single or multi-level context dictionary, or not at all (the detault) if no custom outbound channel processing is required. | See Process<Direction><Channel>Channel for more information. |
| OutboundChannelProcessing Extension | <Triggering Strategy> | A configurable strategy to allow the Process<Direction><Channel>Channel
strategies to be executed only for a set of nominated channels. Configuring only for the channels required will provide optimal performance. | See Process<Direction><Channel>Channel for more information. |
| Process<Direction><Channel>Channel | <Triggering Strategy> | For outbound channels only.These strategies allow for any outbound channel specific
logic to be applied after Final Action Limits have been processed. This logic has been moved from within the NBA Strategy Framework and that the TopOfferOrBundleForOutbound strategy no longer exists since it has been replaced by the Apply Final Action Limits and Contact Policy Limits strategies - now executed from within Final Action Limits And Bundling. | It is understood that the generic default logic for all outbound channels
provided in the Apply Final Action Limits and Contact
Policy Limits strategies may not fully meet local requirements, and so
these strategies are provided to augment the default functionality. The Final Action Limits DDR (described elswhere) will obviate any need to directly set output limits in these strategies, but these extension points can be used for applying custom logic or setting additional channel specific properties for output. |
| ContactPolicyExtension Control | <Triggering Strategy> | ||
| ContactPolicyExtension | <Triggering Strategy> | A configurable strategy to allow the ContactPolicyExtension strategy to be executed for a single or multi-level context dictionary, or not at all (the detault) if no custom contact policy processing is required. | See ContactPolicyExtension for more information. |
| FinalLimitsAndBundlingPostExt | <Triggering Strategy> | This is executed before actions for all contexts have been processed by the Next-Best-Action Designer framework, and before any outbound bundling or final action limits are imposed. It is the final stage of the Next-Best-Action Designer framework strategies. | There is no specific use case for this extension point, but it is provided to allow for any additional logic to be inserted after all Next-Best-Action Designer logic has been applied for all actions for all contextsThe Final Action Limits DDR described in Setting Limits on the number of Actions will obviate |
Modifiable strategy extensions
Extension points listed in this section are fully functional out of the box, but you can still modify the logic if it is critically important to your business needs.
| Extension point strategy name | Parent strategies | Purpose | Business use case |
| JourneyWeightAndPredictorsExt | <Triggering Strategy> | Use this strategy to include any custom logic for setting journey properties or calculating journey weights. | Only use this if the default weight calculations do not suit your needs, or if you want to prepare additional journey related predictors for the models. Bear in mind that any additional model predictors will also need to be included as parameters for the models and so will require the models to be updated, and the generated strategies that call them. |
| Handle Model Maturity | <Triggering Strategy> <Triggering Strategy> | The values in the Model Maturity Threshold and
Population Percentage Set Property shapes may be changed to
suit local requirements. The default values are 200 and 2% respectively. Model Maturity Threshold is the number of positive responses above which the model is deemed to be mature. Population Percentage is the initial percentage of the population that will receive actions for which the models are immature. This will increase towards 100% as the number of positive responses approaches the Model Maturity Threshold. | Only modify this strategy if the default values are not suitable. |
| <Channel>ChannelStrategy | <Triggering Strategy> <Triggering Strategy> | These strategies may need to be updated if additional treatment metadata needs to be added to the treatment definitions, for example if the <Channel>Treatments Decision Data Rule has been extended. | These are default strategies that assign treatments to actions separately for
each channel. They are not extensions as such, but are able to be modified to suit
local requirements. If additional properties need to be added to treatment definitions, then these strategies may be updated to accomplish this. |
Optional DDR extension points
For extension points listed in this section, the Decision Data rule is empty, and you can configure it as needed to suit your requirements, or leave it blank.
For more information about these extension points, see Additional NBA Strategy framework components.
| Extension point Decision Data rules | Parent strategies | Purpose | Business use case |
| ArbitrationInfluencers | <Triggering Strategy> | Used to define Arbitration Influencer Contact Policies that use the insights gained from the outcome of presenting an action to influence the arbitration of the same action - or one or more related actions - at some future interaction. | This DDR only needs to be utilized if there's a requirement to upweight some
actions in future interactions based on a prior response to an action. For example, during an interaction with a call center agent, if a customer expresses an interest in an offer, but needs to drop off the call due to other commitments, the outcome could be recorded as Maybe-Later. On the next interaction with the same customer it may be prudent to boost the chances of that same action - or some related actions – being selected as the next best action, on the assumption that the customer may still be interested and have a higher likelihood to accept the follow-up action based on their initial Maybe-Later response. |
| OutputBundlingSettings | <Triggering Strategy> | Used to set the bundling output options (BundleOutputType, SinglePrimary and pyDeliverOffline) by Direction and Channel, which are mainly used for outbound processing. These settings are applied after actions for all contexts have been processed by the Next-Best-Action Designer framework and prior to evaluating the final action limits. | This DDR only needs to be utilized if there is a requirement to change the default bundling and output settings. Otherwise it may be left empty. |
| FinalActionLimits | <Triggering Strategy> | Used to set limits on the number of actions that can be emitted for each contact or for the interaction as a whole. Limits can be set at the Direction, Channel and Action Context levels, and the limits for action contexts can be combined. | This DDR only needs to be utilized if there is a requirement to set limits on the number of actions that may be emitted per Direction, Channel, Context and Contact other than the defaults. Otherwise it may be left empty. |
Modifiable DDR extension points
Extension points listed in this section are fully functional out of the box, but you can still modify the logic if it is critically important to your business needs.| Extension point Decision Data rules | Parent strategies | Purpose | Business use case |
| <Channel>Treatments | <Channel>ChannelStrategy | Additional treatment properties may be added to these Decision Data rules. | See the use case for <Channel>ChannelStrategy in Modifiable strategy extensions. |
Previous topic Adjusting journey weight Next topic Testing the Next-Best-Action strategy framework