The initial articles in this series defined seven major categories of marketing systems. The next group of articles will each describe one category in detail.

Conventional campaign management is the oldest of these categories, so it’s a good place to start. These systems trace their roots to the 1970’s, when banks built Customer Information File (CIF) systems to identify all accounts owned by the same customer. By the mid-1980’s these had evolved into Marketing Customer Information File (MCIF) systems that let marketers select names based on a complete view of each customer relationship. MCIFs were initially used to identify the best customers for specific products, thereby maximizing the efficiency of each marketing campaign. This closely mirrored traditional catalog and magazine direct marketing, which often split an audience into hundreds of cells and analyzed the performance of each one. But MCIF systems also allowed a more customer-oriented approach, where marketers defined a matrix of offers and chose the best one for each customer segment. Although relatively few bank marketers actually implemented matrix marketing, it was widely recognized as the best practice. In a more sophisticated form, it still is.

Both the product and matrix approaches relied on the campaign manager’s ability to hierarchically assign records into segments. That is, the system would first find all records that qualified for an initial segment, then check which of the remaining records qualified for the second segment, then check which of the still-unassigned records qualified for the third segment, and so on. In product-oriented campaigns, the segments let marketers measure the results of different customer groups to help find the best prospects. In the matrix approach, the segments controlled which customers got each offer.

In fact, the ability to execute hierarchical, multi-segment selections is precisely what distinguishes conventional campaign managers from other marketing systems. The most efficient campaign managers are engineered to do these selects in a single pass through the file–determining where each record falls in the hierarchy and then moving on the next. Unfortunately, single pass processing is sequential, while relational databases and SQL work with sets. As a result, most SQL-based campaign managers execute a separate query for each segment, at a considerable cost in processing time. The cleverer products gain back some efficiency by using special indexes or querying an interim result set rather than the original universe. Campaign managers vary greatly in how they handle this problem, so buyers who expect campaigns with dozens or hundreds of segments should examine the mechanics of each product closely before making a purchase.

A first-rate campaign manager needs several functions that can be found in other products as well. High on the list is tracking promotion history, typically by adding a new promotion history record each time a customer is selected. This allows reports to compare the people who received a promotion with those who responded. At a minimum, the promotion history record holds a customer ID and promotion ID. More powerful systems also let users include a snapshot of other data elements, to use in later analysis.

Other important functions include complex queries–things like ranking, ad hoc calculations, and comparisons across multiple records–and random sampling to set up tests and control groups. These are also difficult for standard SQL, although most systems handle them fairly effectively. Many products sacrifice the advanced query functions for ease of use–a compromise most users seem to find acceptable.

Finally, nearly all of today’s major products can automatically execute campaigns on a regular schedule. This is a relatively new function, added when systems changed from a monthly or quarterly updates to daily or weekly. The greater frequency allows timely reactions to events such as a major purchase. But despite the goal of near-real-time response, most systems run automated campaigns using the same batch processes as their original, manual campaigns. That is, the campaign “trigger” is a query that runs periodically against the entire file. Since such queries can consume significant resources, they impose a practical limit on how often the trigger campaigns can be run. A few systems avoid this problem by placing triggers on the database itself, so events are identified as they occur. But adding a trigger to a database field takes a fair amount of technical skill, which makes it unacceptable to many marketers.

Even if marketers loved setting up database triggers, the fact would remain that today’s campaign management products have been optimized for batch processing. Handling real-time interactions would require a major reengineering that few vendors can afford. The issue is now becoming critical as users demand support for email campaigns. While generating a list of outbound emails is pretty much the same as generating a list of mailing labels, the real user requirement is to receive the email replies, post them to the marketing database, and react–more or less immediately. So far, the leading campaign management vendors have slipped by with loose integration with external email and Web site software. But they will probably need a more sophisticated approach to remain central to their clients’ marketing efforts.

*                       *                        *  

Copyright 2000 Raab Associates, Inc.. Contact: info@raabassociates.com

Back to Search