Kategoriale Variablen können in SPSS als ursprüngliche Texte verwendet werden, was bei größeren Datenmengen beträchtliche Performance-Einbrüche mit sich bringt, oder als numerische Codes mit Labels. Der zweite Weg ist nicht nur drastisch performanter, sondern auch der richtige Weg, weil es den Code in der SPSS-Syntax zwar schlechter lesbar macht, aber dafür völlig immun gegenüber Änderungen in Schreibweisen ist.
Seit meinem Psychologiestudium war ich ein intensiver SPSS-Nutzer. Was mich über alle Versionen in dieser Zeit begleitet hat, waren die einfachen, knappen Befehle, um mir deskriptive Statistiken anzeigen zu lassen. Diese kurzen Kommandos gehen schnell in Fleisch und Blut über und ermöglichen ein schnelles Sichten der Daten. Aktuell liegt mein Tool-Schwerpunkt bei R. Es ist eine hervorragende Alternative, aber trotz umfangreicher Erfahrung mit diesem Open-Source-Tool fehlt mir immer noch ein bisschen die gefühlte Usability von SPSS. Mir fehlen schlicht und einfach meine kurzen Kommandos. Nun ist es relativ leicht, SPSS-ähnliche Befehle selbst als Funktionen in R zu ergänzen.
Am PROSET-Forschungsprojekt arbeiteten die TU München, die ETH Zürich und b.telligent für insgesamt drei Jahre, von Februar 2011 bis Februar 2014. Im Mittelpunkt standen Fragestellungen, für deren Bearbeitung im gewöhnlichen Arbeitsalltag meist keine Zeit bleibt. Dabei werden oftmals Fragen behandelt, die nicht nur für die Praxis relevant sind, sondern auch neue Erkenntnisse für die Forschung ans Licht bringen. Im PROSET-Projekt haben wir uns der Frage der Produktivitätssteigerung durch Service Experience Management gewidmet.
Eine besonders fruchtbare aktuelle Diskussion dreht sich um die Frage, was ein Data-Science-Team eigentlich sinnvollerweise herstellt. Die beiden Möglichkeiten sind dabei schnell benannt: Auf der einen Seite steht die "Analyse", also ein einmalig erstelltes, eher statisches Endergebnis; die meisten denken hier sofort an eine PowerPoint-Präsentation. Auf der anderen Seite steht die "App", also ein interaktives, ständig mit frischen Daten versorgtes Endprodukt, häufig in Form einer Website oder einer Mobile App.
Ich bin vor kurzem umgezogen und wurde von meiner alten Hausverwaltung gebeten, die Wände und die Decken der verlassenen Wohnung zu streichen. Ich habe mich sogleich im Internet um Vergleichsangebote von Malerbetrieben bemüht. Dort sollte ich gleich zu Beginn die zu streichende Fläche in Quadratmetern angeben ... mmh, ich hätte natürlich sofort die Grundfläche und die Anzahl Räume angeben können und gehofft, dass die Betriebe eine einfache Hochrechnung für die Angebotserstellung verwenden. Aber direkt die zu streichende Fläche zu ermitteln, schien mir etwas komplexer als eine Schätzung aus dem Stegreif.
Die Behauptung „Python ist keine typisierte Sprache“ erhöht meinen Puls mittlerweile genauso wie das vor vielen Jahren übliche „Python ist nur eine Scriptsprache“.Man muss nur schnell eine Python-Konsole öffnen und 1+"1" eingeben. Das Ergebnis ist nicht, wie z. B. bei PHP, eine 2, sondern ein TypeError. Python ist sehr wohl stark typisiert und unterscheidet zudem auch noch zwischen mutable und immutable types. Da der Code in Python erst zur Laufzeit kompiliert wird, fällt der gerade genannte Additionsfehler an sich nicht beim Programmieren, sondern erst bei der Ausführung auf.
SAS und R sind Themen, die dicht beieinanderliegen: Beides sind populäre Werkzeuge für Leute wie uns, die Probleme aus dem Umfeld von Statistik und Machine Learning auf mehr oder weniger großen Datenmengen lösen möchten. Trotz dieser scheinbaren Nähe gibt es wenig Berührungspunkte zwischen den beiden Communitys, und nur wenige arbeiten mit beiden Werkzeugen. Als passionierte Über-den-Tellerrand-Blicker finden wir das schade und möchten mit diesem Blogeintrag eine Miniserie starten, in der wir uns in loser Folge mit Themen beschäftigen, die beide Welten miteinander verbinden. Für diesen ersten Blogeintrag werden wir uns mit den Möglichkeiten beschäftigen, Daten zwischen den Systemen auszutauschen. Da es eine große Vielzahl an Wegen gibt, beschränken wir uns für diese Folge auf den Transfer von SAS zu R; der entgegengesetzte Weg folgt in einem späteren Eintrag.
Uplift-Modeling kann Kampagnenmanager bei der Kampagnensteuerung und -planung unterstützen, da es das klassische Response-Modell des Kampagnenscorings ergänzt. Uplift-Modeling geht von der Grundidee aus, dass man die Kampagnenreagierer in zwei Gruppen einteilt: diejenigen, die auch ohne die Kampagne reagiert hätten, und die, die das ohne die Kampagne nicht getan hätten. Während klassisches Scoring unterschiedslos auf beide Gruppen abzielt, versucht das Uplift-Scoring, exklusiv nur die zweite Gruppe zu isolieren und dabei die erste möglichst zu ignorieren. Zu diesem Zweck werden die Responseinformationen aus der Kontrollgruppe verwendet, die im klassischen Kampagnenscoring ungenutzt bleiben.
