Data Science & AI

The Technical University Munich (TU Munich), ETH Zurich and b.telligent haven been working on the PROSET research project for three years from February 2011 to February 2014. The project centered on questions which cannot usually be pursued in everyday working life due to lack of time. In this context, questions which are not only relevant for practice, but also bring to light new findings for research are raised. In the PROSET project, we have concentrated on the question of increasing productivity by means of service experience management.

A particularly productive current discussion revolves around the question what a data science team should actually sensibly produce. The two possibilities are quickly named: on the one hand, there is the "analysis", thus, a one-off, rather static final result; in this context, most people immediately think of a PowerPoint presentation.  On the other hand, there is the "app", i.e. an interactive end product continuously supplied with fresh data, frequently in the form of a website or a mobile app.

I have moved recently and was asked to paint the walls and ceilings of my old apartment by the former property management company. I went ahead right away and tried to get quotes from painting and decorating businesses online. There, I was asked immediately to provide the surface area to be painted in square-meters ... mmh, of course, I could have provided the floor area and the number of rooms straight away, and I had hoped that the businesses would use a simple projection for preparing the quotes. But to directly calculate the surface area to be painted appeared somewhat more complex to me than an off the cuff estimate.

The claim that "Python is not a typed language" now raises my pulse rate just like "Python is simply a scripting language" which was common many years ago.

One just needs to open a Python console and input 1+"1". The result is not 2 as in PHP, for example, but a TypeError. Python is by all means strongly typed, and also differentiates between mutable and immutable types. Because code in Python is not compiled until run time, the above-mentioned addition error makes itself noticed not during programming, but only during execution.

SAS and R are topics which are very closely related: Both are popular tools for people like us who want to solve problems from the environment of statistic and machine learning on (more or less) large data volumes. Despite this apparent proximity, there are few touchpoints between the communities and only few persons work with both tools. As passionated `outside the box´ thinkers, we regret that and want to start a mini-series by means of this blog article in which we deal with topics which connect the both worlds, in loose order. For this first blog article, we will deal with the possibilities to exchange data between the systems. As there is a high number of ways, this article is limited to the transfer of SAS to R; the opposite direction will follow in a later article.

Uplift modelling can support campaign managers in managing and planning campaigns as it supplements the classic response model of campaign scoring.

Uplift modelling is based on the principal idea that campaign responders are grouped in two categories: those who would have reacted even without the campaign and those who would not have responded without the campaign. Unlike classic scoring, which equally aims at both groups, uplift scoring tries to exclusively isolate the second group and, wherever possible, ignore the first. For this purpose, the response information from the control group is used, which remains unused in classic campaign scoring