Category Archives: Analytics

Tell me what you want to see

Caught this magnificent optical illusion on kottke.org today. I’d say that is definitely  this is worth a minute or two of your time.

Was in my “data” frame of mind when I watched this, and couldn’t help thinking that this is exactly how data works: control the content, control the angle (i.e. perception), and you can make a square block look like a cylinder.

Expensive Software and Consultants

They took our data, ran it through their software, and they got the answers that eluded us for so long.

I was told they were a big consulting company, which meant they probably had great, restrictively expensive software that could do the job. That’s why.

But I don’t buy that argument.

Great software needn’t be expensive.

I’ve lived and breathed great open-source, free technologies growing up. Linux; Apache; PHP; MySQL; WordPress; Python; R.

Are any of these free technologies inferior to their paid counterparts? In development (including data science) work, I don’t think so.

So why were they “successful”? Why could they come up with an answer we couldn’t?

My guess: they were a consulting company with less vested interest.

They came up with an answer. But would it have been better than the one we would have come up with if we were in their shoes? I don’t know.

As a consultant I’d have been much more liberal with my analyses. No matter how badly I mess up, the worst that would happen would be that my company would lose a contract. And chances are good I could push the blame to the data that was provided, or having been provided the wrong context, or information that was withheld.

When you’re part of the company, you have far more vested interest. Not just in your job, but your network, both social and professional. Consequences extend far beyond they would if you were an external consultant working on “just another project”. I’d be far more meticulous ensuring everything was covered and analyses properly done.

 

Business Implications of Analysis

“And,” she said, “we found that the more rooms a hotel has, the higher the positive rating.”

I was at NUS (National University of Singapore) in my Master’s class — listening to my peers present their analysis on the relationship between hotel class (e.g. budget, mid-scale and luxury) and the ratings of several key attributes (e.g. location, value, service) based on online reviews.

By now, having been through ten presentations on the same topic in the last couple of hours, it was clear that there was a link between hotel class and attribute ratings: higher class hotels tended to get better reviews.

But something was missing in most of these presentations (mine included, unfortunately): there wasn’t a business problem to be solved. It was simply analysis for analysis’ sake. Through it all I couldn’t help but think, “so what?”

So what if I knew that a budget customer’s standard of “service quality” was different from that of the patron of a luxury class hotel? So what if I knew that economy-class hotels didn’t differ from mid-scale hotels but differed with upper-scale hotels? So what if I knew that hotels with more rooms tended to have more positive reviews?

(And on this last point, it was a rather common “finding”: it was found that hotels with more rooms tended to have higher ratings, and presented as if if you wanted higher ratings, you might want to build hotels with more rooms; the problem of course is that larger hotels with more rooms tend to be of the higher-end variety; budget and independent hotels tended to have fewer rooms. Would the business implication then be that even budget hotels with more rooms will improve their ratings? Probably not.)

In the end the 15 presentations or so that we went through just felt like a whole lot of fluff. Sure he analytical conclusions were technically correct; statistically  sound. But so what?

It reminded me that you can be great at analysis, but without an understanding of the business, without a mindset of constantly questioning “so what does this mean — what are the implications on the business?”, all your analytical prowess would be for naught.

You make it look so easy

I’ll start with a quote I read today from the book Getting Ahead (Garfinkle, 2011) about a problem faced by people good at their craft. It made me smile because I this was the first time I’d seen it brought up anywhere and which I thought was one of those things I thought you just sucked up and lived with:

Former local San Francisco TV host Ross McGowan was negotiating a contract with his boss. He was surprised when his boss made a fairly low offer, especially considering how high his programs’ ratings were. McGowan asked why the offer was so low and his boss said, “You make it look so easy.”

Not to brag, but I think I do lots of great work (and so do many people I know), but oftentimes I make it look too easy, even when it’s not.

If you work with me, you’ll see the output of my design, programming, and execution. You see the 20 minutes that they can see but miss the 600,000 that has gone on behind the scenes preparing for just this very moment (and moments like these).

You don’t see the hours of PowerPoint deck preparation and storyline rehearsals I do for each and every presentation.

You don’t see the countless trips to the library I make getting books to hone my craft.

You don’t see the endless hours of coding I do just practicing, like differentiating the nuances of a while loop from a for loop so I can use it in my next project.

You don’t see the articles I read on metrics on sales team remuneration design so that I’m aware of potential flaws in the company’s compensation schemes and can proactively work around or advise on these when the time comes.

Easy? If giving up many aspects of life that you feel for and wish you had more time for is easy, then well, yes.

My thoughts on (sales) forecasting and predictive models

I need to have a data-dump on the sales forecasting process and forecasts.

On optimistic and pessimistic forecasting:

  • When forecasts are (consistently) too low: well-known issue that even has a name: sandbagging. You forecast lower to temper expectations. When you do get better results than the forecast you look like a hero.
  • When forecasts are (consistently) too high: quick research on Google shows that this is almost as prevalent as sandbagging. It seems salespeople are by nature over-optimistic about their chances of closing deals. My question though: if you consistently fail to deliver on the high-expectations doesn’t this dent your confidence? I’m not a salesperson, but if I was one I’d probably be a sandbagger (note: this actually reminds me of IT teams, where sandbagging is so prevalent  because of the high variability of project outcomes).
  • If the above is true, that we consistently under- and over-estimate our abilities to deliver, would a range of forecasts be a better bet? But I don’t hear sales leaders saying “don’t give me a number, give me a range.”
  • Would a range solve the sandbagging and over-optimism problem? In a way, it might, since it forces an alternative view that would be hidden should only a single number held sway.
  • Sandbaggers would be forced to say, “well yes, if EVERYTHING went to plan we might get a 20% increase in sales this month,” while the over-optimistic’ers would be forced to say, “fine, you are right that there is quite a bit of risk. A 10% drop wouldn’t be impossible.”
  • The problem with a range is that it is, well, a range. Oftentimes  a single number is preferred, especially if it’s to be communicated to other parties. It’s easier to tell a story with a single number, and its precision (note that I did not say accuracy) is seductively convincing.
  • One way around this would be to explicitly ask for a range, but at the same time ask also for the “highest probability” or “expected” value. This forces thinking about the best and worst case scenarios while giving you the benefit of a single number. And if you were tracking these forecasts, you might actually find that you can systematically take the optimistic forecasts of known sandbaggers and pessimistic forecasts of known over-optimistic’ers.

On the granularity of forecasting

  • When forecasting, the more granular the forecast the more noise you’ll find. I find it easiest to think about this in terms of coin flips.
  • A fair coin gives a 50/50 chance of being heads or tails.
  • If I flipped a coin, there would be a 50/50 chance of it being heads or tails, but I couldn’t tell you with any certainty if the next flip was going to be heads or tails.
  • However, if you flipped a coin a thousand times, I could tell you with certainty that the number of heads would be close to 50%, which is the nature of fair coin.
  • But let’s say I flipped a coin ten times. Could I tell you with certainty that the number of heads would be close to 50%? Well, no.
  • With just 10 flips (or “trials”, in statistical parlance), the probability of getting 5 heads is actually only 24.60%, which means that you have a 75.40% chance of getting something other than 5 heads/tails.
  • As we increase the number of trials, the probability of heads gets ever increasingly closer to 50%. Every additional trial reduces the variability, and you get closer and closer to what is the “nature of the coin”.
  • In sales forecasting there are occasionally times that you are asked to forecast for very specific things, so specific in fact that you might only have 10 historical data points from which to extrapolate. But with just 10 trials, what’s the chance that those 10 would fit the “nature of the thing being predicted”?
  • From Arthur Conan Doyle’s Sherlock Holmes: “while the individual man is an insoluble puzzle, in the aggregate he becomes a mathematical certainty. You can, for example, never foretell what any one man will do, but you can say with precision what an average number will be up to. Individuals vary, but percentages remain constant.
  • One way around this is to aggregate upwards. You can, for example, ask yourself “what category does this thing I’m trying to predict fall into?” and lump this with those other similar things in the same category.
  • Say you have 10 related products that have sold about 10 units each, similar to each other though not identical. Though you could attempt to predict them individually, the small sample sizes per product would give you so much variance your prediction would likely be not much better than chance. It would be better to group these products together into a single category and perform predictions on this larger category.
  • Variations/predictive noise at the individual product level cancel each other out, giving you a cleaner picture.
  • Though looking at the individual products is a precise exercise, it doesn’t add to predictive accuracy.

On Building Great Predictive Models

  • The greatest amount of time spent on developing good predictive models is often in data preparation.
  • Give me perfect data, and I could build you a great predictive model in a day.
  • A predictive model that is 80% accurate may not be “better” than a model that is 70% accurate. It all depends on the context (if this was in the business domain, we’d say it depends on the business question).
  • Let’s say I build a model that is so complex it’s impossible for others but the most technical minds to understand, or which uses a “black box algorithm” (i.e. you let the computer do its predictive thing, but you have no hope of understanding what it did, e.g. a neural network). It predicts correctly 8 out of 10 times (or 80%).
  • Concurrently, I also build a model using a simple linear regression method, which is algorithmically transparent – you know exactly what it does and how it does it, and it’s easily explainable to most laypersons. It performs a little worse than the more complex model, giving me the correct answer 7 out of 10 times (or 70%).
  • Is giving up control and understanding worth that additional 10% accuracy? Maybe, but in a business context (as opposed to a hackathon) chances are good that after the 7th time you spend an hour explaining why the model does what it does, you’ll probably want to opt for the more easily understandable model at the expense of a little accuracy.
  • Business understanding is an important aspects of model building.

Overfitting a model and “perfect” models

  • Finally, I want to talk about overfitting models. Have you heard about overfitting?
  • When we build predictive models, we build them based on past data. In machine learning we call this data “training data”, i.e. data we use to “train” our model.
  • Overfitting happens when we “train” our model so well on training data that it becomes so specific to the data used to train it that it cannot be expanded to predict new data.
  • I find it akin to learning a new language. Sometimes you get so fixated on the grammar and syntax and structure you miss the woods for the trees, that though your speech may be grammatically correct it could be awkward or unnatural (e.g. overly formal, which is often the case if we learn to speak like we write).
  • When somebody speaks to you in a language you’re just picking up using conversational language, you try to process it using your highly formalised syntaxes and grammars and realise that though you know all the words individually, when strung together they make as much sense as investment-linked insurance plans.
  • Overfitting often happens when we try to predict at increasingly granular levels, where the  amount of data becomes too thin
  • In the end the model becomes VERY good at predicting data very close to what was used to build the model, but absolutely DISMAL at predicting any other data that deviates even slightly from that.
  • If tests show you’ve got a model performing at too-good-to-be-true levels, it probably is. Overfitted models perform very well in test environments, but very badly in production.
  • Sometimes when a model performs “badly” in a test environment, ask yourself: (1) is it performing better than chance? (2) is it performing better than the alternatives?
  • If your answer to both (1) and (2) is yes, that “bad” model is a “good” one, and should be used until a better one comes along.
  • Unless, of course, that the resources it takes to carry out predictions, in terms of monetary cost, time, or both, are higher than the benefits it brings. Sometimes a simple model with above-average performance that can be run in a minute can be far more valuable than one with superb predictive performance but which has a turnaround time longer than the time in which decisions are made.
  • I know of some people who look at predictive model and dismiss them simply because they aren’t perfect; or worse, because they’re too simple — as if being “simple” was bad.
  • But models have value as long as they perform better than the alternatives. If they’re simple, quick to run, and require no additional resources to build or maintain, all the better.

So many ideas – have to expand on some of these one of these days.