Thursday 22 December 2016

Why returns on "data science" have been very low and what you can do about it (Part 2: Understand the true costs involved)



In Part 1, I posited that one of the reasons “data Science” had such low RoI was that the expectations of the “business” were too low. This brings me to the importance of metrics, both on the revenue and costs sides of the equation.

I mentioned that the business had no idea what can be done with “data science” and that 2 ways of bridging the gap were to get “data scientists” to talk the “business language” (have enough domain expertise or at least be able to communicate on equal ground with someone who does) and secondly, the advances of technology should be embraced since, at least they speed up analysis and should reduce costs.

So what is the cost of “data science” and is it really that hard to measure it?




First of all there are direct costs to “data science”: the cost of the “data scientist”, the apportioned cost of the IT infrastructure (that can be low if you use open source solutions and have proper IT infrastructure roadmap – something that is beyond me to do, but which is aligned with a “data science” roadmap which I think is essential) and the costs of running the experiments/campaigns.

I had a very interesting conversation at Strata in Singapore this year with someone from Swansea University. They have data analytics and data science programs for all sorts of different skill levels in the field of health sciences.

It does make sense, right, that in order to be qualified to be a data scientist in a field where lives may be at stake, you’d need proper background, domain knowledge? For example, the Master’s programme requires some real life application in the field by practitioners so they can be awarded the qualification.

It makes sense because the most people would agree that the cost of mistakes in the medical field is very high. Hence domain knowledge is seen as critical. But are the costs of “data science” mistakes in the commercial world low?

I have a friend who works at one of the large banks in Singapore who has a Masters in Analytics from the Singapore Management University (SMU) and has extensive work experience in the banking sector. She was asked to hand over her model building role to someone so new that her only knowledge of the banking world was in Human Resource, and focus on churning out campaigns. Her manager explained the decision by saying that building models can potentially cause less harm than doing campaign management (cleansing the lists which ironically may have come from the models). 

This brings me to the idea of potential harm.



My friend’s manager simply believes that little harm can come from the application of “data science”/analytics. If that was true, then “data science” is the Holy Grail: little potential for harm, but huge potential for good! The adage “if it looks too good to be true, it probably is” surely applies here.

My friend’s manager is totally ignoring the opportunity cost of contacting a customer. Many organisations today have relatively well oiled campaign machines, churning offers to customers on a regular basis, and there usually are contact policies in place: a customer cannot be “disturbed” that many times. Basically: any offer you contact a customer with implies there’s another he/she is not getting

Furthermore, going back to the customer contact policy, there is the classic argument of customer fatigue. Unless the contact policy has been set ‘properly’, there is a risk of customers simply ignoring the communications from an organisation if these constantly bring no value. The customer need not complain, simply ignore. Setting the contact policy itself is thus critical and is something relatively simply analysis can reveal.

With today’s technology, behavioural factors are being taken into account more often in “data science” algorithms, and “real time” offers can be made following triggers based on each customer’s behaviour. For example, if I know you usually like a good cup of coffee after your meal, once you pay for a meal using your credit card, I can almost instantly make you aware of offers for coffee with that card in the vicinity (combining behavioural pattern and geo-location to make you a relevant offer). This can even go a level deeper, for example, I may know your child’s birthday is in a week, and after you finish your meal, I decide, instead to send you an offer at the nearby toy store. How I decide which offer to make can depend on the chances of success, and the relative ticket sizes, but all this can be fed into your fulfilment engine and the ‘best’ offer made on the fly.

It is however important to distinguish between tactical and strategic moves. A danger when using “real time” offers is these are often purely tactical, contextual yes, but purely short term. It can be argued that if that through my offers I manage to make a customer move my credit card to the top/front of the stack of cards he/she holds, then the customer would use my card more often with or without offers (free money!). But customers learn, and their expectations change, may be they will wait for that offer at a toy store before purchasing the present, after all, the child’s birthday is still a week away; Doctor Pavlov’s experiments were with dogs, not humans.

Hence costs should be expanded to include opportunity costs, but also a strategic Customer Lifetime Value (CLV)/Customer journey component. An organisation’s relationship with a customer should not be a series of short term interactions, but, hopefully a long term one punctuated by strategic reinforcements[1].

If costs have to take into account not only opportunity costs, but also a longer term view of the impact on the relationship with the customer. So should revenues.

Some organisations have attempted to bridge the gap between the short term tactical approach, and the long term strategic engagement by creating a series of small journeys a customer engages into, and where the organisation wants to help, profitably.

For example, in the case of the child’s birthday, based on past patterns or similar people, the journey can include the gift, booking a venue for the party with friends, arranging for caterers for the party, engaging entertainment (may be a clown?)... A bank that identifies these steps a customer is likely to take within a kid’s birthday journey can send offers to the customer that make his/her preparation for the birthday easier while generating more revenue for the bank (using the bank’s credit cards at participating merchants).

This is a step in the right direction. But eventually, this is only one micro-journey; it makes more sense for an organisation to work on the macro journey, from customer acquisition, growth, reaching a plateau, and may be exit, and use these micro journeys to manage the customer, creating and reinforcing habits. When you have millions of customers is where “data science” can really shine, allowing you to personalise every journey based on the strategic decisions made, and even affect customers via their social network [2].




Hence the costs of not making the right offer at the right time to the customer go much beyond the simple costs of the hardware, software and time of the “data scientist”, but only if the organisation is set up to really take full advantage of data science.

To me, an organisation needs to be properly set up to enjoy the benefits of “data science” and understanding the actual costs of bad “data science” is only part of it, but an important starting point. As mentioned above, the best way to do this is to align the infrastructure roadmap with the data science roadmap so the “data science” adventure pays for itself, fully realising the costs and revenues.

This will be the topic of my next instalment.

To summarise:

  • While many organisations get low RoI out of “data science” the RoI is even lower that they believe because they tend to underestimate the costs of data science
  • While I argued that technology should be fully utilised and would be likely to bring down costs, the hardware, software and “data scientist” time costs are just a small part of the costs.
  • Many organisations have contact policies and campaign machines, they fail to include the opportunity costs when they calculate the costs of a campaign.
  • Furthermore, with technological advances, it is not that difficult to make real time offers to customers, trying to be the “right offer at the right time”, to be contextual.
  • However, very often these are purely tactical in nature and do not maximise what “data science” can do for the organisation.
  • Some organisations have attempted to build event based customer journeys, and while these are a step up from purely tactical approaches, they are still quite short term in nature.
  • To understand the true costs of “data science” and reap its full benefits, an organisation has to exploit “data science” across the whole relationship with the customer, not just in a purely tactical piece-meal fashion.
  • How well organisations have been setting themselves up to benefit from “data science” will be the topic of my next post.


 




Thursday 15 December 2016

Why returns on “data science” have been very low and what you can do about it (part 1 – unreasonably LOW expectations)



I have had a fair bit of time to read-up, play with some of the ‘new’ technology, talk to people from the IT, Business, and “Data Science” field in the last few months, and have decided to type my thoughts. I have arranged them in 3 broad lines of themes and will be sharing them from now til the end of the year. 

They address why “data science” hasn’t brought the expected returns, and what can organisations do about it. 

My theme for today is: unreasonably low expectations.



People who call themselves “data scientists” come with a dizzying array of skills. For a “data science project” to be successful, there needs to be collaboration among different skill sets, and one large part of clearing the path to returns is assembling these key skills, which are likely to reside in two or more people working truly collaboratively. 

“Data Scientists” are supposed to have the sexiest jobs of the 21st century [1], and many “data scientists” work hard to substantiate this claim, cultivating the mystique around the role. 
Many organisations are under the spell of the “data scientist” and expect that one specialist (or a group of similar specialists) to have all the answers and follow that specialist in setting expectations, which are most often much lower than what could really occur; it’s a game with asymmetric information

The business wants high returns but doesn’t know what is achievable, the “data scientist” wants a reasonably low promised return but can control, to some degree, how large these returns are. And usually in such games, the one with less information end up getting sub-optimal results – the one holding the aces wins, irrespective of whose deck of cards it is.

(Furthermore, the interests of the “data scientist” and that of the business may not be aligned, the business focusing on the results and the “data scientist” on the process. And in this case too, the “data scientist” holds the aces; the principal-agent problem; but that’s a topic for another day.)

Not so long ago, I attended a best practice sharing session when a colleague from Europe shared his success, a model/algorithm whose lift was 1.2. This means the “data scientist” (and presumably the client) were satisfied with being only 20% better than randomly picking customers from the database (worse still that was a theoretical lift, not the result of tracking an experiment). And in case you were wondering this was not for high margin high ticket products, it was plan upgrade in telco. 

In a previous role my manager was about to accept the work of a team of consultants whose performance was 1.28x the old model in place. Clients trust “data scientists”, it is up to us not to take advantage of that trust.

I have a rule of thumb, any model/algorithm I build has to have a lift of 2 in the top group. Of course I won’t take on any project; if i believe there is little prospect of me creating a model/algorithm that will generate 2x better results than what my client has, I will work with the client to find a situation where he/she will get proper Returns of his/her Investment (RoI); this may take a lot of discussions but is worth the effort even if it delays the commencement of what is usually considered as the core of a “data science” project.

As you probably can tell I wasn’t always very popular with my bosses; but to me there has to be a commitment to a certain quality, and RoI in any “data science” project.

The fact that “data science” is in general not delivering the returns it can has caused many people to think how this can be remedied. HBR came up with 2 articles recently with 2 possible solutions.
“Better questions to ask your data scientist”[2] posits there is a communications gap between the “data scientist” and the “business”. I agree. Referring to the Drew Conway’s “data scientist Venn diagram”[3]:

Most people who are hired as “data scientists” are lacking in domain knowledge. The HBR article attempts to bridge that gap by advising the “business” the type of questions they should be asking the “data scientist”, making the “business” speak the language of the “data scientist”. 

I think that’s absolutely the wrong approach; at best it is a stop gap measure, but it will not generate the RoI that the proper application of “data science” can generate. It’s like expecting a patient to be speaking in medical terms when at a doctor’s. To me, the doctor should be the one who speaks in the language of the patient. 

Would you trust your health to some medical lingo you picked up in an article, or would you prefer a doctor who can speak in your language? 

Then, why would do that to your business by trying to pick up “data science” lingo?

Another approach, again as suggested by HBR in “why you are not getting value from your data science” [4], is to do a different kind of “data science”, make is simpler. Again, in principle, I agree. This, it is argued, is the way to make “data science” faster, to be able to keep up with business needs, and hence increase the RoI.

One of the most stunning descriptions of the article is “machine learning experts (data scientists focused on training and testing predictive models) “. This illustrates totally what “data scientists” are seen as even in the corporate/commercial world. To me, if a data scientists isn’t engaging in predictions, what is he/she doing, looking good in a lab coat? It’s no wonder you don’t get good RoI from his/her.

The article goes on to state that the solution is to use simple models, on samples of the data rather than on the whole lot, and potentially disregard the technological advances such as parallel processing (Hadoop, Rev-R, Aster...). To me if you follow these recommendations, you are simply going backwards in time. 

Parallel processing (and it’s ugly cousin in-memory processing), cheap storage, the development of tools that allow you to relatively easily run a whole suite of algorithms on ‘all the data’ and get results quickly allowing rapid iterations are the key drivers in “data science”. It would be doing a disservice to one’s organisation to ignore that. 

There is a balance to be struck between depth of analysis and number of iterations on one hand, and the speed to market on the other. Taking advantage of the key drivers in “data science” skews the old equation, allowing more to be done in the same amount of time, or the same level of analysis in a much shorter time.

In the past, once I submitted my programs, I would have the time to go out for a cup of kopi before the results were ready. Now I barely have the time to go to the toilet.

That should be a good thing; it potentially enables the organisations to quickly execute experiments on the basis of the output from a “data scientist”, and that is an integral part of deriving RoI out of “data science”.

To summarise:

  • Low RoI out of “data science” is a reality most organisations are experiencing.
  • One of the reasons for this is unreasonably low expectations from the business, together with asymmetry of information, and to some degree a potential principal agent issue
  • Good collaboration between the business who is supposed to drive the RoI and the “data scientist” who is supposed to enable that is one of the easiest ways to resolve this issue.
  •  In this case it is very important that the 2 parties speak a common language, and it is preferable for the “data scientist” to have enough domain expertise to speak the language of the business (this will also help in doing better “data science” but again, that’s a topic for another day)
  • Obviously, since “data science” is driven by technology, any “data science” effort should take advantage of technology. 
  •  This should speed up experiments and enable organisations to take full advantage of “data science” to generate proper RoI.
  • However, the organisation itself has to be geared to do that. But in order to be geared in such a way, it is important to be able to measure the impact of “data science” and this will be the topic of my next blog.