Sunday, August 23, 2009

Knowledge is only power when you know what to do with it

"Strive not to be a success, but rather to be of value" -- Albert Einstein

Not that long ago I was pitched some predictive analytics project that was promising (according to the vendor) to solve many of my problems. Or, in their words, "just imagine all of the things you could do if you knew that this person is more likely to buy your services than that person". That's usually when the thinking stops and the dreaming begins. However, back on the ground, the question remains - given that knowledge, what exactly do you think you should do, and how do you know that this will be more efficient than what you are already doing?

The whole concept of "doing something" in marketing assumes that 1) your action will change behavior (analysts usually compare to a control group to assess if the behavior changed) and 2) the benefit from change is large enough to pay for the action you have taken. Often, both of those things are assumed to be true, and the action is taken. However, our curious analytical minds cannot take anything for granted, so let's just list some thoughts on why this type of knowledge may turn out a lot less useful when we start executing on it.
  • It is not clear that the behavior can be changed. For example, if you know that someone is likely to disconnect your services (stop purchasing your product, stop paying on the mortgage you are holding) because they lost their job and can no longer afford it, then there is really little you can do to make them keep the services - or, at least, do it in a way that is profitable to you.
  • It is not clear that the behavior needs to be changed. If someone is likely to buy your product, maybe they will - in quantities large enough that you can't improve with your communication. If someone shops at your store every two weeks, provinging a discount often only leads to giving away discount on the purchase that would have happened anyway.
  • It is not clear that you can change the behavior with your action. This is related to the previous point stating that there may not be enough change in the behavior for the action you have chosen. This means that you may have to test a variety of actions, which often makes the knowledge you have obtained from the predictive research less and less relevalnt.
  • The research does not give you much clue on who you want to target. That's when your vendor is going to throw a fit - of course it does, that's the whole purpose of the exercise! Hold your horses, though. So, if one person is more likely to buy your product, why does it mean that this person is more likely to change their behavior and buy your product after receiving a direct mail piece than the other person? From my experience in measurement based on recency, those who have bought the product most recently, are much more likely to buy again, in fact, so likely, that it makes little sense to send them a coupon. It is the other group - people who have bought before, but have not bought in a while that show most change in behavior when sent a coupon. The change is measured as a lift over control group, not as overal response rate. What that says is that if you know that person A is more likely to buy than person B, person B may turn out to be a more profitable target. Combined with the previous point - after all that money spent on predictive research, you still don't know what action to take, and whom to target with it!
  • The research does not give you any information on whether your action is a cost effective way to act on the knowledge. We are again measuring our action against status quo, and looking for a lift in revenue that makes our efforts worthy.
  • It is not clear that you should change your approach to the market. Assuming you have done some prior in-market testing and measurement, and figured out how to segment your market in a way that appears to makes sense based on responses to your communication, it is not clear at all that the additional predictive knowledge is going to help you optimize your marketing. It is nice to know that someone is likely to purchase or cancel your services, however, it does not necessarily ensure a change in strategy. If you know that a certain group of targets needs to be mailed every X month for optimal response, you don't really care that it is because they are more likely to purchase the product - or because they are less likely to. All that matters is that your mailing has been tested and optimized for efficiency.
  • It is possible that your optimal go to market strategy is independent of the segment. That actually happens to good strategies - they let the customers to reasonably self-select, and they offer solutions optimized to serve certain needs. Customizing them on an individual basis is not going to move the needle much, but efficiencies will be lost.
The conclusion is that although the knowledge is a good thing, it is not always possible to use knowledge to improve business results. Correct testing, measurment and execution are generally more important for marketing optimization than having predictive knowledge.

Saturday, August 15, 2009

How to create a great analytical report

"Joy in looking and comprehending is nature's most beautiful gift" -- Albert Einstein

How many times have you been thinking/told that "we need to understand A", and automatically assumed than this means "we need a report on A"? After this conclusion, things usually get into gear - people get together to come up with metrics, they task analytical (code word for "data puller") or IT people to come up with the number, and eventually put it in a nice regular email report. Sometimes things work out, but sometimes the report becomes just one of those efforts that are never used afterwards. In my particular place of work, not only the process spits out something ugly and often completely unuseful, it also takes a Herculean effort wasted on it. The end result is usually hailed a great success, and one of those days you get an email stating that the great new report you have been asking for (no , that was not me) has been created and now published, but we can't send it over email because it is more than 10Mb zipped, so go pull it yourself. Oh, by the way, this report does not include some of the data because we could not trace it properly in the set up we had created, so, it is pretty much not useful, anyway.

How do you avoid this situation from happening? Here are some of my thoughts.
  1. Find out what the true question is.The assumptions about what should be in the report most often come from two camps - the executives and the data pullers. Whenever executive asks for a report that is too specific, like "shows percentage of customers who's discount expires next month", beware. Chances are that what the executive think will answer the question is not what will answer it in the best way, and often, it will not answer the question at all. My personal take on that is to reframe the inquiry, and simply go back to the root - ask the executives about question they are trying to answer. Most times, you will find out that the answer lies in totally different cut of data that was initially assumed. The second camp of people that I have encountered, are data people, particularly, IT people in the organization I am currently working for (was not the case in my other jobs, so I have to make a caveat for them). For some reason, they tend to skip all of the initial exploration steps and jump to a conclusion about what kind of data will answer the question without much regard to the question itself. Sometimes it is not their fault, "they are just doing their jobs", but have yet to see a great report built upon their assumptions.
  2. Research. Can't stress it any more since this is the most common error made in the process, especially, if you are creating something new and not particularly well understood. Before you create a report, you must know what measures to put in it. Sometimes the measures are pretty simple, and sometimes they are not - there is a million ways to slice and dice the data, so if you determined to spend your company's time and money on creating the report, it will pay a hundred-fold to come up with the best slice/dicing technique. A good deep dive research project should have the following properties: 1) it should explain how things work - i.e. what impacts what in that particular area, and by how much; 2) it should compare several metrics for the same process and look at them from different angles - by store/franchise/DMA/division/region, by day/week/month/year, by product type, month of month/year over year, and so on; 3) ideally, it should have that best cut that you just lift from the presentation into the report and feel confident that tracking this measure(s) will tell you all you need to know about the issue going forward in the most efficient manner, meaning, with the least number of measures possible.
  3. Revisit your decision about regular report. Review your research project with peers and executives and decide if creating a structured, regularly updated report is truly needed. Even though it seems not plausible, but understanding of most business processes does not require a regular report. Remember, the conclusion that "we need a report" was just a conclusion, and may have been a wrong one. A deep dive research project may be able to answer most if not all questions, and thus the regular report is not needed. The decision may be to refresh certain parts of the deep dive at some later time, but not to turn it into a regular thing. There may be other reasons not to create a report, including: 1) the data quality is not good; 2) you have not been able to answer the question any better than existing reports; 3) the data is too stable or too volatile, and tracking it will not be insightful (will it do you any good to know that 20% of your orders come from type A customers every month, and the number never budges even a little?); 4) there is insight in the research, but not enough to warrant regular reporting. Remember, a weekly report is 52 times the work of an annual report, and a daily report is 5 to 7 times work of a weekly report. Too many regular reports are not going to promote learning but rather clutter the mailboxes, so be selective about reports that are produced on a regular basis.
  4. Listen to the data - it has the mind of its own. When you finally lift that chart that you want to recreate in a regular report, you have to evaluate it for appropriateness for regular reporting. First question is how hard it is to pull. Sometimes, the very best and meaningful cut of the data is 10 times harder to pull than a cut that is just a hair lower in quality. Multiply the difference in difficulty by the frequency of the report, and see if it makes sense to go for the harder to get number. Second consideration is the amount of maintenance the report will require. What can be pulled for a deep dive not always can be turned into a daily email without daily maintenance of the code. Any regular data pulls must be very stable, i.e. not impacted by customary changes in the information or operational systems. The other side of the maintenance consideration is how much you can automate the report, which should be tied to the frequency. Daily reports must be "set it and forget it" automated. Monthly report may have some pasting and copying in them.
  5. Put metrics in context. One of the biggest mistakes I see made over and over is forgetting about proper setting of the metric. Let's say your metric is total sales by region. Now, how do you know if those sales are good or bad - the regions may be different size and have different sales trends or inherent idiosyncrasies, so comparing them is not always meaningful. You may compare to the previous time period, but what if your business is seasonal? That's where we usually get to the year over year comparison. Now let's say your sales this month are 20% down compared to the sales a year ago (automakers in 2008-2009 are a good example), that must be bad - but not until you see that in the previous months they were 30% down. Proper trending is one of the most important settings in which you should show your metrics. The regular report should be able to tell you if the results are good or bad, otherwise, it is not very meaningful, and nothing can put the metrics in perspective like trending. This also impacts the execution of the report, because it is one thing to pull the data for one month, and quite another to pull it for 15 or 24 months. In an ideal situation, your timeframe and properties of the metric were well defined during the research stage.
  6. Now, finally, it is the time to build and execute the report. First, comes the format. I have always maintained that a pretty chart works magic - so, do use pretty charts. Second, think about the report delivery, distribution list, putting it out on the web-site and all that pleasant stuff. Your analytical part is now over, but polishing your splendid work and delivering it correctly makes a cherry on a sundae. You are working in marketing, after all. Good luck!

Monday, August 3, 2009

Pretty picture = bad methodology?

"Information is not knowledge" -- Albert Einstein

A couple of jobs ago I was working for a large, publicly traded retail company that spent a lot of money on being able to track transactions to particular customers, and got lots of insight from the analysis of their purchasing behavior. Most of the analysis was done very well, however, one particularly important piece of analytics that went through the executive levels like a firestorm as soon as it appeared in a presentation prepared by one very respected management consulting company. The piece of information was so popular, I have heard it reiterated numerous times at investor calls, so I have no conciseness spasms dragging it out to the blog, as this is no longer proprietary information.

Here is how it went: "Our customers who purchase from just one channel spend $X with us, while those who purchase from two channels spend $2X, and those who purchase from all three channels spend $3X with us". By "channels" the company meant physical stores, catalogue, and web-site. The conclusion always was that you want to get your customer to purchase from as many channels as possible, thus increasing her involvement with the brand. What got people to love this particular piece of data the most was the pretty chart - nice bar graph, growing from left to right, showing how the amounts of "spent" money spent nicely stack up, as we see increased "involvement".

I have stated that before and I am going to do it now - beware of the pretty numbers. The ones nicely confirming your hypothesis, and almost magically putting that conclusion into your mind. The numbers may not necessarily be misleading, but as analysts we need to understand the nature of the beast first.

Going back to the beast... namely, the database. I had been working with that database for a while, dutifully slicing and dicing the data, and at some point I got acquainted with the beast enough to project the kind of outcome we get from every dice. For example, if you pick up customers who have had a transaction in Large Category B, their average dollars spent and even the number of transactions is likely to be more than average for the database. Same went for Large Category V, and even not so large Category N. It always looked pretty - we get customers to buy something, and boom they spend more money with us. But do they? Is it a self-fulfilling prophecy again?

Turns out, it was. Around 60% of customers in the database were single-purchase customers, and they probably bought 2 items on average, thus limiting their possible exposure to the product categories. Naturally, the 40% of customers who had multiple transactions were vastly more likely to buy items from any given category. Thus, the comparison was always between average customer and more than an average customer.

Now let's go back to our beautiful channel chart. My careful investigation of the analysis methodology revealed that there was no adjustment for the number of transactions the customers had made. Basically, those who have purchased from three channels must have had at least three transactions (average for the database at the time 1.5), and those who have purchased from two channels must have made at least two purchases, and the single channel purchasers were mostly comprised of the single-purchase customers who by definition could not have have made it to the other groupings - they just did not spend enough with the company! Now, it is my best knowledge that the comparison of those who have spent more with the company to those who have spent less always confirms that the first group spent more, and the second spent less. I believe that's an imprtant finding that we need to keep in mind whenever the numbers are a little too pretty.