Do you want to make your head hurt? Think about this: You have x million customers, n number of products and y dollars to spend over some promotion period, say the next three to six months, and at least three contact channels: direct mail, telemarketing and e-mail.
The smart reply is, why would you want to make your head hurt?
So skip to another article or go for coffee. That’s what a lot of direct marketers do. They try to keep it simple.
This month, they say, we’re going to promote product A, next month we’ll promote product B, and so on. We’re going to use direct mail or telemarketing; our fiscal plan calls for so many pieces; we’ll sort our customer file on the basis of RFM or some regression or artificial intelligence model; and then we’ll mail or call as deeply as the budget will allow.
That’s it. And next month we’ll do it all over again.
I’m exaggerating, you say. Nobody could be that simple-minded in the year 2000. Any DM company offering multiple products would not intentionally decide to promote one particular product in one particular month. What that company would do is calculate the expected value of promoting each product to each potential customer. It would also determine this expected value for all possible channels of distribution, and then allocate its monthly budget to maximize return on the discretionary marketing budget.
That strategy certainly sounds better than the product-of-the-month approach, but does it go far enough?
Suppose you could actually execute such a plan? And then another month went by and you re-scored your database and again estimated the expected value of promoting each customer for each potential product, using a model that did not explicitly take into account fatigue – that is, the falloff that occurs when the same product or similar products are promoted in two or more consecutive promotion periods.
What would happen, more or less, is that the same people would be matched against the same products and the prior month’s promotion plan would be repeated, assuming the same budget and adjusting for seasonality.
So is this good or bad? If there’s no such thing as fatigue, then it’s fine – assuming your models are as accurate as possible, which is the only assumption you can make.
But what if there is fatigue and its mirror image – let’s call it the rest factor – as well as yet another possibility, the build-up factor?
To put it another way, if response in one period is affected by promotion activity in earlier periods, then your models have to allow for these effects.
But how? Obviously by affecting your estimates for the next promotion period.
But if fatigue and rest factors do exist and are relatively strong, the implication is that in order to maximize response or contribution – or whatever measure it is you wish to optimize – then your models must extend over a planning period that is greater than one month.
If fatigue is not dealt with directly, the danger is over-promotion and the result is declining response rates.
This effect will be most severe if the product line is limited and your models keep directing the same products to the same people.
This is relatively easy to observe, and to some extent, the only action that needs to be taken is to build in a set of suppression rules so that your models don’t cause over-promotion.
However, if we can measure the effect of fatigue and rest and can begin to gauge the impact of using different channels in different combinations, then we can work toward optimizing promotion or contact strategy over a longer period.
What is required in order to successfully accomplish this is a process for estimating the expected value of each permitted contact effort. Then the expected strategies for an individual can be ranked, and within the context of budget and processing constraints, a promotion plan can be developed that will indeed optimize results over a defined promotion cycle.
So what are the major stumbling blocks to implementing a process like this?
Not knowing how to quantify fatigue and rest, for starters. Therefore, the place to begin is to develop a testing environment in which reasonable strategies can be tested – not all possible combinations, but a limited set of logical tactics.
At the same time, you can begin building the algorithms that will be required to handle the optimization process.
It’s not a simple task, but if you don’t make it more complicated than it needs to be, then your head shouldn’t hurt…at least not too much.
Network
