One well designed metric is better than multiple poorly designed metrics

Obvious, is not it? However, in practice we often go for quantity rather than quality. How about looking at this metric by region? What about product categories? Customer status? Average revenue? Those are all familiar ways to get to the answer by numbers rather than by insight. Instead of going on a slicing and dicing rampage, often it does pay to think twice about where you want to cut next, and cut very diligently. The is one of my zen habits of analytics - to answer the question with the least amount of data possible. Too many numbers on the report/screen translate into junk in the head.
Interesting take on the issue of choice and simplicity is described in the book Paradox of Choice by Barry Schwartz. Just adding to the eternal struggle of wanting more, but being unhappy when we get more. Simple is beautiful.

The most powerful analytical approach I have seen to date

This sounds a little pompous, but it is true. I have used this approach several times in different industries, and in different customer analytics settings, and every time it was huge success. Fortunately, the method is very simple (me like simple!), and can be replicated in a variety of situations.

1. Find a natural break of your total sales into units and dollars (aka rate and volume).
2. Pull the data by various groupings and trend over a few years. Find contribution of each part to the total and trend.
3. Take your volume variable, and repeat steps 1 and 2 again.

Here is an example. Total retail sales by week were broken down by the number of transactions and an average dollar amount per transaction and trended over five years. That of itself was quite a revelation. On the next level, we looked at the number of units per transaction and dollars per unit. Next, we looked at the breakdown of units and dollars per unit by category over time, and then split it into changes due to mix shift, or share of more expensive items that have longer life and lower sales volume, and inflation, or change in price of the same SKU. This was probably the most simple, perfect, insightful, and successful analytical project I lead.

Simple analytics is the best kind of analytics

"Make everything as simple as possible, but not simpler." -- Albert Einstein

Due to the nature of job, I get to have three measurement development and five measurement explanation conversations a week. Thus, it is topic near and dear to my heart. So dear, I sometimes want shoot myself rather than having another conversation about it. Here are my suggestions on how to build an easier road to measurement.

1. Concentrate on the bottom line. Did you make money or lose money? Did you improve overall sales or not? Did you improve overall churn? If you are not using control groups, concentrate on overall numbers. Granted it is much easier to show a stellar performance in one group of customers, but it is usually a false assessment due to self selection. If you have not moved the overall needle, you have not moved the needle. Overall revenue change is good. Overall revenue change year over year is even better. Revenue for a category or a certain selected sub-group of customers may be misleading.

2. Use control groups, if you can. Control groups are the great equalizer of metrics. It's the only panacea against a poorly designed measurement. Let's face it, shit happens, and metrics don't always work out the way we want them. Yet, if you measure it against a matched control group, even the worst metric will usually point you in the right direction.

3. Resist going into the weeds. Weeds require careful use of judgment, otherwise, they will turn into the hell of 100,000 numbers.You all know the drill, after the first look at the report, the executive asks, "and how about we look at those measures by cutting them by X... and Y, and of course, Z". Depending on how many categories are in XYZ, your total numbers in the report all of a sudden explode into a incomprehensible mess. So, this is where the analyst must go into the best diplomatic dance they can manage, saying that of course, we will look and see how that turns out, and surely report back. That's your chance to look at the weeds and see which ones are worth going into. If you see real insight that sheds light on the question at hand, the cut is worth reporting on. If it is just another iteration of the same numbers, simply cut into smaller pieces, then stay away.

It is my firm belief that a report should contain the least amount of data it needs to provide insight, and more data clog your understanding of the picture just as well as too much clothes clog up your clothes, so be ruthless with the stuff that does not add to the understanding. It may lead people on the wrong path, too.

Simplicity is the king

"If you can't explain it simply, you don't understand it well enough." -- Albert Einstein

Today I had a conversation about a very interesting churn model that we may try to build. The model will let us assess impact of different factors on churn, one of those factors is price, or to be precise, pricing changes. When the conversation ventured to the problem at hand, which is to quantify the impact of the most recent price change, I had to explain that I do not want to put this price change into the model. This is anathema to someone with an interest in econometrics, however, there is not as much driven by the scientific truth as by communication, i.e. being able to explain your results. Though adding the most recent data will improve the model, it is unlikely to help with understanding of the issue at hand by those with little knowledge of regression.Having a known coefficient is good, but it is hard to explain what this coefficient means to layperson. Even if you express it in the form of elasticity, let's say, your churn goes up by 1.5% per every percent of a price increase, it does not quite mean anything to most executives. The alternative approach we agreed upon was to build the model on the data before the price increase, and then determine the churn baseline for every segment we are tracking. Then, we can compare post price change churn to that baseline to show the difference. For example, you had a 2% rate increase for this group of customers, and their churn was 6% compared to 3% we would have expected with no price increase. That is something people can understand.

Another example of simplification to aid communication is the correlation analysis I have done a few years ago. For every variable X correlated to my output Y (sales), I would create a bar chart of Y by grouping subjects with "low X", "medium X" and "high X". This spoke better than any scatterplots or correlation numbers. The only difference is correlation in time between two variables - when shown on a nice chart and visibly correlated they make the best case for making executives feel smart.

When comparing, make sure the groups are representative

Sometimes people call them "matched", which is a layman's term for representative. So, why do they have to be matched? Because having non-representative groups may be so misleading, your analysis result may be the opposite of what they should be.

Here is a quick example. Let's say you have two groups of customers, each one of them consists of customers of two types/segments. Sometimes you may not even be aware that there two types of customers in your groups. Let's assume those segments exhibit different behavior. The sample behavior I chose was Churn, but it may be anything. Let's say we applied some sort of treatment to Group #2, and their churn went down by 1% in both segments. We are trying to use Group #1 to establish a baseline (or, what would have happened to the best of our knowledge) to Group #2 if we had not had the treatment. However, because the composition of groups is not representative of each other, we get exactly opposite result for the total - Group #2 appears to have a higher, not lower churn. See table below.

												Group 1	Group 2	Difference
					Segment #1							1,000	5,000
					Seg #1 Churn							5.0%	4.0%	-1.0%
					Segment #2							5,000	1,000
					Seg #2 Churn							2.0%	1.0%	-1.0%
					Total							6,000	6,000
					Total Churn							2.5%	3.5%	+1.0%

Every business is seasonal

At least, I have yet to see one that is not. Out of all basic analytical concepts seasonality is the one that I find underestimated the most. On more than a few occasions I have heard that "our business is not that seasonal" while in reality, seasonal swings may explain up to 80% of sales deviation. Always check for seasonality.

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.

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!

In defense of the big picture

"Confusion of goals and perfection of means seems, in my opinion, to characterize our age" -- Albert Einstein

Someone needs to defend the wisdom of looking at the big picture, so I am going to do just that. How many times do people want to look at the forest, but start looking at trees, then at the leaves of the trees, then at the veins on the leaves? The problem is that while leaves and veins may be fascinating, the forest may be shrinking while you are looking at them, maybe even due to logging. Well, hope, not that severe.

My analysis du jour was looking at a very clever and nicely sampled test that I had devised several months ago. The test has not survived the latest iteration of never ending organizational change, and had to be prematurely ended after a few months in the market. I decided to take a closer look at the results anyway - testing, but never analyzing/making conclusions is one of my pet peeves.

In the test, the target customer universe is randomly split into several groups, and each one of them is delivered a certain dose of our marketing poison (kidding, it's of course marketing manna). Basically, full dose, half-dose, and quarter dose. A few months later, I am looking at the results to understand what happened. What we really want to look at first, is whether consumer sales grew during that period of time - and by how much/how long, not the details of how it grew. That's because at the end of the day, if you are not growing your subscriber/product/sales base, and get more money out of it than you are putting in, nothing else matters. Obviously, the first question I get, is how the subscriber base grew - was it increase in connects, was it drop in disconnects, or a combination of those - because anyone in marketing automatically thinks that they only need to care about connects. Well, plainly speaking, that's wrong. Higher connects usually lead to higher disconnects as certain (and actually surprisingly high) percentage of customers are going to disconnect within the first month or two from the connect. Those disconnects are a direct result of the connects you are driving, and it would be incorrect to count all connects in. On the other side, if higher marketing dose results in lower churn, I will still take it - I really don't care why applying marketing reduces churn, what I care is being able to experimentally confirm that it does and by how much.

Now, I should admit that knowing a certain amount of detail may help you chisel some helpful insight, however, many times it is hard to nip the tendency to evaluate the end result of a program based on that detail. If the bottomline question about a program is whether it worked (aka paid for itself), then this conclusion should be drawn from the bottomline, most "big picture" number. In our particular case, after all the connects, disconnects, upgrades, downgrades, and all sorts of other moves, what difference we are left with, and for how long. The "what" comes first. For how long comes second, and let's not kid ourselves, that "how long" is usually not the lifetime value. LTV and it's [mis]use for campaign evaluation is a totally different topic, which I hope to write about pretty soon.