How to use Horizons in MOMA (Marketing Automation/Marketing Optimization integration)

[#1]

This document describes the concept of horizons for an MO-MA integrated environment via a simple example.

Assumptions:

The reader is familiar with creating and using MOMA data:

• Campaigns and campaign groups
• Optimization groups
• Preferred scenarios
• Scheduled executions

The concept of horizons came about when customers wanted a way to efficiently use computer resources when running a MOMA optimization.  Some customers have lots of campaigns in a campaign group which results in the processing for a huge amount of data.  The problem is that not all of the campaigns may be scheduled for execution during an optimization.  So we are processing a lot of extra information that will not be used for anything.

Using a horizon in your MOMA data ensures that optimization runs only for campaigns in the current horizon.  If a horizon period is defined, then only those campaigns that are scheduled to execute during the horizon will be loaded into the MO tables.  Therefore, MOMA will only be processing relevant information for each optimization.

When an optimization run starts, the horizon is used to determine which campaigns will be included and which campaigns will not be included.  This will result in campaigns being added to the MO input tables as well as campaigns being removed from the MO input tables. 

Setting an optimization schedule

If you plan to use horizons, the campaign group must have a schedule in place.  In MA, when the campaign group is created, it must have a schedule set at the group level, which is the schedule for the optimization. This means that when the scheduled time for the group arrives, the following happens:

• MA recreates MO tables based on the latest information (including the current horizon)
• MO refreshes the optimization group using the new tables provided by MA
• Preferred scenario is optimized and promoted
• MA gets the promoted solution and uses the results for the optimized counts

When setting the optimization schedule for the group, schedules can also be set for the member campaigns.  The schedule for the campaign indicates the time (and recurrence) for the campaign to be exported.  When the scheduled time for the campaign arrives, the following happens:

• Campaign is published and exported
• An export file is created using the optimized counts from the MO promoted solution

There are a number of rules to keep in mind when scheduling campaigns and campaign groups:

• A campaign can only be scheduled to run after the first optimization has occurred
• A campaign can only be scheduled to run once after each optimization

Setting the horizon

Although the horizon is set in MO when creating the optimization group, determining the horizon number of days requires some collaboration between the MA user who is creating the campaign group and the MO user who is creating the optimization group.  Typically, this is the same person, but this may not always be the case. 

Once a schedule has been determined for a campaign group and member campaigns and all other options have been assigned, the campaign group is saved and made available for MO.  When the optimization group is created in MO, there will be an option to enable and assign the horizon:

Selecting the number of days in the horizon can be tricky.  A few things to keep in mind are:

• Using a horizon number of days that is too small can result in no campaigns in the horizon. In this case, then the optimization group is created or refreshed, there will be errors (conveyed by error messages in the UI and/or the log) that there are no campaigns in the data

• Using a horizon number of days that is too big means that the current data may not need to utilize the horizon feature. If the horizon number of days is so large that all campaigns are always included in all optimizations, then that is an indication that horizons do not need to be enabled at all.  If this is the case, horizons can be disabled.  For disabled horizons, all campaigns are included in all optimizations.

Once the optimization group has been created with the horizon number of days, the number of days is sent back to MA, but is not surfaced anywhere.  MA does know that the campaign group is using horizons and the number of days, but this information is not available via the MA UI.  The user will have to check the value via the MO UI.

Example of MOMA process using horizons

We have a campaign group with 3 campaigns which have an optimization group that is set up as follows:

Horizon number of days = 14 days

Group scheduled every 4 days, start 4/1

Campaign1 scheduled 5 days, start 4/1

Campaign2 scheduled weekly, start 4/7

Campaign3 scheduled every month on the 15^th, start 4/15

The schedule for this would be as follows, where the shaded days represent some action (optimization or execution) on that day:

The daily activities can be broken down into more detail.  Dates in red indicate dates where a campaign has been added to the horizon or where a campaign has fallen out of the horizon.

Ramifications of horizons

Because campaigns will be falling in and out of the horizons, there may be some unexpected behaviors and results with campaign group and scenario set up.  As of 5.4, dealing with these issues are left up to the user.  This means that the user should be familiar with the data being used, as well as how the horizon affects the data.

Some issues that the user may come across include the following:

• Infeasibility of the preferred scenario due to constraints
  When using horizons, it is possible to create constraints that cannot be fulfilled for a particular horizon. For example, say we have Camp1, which has 50,000 eligible offers and Camp2, which has 100,000 eligible offers.

These are put into a campaign group, where a group level constraint is created such that the minimum number of offers for the group is 100,000.

Then say that, while using horizons, we have an instance where Camp1 is the only campaign in the optimization group.  This means that there are only 50,000 eligible offers.  However, we still have the constraint on the group where the minimum number of offers is 100,000.

Since we cannot fulfill this constraint, the scenario will come back as infeasible.
Best practice in this case is to make sure that the user does not create constraints like this which may cause infeasibility.  Group constraints may not be the ideal constraints to use when horizons are in play.  The same is true for channel constraints, which are, in essence, a type of group constraint.

• Infeasibility due to filters in constraints or contact policies
  In MO, the user can create constraints and contact policies that use filters. For example, a scenario may have the following contact policy:

min contact >= 1, where communication_cd IN [EmailMsg]
Using our previous example, let’s say that the communication EmailMsg is a communication that exists only in Camp2.

While using horizons, we have an instance where Camp1 is the only campaign in the optimization group.  So Camp2 is not in the optimization group.  We will still see the values for items in Camp2 as selections.  For example, EmailMsg will still be a valid option.  But since Camp2 is not in the optimization group, there are no eligible offers where communication_cd is EmailMsg.

For this example, this means that the preferred scenario will come back as infeasible.  The contact policy we had will never be met since we do not have any offers where communication_cd is EmailMsg.

This is also true of filters that are custom details.

• Unexpected behavior and results due to filters in constraints or contact policies
  In a similar vein to the previous issue, you may get unexpected behaviors and results with filters that are falling in and out of the horizon.

Using the same example, let’s say we have a constraint with a filter:
max contacts <= 2500, where communication_cd IN [EmailMsg]
As before, the communication EmailMsg exists only in Camp2.

While using horizons, we have an instance where Camp1 is the only campaign in the optimization group. So Camp2 is not in the optimization group.  We will still see the values for items in Camp2 as selections.  For example, EmailMsg will still be a valid option.  But since Camp2 is not in the optimization group, there are no eligible offers where communication_cd is EmailMsg.

For this example, the preferred scenario will still be optimized successfully.  But the user should be aware that the value of this constraint will be 0.  This will still satisfy the constraint, but it may not be what the user was expecting.

This is also true of filters that are custom details.