David Raab Article Archive

Is campaign management a commodity?

Not so long ago, campaign management vendors competed on core capabilities: which system handled the most complicated promotions, included the most data, ran fastest, or was easiest to use. But over the past year or two, the terms of competition have shifted. Now vendors tout the scope of their offerings, citing integrated analytical reporting, email production, and statistical modeling. Basic campaign management itself–the ability to select names, keep a promotion history, and match responses to promotions–is almost an afterthought.

In some ways, this is a natural result of past industry trends. Over the past decade, systems that use standard or “open” relational databases like Oracle or SQL Server have steadily displaced products that use “proprietary” databases created by the campaign management vendors themselves. The main argument in favor of the open systems was that the data could be read by any number of third-party reporting and analysis tools. This eliminated a dangerous dependence on the campaign management vendor. But precisely because the “open” systems all use the same database engines and query language (SQL), their performance depends more on the underlying database engine, database design and hardware than on the campaign managers themselves. Similarly, third-party query, reporting and analysis tools are at least as good–and often better–than anything a campaign management vendor can build for itself. So, having given up control over most of the things that previously differentiated them, campaign management vendors now need new ways to compete.

Integrated suites meet this need nicely. They simplify implementation–one of buyers’ key concerns–while helping shift attention away from specific functional details. There is some irony to this development, since the integrated suites are in some ways as “closed” as the proprietary systems they initially displaced. Of course, most vendors don’t see it that way.

But back to the original question: are the campaign management functions in today’s leading systems so similar that buyers need not examine them in depth?

I think not.

Take query complexity. This is where the constraints of SQL bind most tightly: nearly any modern system can support a simple SQL query, and very few systems can do much else. The simple functions boil down to examining a single field to see whether its value is equal, greater than or less than a specified value or another field in the same record. Most systems can extend the comparison to include simple math operations such as addition and subtraction, and can also combine separate statements with “and” or “or” conditions (although it’s easy to make mistakes in setting up “or” logic.) But it’s hard to generate SQL to handle other situations, such as finding sets that do not contain a particular value (practical example: people who haven’t purchased a given product) or summarizing many-to-many relationships (example: multiple purchases linked to multiple returns). Most of today’s SQL-based campaign managers don’t even try to support such queries, relying instead on precalculation, hand-written SQL, or multiple steps in a segmentation flow. The most important exception, Decision Software Inc.’s TopDog (www.dsitopdog.com), actually extracts the data from the relational database, manipulates it without SQL, and then reinserts it.

Embedding precalculated values in a record is one way to overcome some SQL limitations. Today’s systems also vary considerably in this area. The most powerful allow users to design, save and reuse complicated formulas that incorporate multiple variables and can even look up values in related tables (for example, the median income of the customer’s Zip code). Systems also differ in whether the values can be recalculated automatically as a query is executed, and how much work it takes to store them permanently on the database.

Promotion complexity is also tightly bound to the nature of SQL. Most of today’s systems allow users to define hierarchical nested selections: that is, they apply a series of queries that use the records selected (or rejected) by one query as input to the next, in order to split the database into ever-finer segments. This is another way to create complex selections that would be difficult or impossible with a single SQL statement. The differences among existing systems arise in two areas. The first is that not all products actually allow this sort of nesting–some limit the number of levels of queries that are allowed. More subtly, systems also differ in whether they literally use the output of one query as input to the next, or instead generate independent queries that all run against the main database itself. So long as the independent queries reexecute the logic of all the preceding queries, either method will yield the same result. But the independent query approach requires a great deal more processing where large databases or many segments are involved. This can raise a scalability issue. Some products offer a choice of whether the queries are independent or not, although even within this group there are differences in how easy it is to set up the processes.

A related distinction is how systems handle segments that are separated in time–for example, where one message is sent thirty days after another. Here, the different queries pretty much have to run independently, since the latter message may depend on customer actions after the initial selection. The difference among systems lies in whether they create the underlying queries automatically, based on an interface that lets the user simply specify a time interval. Many do, but others require the user to build the time relationships into the queries themselves. This is difficult and error-prone, and makes it impossible to show the relationships on system reports.

Query and promotion complexity are areas where marketers’ needs vary widely–which is why leading systems have found it possible to treat them differently. Similarly, there are still large differences in the products’ ability to limit the number of promotions sent to an individual, in support for complex response analysis, and in administrative functions such as budgeting, project management and approvals.

On the other hand, some requirements are pretty much universal and these have been incorporated in every leading product. A good example are the Nth or random selections needed for standard testing procedures. These are available in all major systems even though random selects are quite difficult to create in standard SQL. Today’s systems also let the user design the underlying customer database rather than forcing data into a fixed schema, although many do have a standard schema for internal data such as campaign information. Most products also include job schedulers that can execute campaigns automatically over a period of time–another key requirement for successfully executing an advanced database marketing program.

In short, there are still substantial differences in the core campaign management features of today’s leading products–differences that can cause major problems if they are not compared to user requirements before a system is purchased. So while integrated suites offer real and intriguing advantages, it’s not yet safe to ignore the details of their embedded campaign managers.

* * *

David M. Raab is a Principal at Raab Associates Inc., a consultancy specializing in marketing technology and analytics. He can be reached at draab@raabassociates.com.