David Raab Article Archive

Several months back, this column discussed response attribution: the process of determining the impact of marketing activities on customer behavior. The major conclusion was that the scope of such measurement is expanding from isolated promotions to collections of interactions over time. What matters now is not specific marketing campaigns, but customer treatment policies that span multiple promotions, channels, and types of activities.

That was an interesting point, I hope, but a bit abstract. So let’s revisit the topic from a more practical perspective. Assuming your marketers really want to think in terms of policies rather than campaigns, what must your systems do differently?

This begs a preliminary question: what do your systems do now? In terms of response attribution, the answer generally boils down to this: the systems capture the set of promotions sent to each customer, and match these to responses. The mechanism for linking responses to promotions is an identifier that is somehow connected to both. In a traditional direct response operation, the identifier would be a source code or key code that is physically printed on promotion materials and captured as part of the response. Look at the business reply card in any direct mail package you receive today and you’ll almost certainly see such a code. Respond by placing a telephone order rather than mailing the card back, and chances are the agent will ask you to find the code and read it.

Source codes originated in the days before marketing databases existed–when it was impossible (before computers) or just prohibitively expensive (up until about ten years ago) to keep a list of the promotions sent to each individual. The source code therefore had to capture all the information needed for effective response analysis. This boiled down to three things: the campaign that generated the contact, the specific contents of the contact, and the audience that received the contact. The campaign can be thought of as a marketing tactic: send a mailing to new movers, or a catalog before the Christmas holidays, or a renewal offer to magazine subscribers. In still simpler terms, the campaign can be considered the reason the customer was contacted–for example, because we’ve found that new movers are highly responsive. Content is the actual promotion, itself a combination of product(s) offered, pricing, and creative treatment. One campaign can include multiple contents, such as different versions of a catalog or a test of different creative treatments. The third element, audience, indicates not the actual list of individuals but the characteristics that were used to identify these individuals. More important for marketing purposes, these characteristics can also be used to identify similar individuals in the future. While an audience can be as broad as “all past customers” or “every name we’ve ever captured”, competent marketers typically break the audience into segments that might be expected to act differently, such as buyers with different levels of past purchase activity, names from different lists, or people with different age, income, gender or other demographic characteristics.

With each combination of these elements assigned to a different source code, all the marketer needed to analyze response was aggregate information at the code level: that is, the number of names selected and the number or value of responses. For example, a catalog marketer might find that it was profitable to send a second Christmas catalog to customers whose latest purchase within the past two years, but no longer. With campaign, content and audience as attributes of the source code, there was no need to look at information about specific individuals.

Most marketers still assign source codes in this fashion. But with a modern marketing database, this approach is not necessary. The database makes a record of each promotion at the time it is sent to the customer. This means the marketing tactic (campaign), specific offer (content) and customer characteristics (audience) can be read from the contact history. Thus there is no reason to associate them with a source code. Now, the only purpose of the source code is to help tie the response to the outbound contact. The ideal might be to assign each contact a unique identifier, but that could imply millions of codes. This is not very practical, although it’s sometimes used when an accurate match is essential, such as linking payments to orders. The other extreme would assign a unique identifier within the set of promotions sent to each customer: imagine a sequence number showing that this is the customer’s first, second, third, etc. promotion. But this would still require assigning the source code separately for each promotion piece, and assumes that every response will be matched to a known outbound contact. So it also won’t work. A more practical approach is to assign one source code per campaign or, better still, one to each offer. Offer ultimately makes more sense because in most cases each offer will map back to a single campaign. And if it doesn’t–because the customer received the same offer from two different campaigns within the same time span–there is very little real basis for determining which campaign is truly “responsible” for the reply.

In fact, duplicate offers happen all the time. Think of magazine renewals, where the publisher keeps sending reminders until you reply. The card you finally send back may not be the last one you received, even though a later reminder may be what truly prompted the renewal. Magazine marketers have long recognized this fact and, although they do tabulate response for each mailing, they know the correct way to measure the incremental impact of later reminders is to divide a set of subscribers into groups, send a different number of efforts to each group, and compare the cumulative results. Other examples of duplicate offers are Web pages seen repeatedly over time, broadcast or print advertisements, and point of sale materials at retail. Conversely, a customer may receive a single offer for multiple reasons: imagine a catalog marketer who sends promotions to recent buyers, new movers, and new parents. The same (very tired) person could easily fall into all three categories and thus qualify for all three campaigns. Even though the marketer would probably mail just one catalog, all the campaigns could reasonably claim credit for the response.

It’s important to recognize that duplicate offers and overlapping campaigns are only problems for the marketer. The customer doesn’t view contacts as parts of separate campaigns: the customer simply experiences them as they come. Since the marketing database makes it possible to build a list of those contacts, campaigns are no longer needed for response analysis (although they may still be convenient for administration and accounting.) By enabling a comprehensive view of the combination of contacts that led up past results, the database gives the marketer much greater ability to identify optimal customer treatments. For example, it may turn out that contacts from two different campaigns reinforce each other, or cancel each other out. Analysis that looked at each campaign in isolation would never discover this relationship. Similarly, analysis can take into account events beyond marketing campaigns, such as purchases, customer service interactions, and even external conditions such as the economy or competitive offers.

This brings us back to the original topic of changes in system requirements. Clearly source codes can be simplified: rather than being created for unique combinations of campaign, offer and audience segment, they can simply indicate offer. Responsibility for linking the other information to responses is then shifted to the marketing database, and specifically into contact history. Campaigns are replaced with the broader concept of treatment policy, a set of business rules that determines which offer is made in a given situation. The database holds all the information relevant to these rules, in formats that make it easy to recreate the customer’s situation at any past moment and to evaluate the customer’s experience to date. Standard relational databases and SQL are not especially good at presenting these sorts of complex patterns and point-in-time snapshots, so developers are likely to try other approaches. Marketers will need new analytical tools to access this data, find patterns and trends, and simulate the results of alternative policies. Marketing execution will move from conventional campaign managers to rules engines that can read and react to data in real time or something close to it.

Components of this system exist today. Web sites, for example, gauge results largely through page tags that are in many ways similar to content-only source codes. Web experience tracking tools do some types of path and pattern analysis. Fraud detection and anti-money laundering systems use pattern detection, compressed behavior profiles and rule-based triggers. Similar technology is applied to marketing by vendors including Elity, Yellow Brick, and SAS. Specialized database engines and design techniques are available for time series analysis. Simulation, process management and optimization methods are being applied to customer policy development. Various integration technologies are making it easier to combine data to assemble a comprehensive view of customer interactions.

Knitting together these components will not be easy. But the primary barrier to deployment will be the need for marketers to learn a new way of doing things: to shift from managing campaigns to optimizing each customer’s experience. It will be a long while before a critical mass of marketers have adopted this approach. Yet it’s not too soon to start making sure your systems will be ready when the marketers are. You know how impatient they can be.

* * *

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.