Optimization of Audience initiated whiteboards with segmentation controlled path selection

Overview

When a time-based (scheduled or recurring) whiteboard requires an initial audience to run, and this initial audience is very large, subsequent steps require the audience to run down different paths.

This can cause the whiteboard processing to be slower than expected and, in the worst case, block subsequent executions of the whiteboard when a new scheduled execution collides with the previous slowly running instance.

Example

A whiteboard defines an initial audience from a group containing 10,000,000 active members and no pre-filtering. This audience then flows into a segmentation step that filters out all but 10,000 members. These resulting members are then compared against 5 different criteria and run down 5 different paths related to 5 different messages.

What happens inside the whiteboard

• The whiteboard reads the entire active group membership list of 10,000,000 members and copies that result as a working buffer.

• This buffer is then passed to the path split step, where each of the 10,000,000 members will be compared against the segmentation and the path criteria to identify what path each member needs to be sent down:

  • If a member matches a path condition, they are flagged in the buffer to run down that specific path, and the path's logic will be applied.

  • If a member matches no paths, they are individually updated in the buffer to note that they have exited the whiteboard with no further processing required.

• The whiteboard has processed 10,000,000 records in this run.

Why this is a problem

In the example above, there are 10,000,000 members, but only 10,000 members match a processing path. The whiteboard, therefore, spends the majority of its processing time updating each of the 9,990,000 other members to say they have each individually exited the whiteboard with no further processing required. In short, in this example, for every 1 contact that matched a criterion, the whiteboard had to check and reject 1000 others individually.

This issue is compounded when multiple other whiteboards run in parallel based on large audiences, as each whiteboard has its own working buffer and data to filter.

Some other effects

• Overall, whiteboard processing can be slow.

• Expected sends or updates down each branch may not be executed or sent in the expected timeframe.

• A recurring whiteboard may not be able to run at the scheduled execution time if the previous whiteboard run is still executing, potentially blocking time-sensitive processing.

How this can be mitigated

The Audience step in the whiteboard obligatorily requires a group, but only optionally requires segmentation.

When you combine the audience step with a group and segmentation, the whiteboard does not read the entire group but relies on the segmentation to return only relevant contacts, which then enter the whiteboard.

From the example above, if you create a segmentation that pre-identifies the contacts from a given group that you will want to process on execution, this changes the execution to:

• The whiteboard passes the group and the segmentation to the Engage segmentation engine, which returns only the 10,000 matching members that result in a working buffer.

• This buffer is then passed to the path split step, where each of the 10,000 members will be compared against the segmentation and the path criteria to identify what path each member needs to be sent down

  • If a member matches a path condition, they are flagged in the buffer to run down that specific path, and the path's logic will be applied

  • There are no non-matching members to exclude

• The whiteboard has processed 10,000 members in this run, reducing the processing requirements threefold!

In addition, if all Whiteboards based on large groups are pre-filtered, this will globally and positively affect whiteboard runtimes as there will be less buffered data overall to process, which will also contribute to a general performance improvement across all whiteboards.