This column continues my series by discussing the requirements of a high-end campaign manager apart from functionality.

To be suitable for a given task, software must, of course, perform the required functions. However, functionality is a slippery thing; many products can perform a given function but do it poorly, either because of technical constraints or an inconvenient user interface. Because high-end campaign management systems are, by definition, required to handle the biggest, most complicated campaigns, technical and interface efficiency are core requirements.

Many early campaign management systems used proprietary database engines, often based on highly efficient inverted data structures. Most of today's systems use standard relational databases with fairly conventional, somewhat denormalized data models.

It would seem, then, that all must be roughly equal in their efficiency, but systems vary significantly in the approaches they take to generating the many separate segments needed for a large campaign. The simplest, but least efficient, approach is to generate a separate SQL query against the main database for each segment. This can involve hundreds of complicated queries, each against millions of records. It also requires a subsequent step to remove records that were selected in multiple segments. Unfortunately, some products that are otherwise well suited for high-end campaign management use this approach ­ with predictably disastrous results. The systems' limits can be overcome to some degree through specialized database design and preliminary coding of records outside the campaign manager itself.

Most high-end campaign managers use a different approach. Essentially, they mirror the nested hierarchy used to design complex segmentations by generating queries that select each segment from its immediate parent rather than the original universe. This actually involves more queries than the other approach because each level in the nested hierarchy will require separate queries. It also means the system must create worktables to hold the output of the intermediate selections. However, the queries themselves are simpler and run against smaller numbers of records. This approach also lends itself more naturally to random and ranked selections and eliminates most of the problems with duplicate selections of the same record. It is less sensitive than the other method to the structure of the main database because all selects after the initial query run against worktables.

Unfortunately, even nested approaches can encounter problems. These relate largely to complex selections involving groups (bought any three of these five products), aggregates (10 percent more ATM transactions than the average customer), not logic (has no checking account) and other constructs that are difficult in standard SQL. An alternate approach is to extract the universe, place the records in a flat file and then process each record outside of SQL. This requires a system that can convert the segmentation tree into appropriate processing scripts in a language such as C or Java. Creating such a system is a formidable task; however, the result is very flexible and efficient because the programmer is not limited to SQL functions.

This approach basically processes one record at a time, determining its final segment and then moving on to the next. This avoids the inefficiencies of intermediate worktables and inherently prevents placing the same customer in multiple segments. It does add some difficulties to tasks that require an overview of the entire record set, such as random selections to reach a fixed quantity, but developers have found solutions.

Sequential processing somewhat resembles approaches designed to process individual records in real time, as in classic online transaction processing or today's interaction managers. Indeed, the interaction management systems are sometimes used as campaign management tools. However, these systems are optimized for real-time processing, often using special data structures for quick access to customer profiles. This makes them less than ideal for the batch processing required in high-end outbound campaigns. As with other suboptimal designs, this approach still may yield acceptable performance when volumes are low or campaigns relatively simple.

High-end campaign management systems are generally used by a small number of power users who can be counted on to adapt to nearly any interface. This makes it tempting to focus on functional capabilities and treat the interface as an insignificant detail. However, as with technology, the user interface of a high-end campaign manager must be extremely efficient to handle the volume and complexity of high-end campaigns. This imposes specific requirements on the interface design.

The key challenge is dealing effectively with hundreds of segments. This requires being able to see as many cells as possible on the screen while also showing the nested relationships among the segments that form the cells. Most high-end systems achieve this by showing each cell on a single row, often with separate rows for parent segments. The interface may be purely tabular, like a spreadsheet, or use a graphical format similar to the expandable trees that access file folders in Microsoft Windows. Users can generally drill down into a single cell to see details such as key codes, selection rules, costs and quantities. The systems also provide a variety of subsidiary functions to make definition of these details more efficient, such as allowing users to copy settings from one cell or segment to another, having child segments automatically inherit settings from their parent and letting users save and reuse settings across different campaigns.

Many systems let users display the campaign structure in several alternate formats. In addition to the tabular and tree views, these often include a flow chart used primarily to set up the original nested segments. Such flow charts are probably the most common interface among (non-high-end) campaign managers. They are easy to use, make the campaign structure easy to understand and can include all steps in the campaign process ­ such as model scoring, wait periods and output generation ­ as well as segmentation itself. However, flow charts become unwieldy when segmentations are very large or complex; therefore, high-end campaign managers require an alternative.

The campaign display format is the major special requirement that high-end campaign managers impose on the user interface. The interface must also meet general goals for efficiency and ease of use, but these can be achieved with roughly the same solutions as used in other systems. One area that does require close examination is the query generation interface because high-end campaign managers must allow very complex queries. The key issue with queries is functionality rather than the interface: there are a number of acceptable ways to design a system that can generate complex queries, ranging from flow charts to fill-in-the-blank templates to cell ranges on cross-tab tables. As noted earlier, the power users who spend most of their business days working with these systems will learn to do what they need in nearly any interface.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access