The leftmost section starts by defining the model control group properties and executing the Paid channel surrogate model if required.

A surrogate Paid Media channel may be defined via the PaidMediaLearningChannel setting in the Business Control Settings DDR, and if defined, the model for this channel will be used instead of the Paid channel model for actions where Paid is enabled. Typically, the reason for choosing a surrogate channel would be that the Paid channel is receiving very little feedback and so the model has insufficient evidence from which to learn.

The logic for this section is described below.

• A control group is assigned through the Define Control Group sub strategy.
• The Action Model Impl strategy executes the adaptive model for the current contact and context for each action and enabled channel.
• Actions are split into Paid and Not Paid streams based on whether the action has Paid enabled.
• For Paid actions, the channel is changed to the surrogate, the model for that channel is executed, and the results are joined back to the Paid action stream overriding the model results for the Paid media channel. It is important to note that the Exclude model results from Action Model Impl Paid is checked in the data join so that only the original Paid model learns from any response received, and the surrogate model does not learn from the Paid channel.
• Non-Paid actions bypass the surrogate model path.
• Paid and Non-Paid actions are merged.
• The Paid Learning Required switch rule bypasses the whole paid surrogate logic path if a surrogate channel has not been defined.
• The Model/Random Switch rule then chooses between the model results and a random propensity (between 0 and 1) based on the control group setting.

The next section of the strategy applies outbound model maturity, Thompson sampling, and propensity thresholds.

For a detailed description of the logic, refer to the annotations on the strategy.

Define 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. The percentage may be changed within Prediction Studio.

This is achieved by calculating a CustomerHash value between 0 and 100 based on the customer ID (pySubjectId) and the month name, then 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, so that the customer remains part of the same control group for that month.

Action Model Impl

This strategy is generated by Next-Best-Action Designer based on the context dictionary configuration. It may be overtaken and modified if required, but if so any future changes to the context dictionary may need to be applied to the strategy manually.

The Passthrough shape is an empty component connected to the input point of the primary context shape; it is needed so that the Select Context switch rule can test the account context to determine which context model is required, that is, whether a Subscriber or Device model is needed depending on the action context being processed. Without this switch, the logic will iterate over all contexts for all actions which will give incorrect results and execute unnecessary models.

The primary context (Subscribers) shape includes input conditions to ensure that only the current contact (OriginalContactID) is processed.

The Devices shape includes input conditions to ensure that only the current Device (OriginalSubjectID) is processed.

The same OmniAdaptiveModel is used for all action contexts and is applicable to all actions and channels, and the context for this model is issue, group, name, channel, and direction.

The model definition contains some parameterized predictors for Journey Stage data and Pages & Classes entries for each context entity. The shape in the Subscribers context passes the Account and Subscriber pages to the model, as in the following figure:

The shape in the Devices context passes Account, Subscriber and Device pages, as in the following figure:

Handle Model Maturity

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.

This strategy has two public components:

Check Maturity

Determine model maturity. Use this public component to set the IsModelMature property prior to using the Process Maturity public component.

Process Maturity

Is the public component used for implementing model maturity.

Actions that are deemed to be already mature (or are enabled for Paid Media) bypass this process through the Mature or Paid Channel Actions filter. For actions that are less mature (and not enabled for Paid Media), an analytical method is used to filter out a portion based on their maturity (the less mature, the higher the proportion).

Apply Propensity Thresholds

This strategy imports propensity thresholds from the Model Propensity Thresholds DDR and matches them to Actions by Direction, Channel, All Issues, Issue and All Groups, or Group and All Actions. More specific threshold definitions take precedence over less specific ones, that is, a threshold set at the group level will override one set at the issue level.

The DDR Direction may be Inbound, Outbound or blank for either.

The DDR Channel may be blank for all channels, but if any specific channels are defined, then ALL channels must be defined, since blank channels will be ignored.

Actions with FinalPropensity less than or equal to the threshold will be excluded from the output (hence FinalPropensity must be set prior to calling this strategy).

This strategy has three public components, one of which must be selected when calling the strategy (otherwise the number of actions will be tripled):

Apply Issue & Group Thresholds

This is the component that should be selected for all new implementations.

Apply Action Thresholds

Provided for backwards compatibility with version 8.6 and earlier. Gives identical results to Apply Issue & Group Thresholds.

Apply Treatment Thresholds

Provided for backwards compatibility with version 8.6 and earlier. Gives identical results to Apply Issue & Group Thresholds.

For a detailed description of the logic, refer to the annotations on the strategy.