UNIVERSITÄT DORTMUND LEHRSTUHL MARKETING

Transkript

1 UNIVERSITÄT DORTMUND LEHRSTUHL MARKETING Marc Seitz, Jörg Rüppel, Christian Blichmann Projekt Allenby et al. Seminarbericht Oktober 2005 Wirtschafts- und Sozialwissenschaftliche Fakultät Betreuer: Prof. Dr. Florian von Wangenheim GERMANY D DORTMUND

2 Inhaltsverzeichnis Vorwort Aufgabenstellung iii v 1 Vorarbeiten Java, C/C++, R? Datenimport und -aufbereitung R RODBC Weitere R-Pakete bayesm MCMCpack A Dynamic Model of Purchase Timing Modellauswahl Entwicklung eines R-Skriptes Probleme Fazit 10 A R-Skripte 11 B MySQL-Datenbanken 16 Literaturverzeichnis 19

3 Vorwort Diese Seminarausarbeitung beschäftigt sich mit der Analyse von Geschäftsvorfällen und den daraus resultierden Maÿnahmen für das Marketing eines Unternehmens. Es soll ermittelt werden, wann ein Kunde in einen inaktiven Zustand fällt, so dass das Marketing oder der Vertrieb frühzeitig entsprechende Maÿnahmen zur Kundenbindung ergreifen kann. Als Grundlage zu diesem Seminar dient das Paper von Allenby, Leone und Jen [ALJ99]. In diesem Paper stellen die Autoren eine neue Analysemethode für Kundenaktivitäten vor, die nicht dem klassischen Schema entspricht. Bisher ergreifen die meisten Unternehmen nach einer bestimmten Zeit der Konsum-Inaktivität Marketing-Maÿnahmen mit dem erhoten Eekt, den Kunden wieder reaktiveren zu können. Dabei wird jedoch nicht berücksichtigt, dass Kunden verschiedene Aktivitätsphasen haben. So ist es z.b. für längerfristige Wertpapieranlagen nicht unüblich, nur einmal im Jahr akiv zu werden, während es im gleichen Marktsegment Kunden gibt, die jeden Tag Geschäftvorfälle veranlassen. Mit dem neuen Analyseverfahren von Allenby, Leone und Jen werden diese Gegebenheiten besser berücksichtigt, und im Idealfall nur die Kunden kontaktiert, die wirklich inaktiv sind in Bezug auf das jeweilige Konsumverhalten gegenüber dem Unternehmen. Es wurden zwei Datensätze benutzt, mit denen das obige Modell nachgestellt werden sollte: ein Retail-Datensatz mit Verkaufsdaten eines Kaufhauses, sowie ein Airline- Datensatz, der Daten zu Flugbuchungen enthält. Das Analyseverfahren basiert auf einem hierarchischen Bayes-Modell mit nach Generalized-Gamma verteilten, so genannten Interpurchase-Times Zeiten, die zwischen zwei Geschäftsvorfällen liegen. Das im Paper entwickelte Component-Mixture- Modell erlaubt dabei sowohl sektionale als auch temporale Heterogenität, was durch die Verwendung von multiplikativen Kovariaten erreicht wird. Die eigentliche Analyse eines Datensatzes wird mittels Markov-Chain-Monte-Carlo-Methoden durchgeführt. Im Groÿen und Ganzen werden für die Berechnung vier Formeln benötigt, die im weiteren Verlauf dieser Ausarbeitung vorgestellt werden. Schwierigkeiten bereitet jedoch genau die Umsetzung dieser Formeln die während des Seminarzeitraumes erarbeitete Implementierung lieferte leider keine sinnvollen Ergebnisse. Aus diesem

4 Vorwort iv Grund werden in der Ausarbeitung detailliert die Probleme bei der Anwendung des Modells geschildert. Ebenso ist keine Angabe zur Ezienz des neues Verfahrens aus eigenen Versuchen möglich. Dortmund, Oktober 2005

5 Aufgabenstellung Projektgruppe Allenby et al. Als wissenschaftsorientierte Unternehmensberatung haben Sie in der Branche einen exzellenten Ruf im Bereich Analytical CRM aufgebaut. Die Fluggesellschaft Germanisches Flugkartell hat von Ihren Fähigkeiten gehört. Der GA sind in letzter Zeit einige Kunden verloren gegangen. Auÿerdem hat man den Eindruck, dass bei vielen ehemaligen Kunden die Aktivitätsrate in den Keller gegangen ist die interpurchase time (IT) ist also gestiegen. Konkret verabreden Sie im ersten Schritt mit der Fluggesellschaft, die Inaktivitätszeiten (interpurchase times) der Kunden zu modellieren und prognostizieren. Der Leiter der Abteilung Kundenanalyse hat vor kurzem einen Vortrag von Prof. Allenby gehört, der hier auf leicht verständliche Weise sein Modell zur Prognose von ITs vorgestellt hat. Sie vereinbaren, dass Sie in einem ersten Schritt das Modell auf einen Teil der Airline-Kunden anwenden und mit Hilfe einer zweiten Stichprobe testen. Im Vergleich zu dem Aufsatz von Allenby werden Sie auch noch gebeten, eine Reihe von Kovarianten auf ihren Einuss auf die IT zu testen: Alter, Geschlecht, Cross-Buying Aktivitäten, genutzter Transaktionskanal, genutzte Direktkommunikation (wird noch speziziert). Ihre Aufgabe lautet, dem Unternehmen Hinweise dahingehend zu geben, welche Kunden reaktiviert werden müssen, weil sich ihr Aktivitätsniveau verringert hat. Sie selbst sind so überzeugt von dem Projekt, dass Sie darüber hinaus den Datensatz eines zweiten Unternehmens, aus dem Einzelhandelsbereich, heranziehen. Sicherlich wird sich der Kunde über eine Auswertung und entsprechende Handlungsempfehlungen freuen. Vorgeschlagene Projektschritte: 1. Stellen Sie das Allenby-Modell anhand eines selbsterstellten Test-Datensatz nach. 2. Transformieren Sie die beiden Datensätze in auswertbare Formate. 3. Vollziehen Sie, anhand einer ersten Teilstichprobe, die Rechenschritte des Modells von Allenby et al. (1999) schrittweise nach. 4. Variieren Sie die Modellkonguration um unterschiedliche Verteilungsannahmen und Anzahl von states zu überprüfen.

6 Aufgabenstellung vi 5. Untersuchen Sie die Güte des Modells anhand von Fit-Kriterien und interpretieren Sie die Parameter für die eingeschlossenen Kovariaten. 6. Untersuchen Sie die Güte Ihrer Vorhersage mit Hilfe des hold-out samples. 7. Wiederholen Sie das Ganze für den Einzelhandelsdatensatz. 8. Geben Sie, aufbauend auf Ihren Ergebnissen, der Airline und dem Einzelhändler Empfehlungen zum weiteren Vorgehen. 9. Reektieren Sie kritisch Ihre Erfahrungen mit dem Modell von Allenby et al. (1999). Rechtfertigt die Qualität der Ergebnisse den Aufwand der Analyse? Ist das Verfahren im Hinblick auf die daraus ableitbaren Konsequenzen einer einfachen Entscheidungsregel (z.b.: alle Kunden, die vier Quartale nicht gekauft haben, sind inactive) überlegen?

7 1 Vorarbeiten Zu den Vorarbeiten dieser Seminararbeit gehörte die Auswahl einer geeigneten Arbeitsumgebung. Es gab mehrere Möglichkeiten, die Vorgaben aus dem Paper von Allenby et al. [ALJ99] umzusetzten. Zum einen bot sich eine objektorientierte Programmiersprache an, zum anderen die für statistische Zwecke entwickelte Programmiersprache und Umgebung R. 1.1 Java, C/C++, R? Zur Auswahl bei der Arbeitsumgebung standen Java, C++ und R. Die Wahl el auf R, da diese eine speziell für statistische Zwecke entwickelte Programmiersprache und Umgebung ist. Ebenso sind in R diverse Tools/Pakete enthalten bzw. installierbar, die sowohl grundlegende als auch komplexe statistische Rechnungen durchführen können. Damit entfällt bei R die Implementierung vieler Funktionen, die in Java oder C++ aufwändig durch extern eingebundene oder selbstprogrammierte Bibliotheken hätten nachgebildet werden müssen. Ein Nachteil bei der Verwendung von R sollte jedoch nicht verschwiegen werden: Der im Informatik-Umfeld recht geringe Verbreitungsgrad und die komplexe Syntax führen zu einer als deutlich steiler empfundenen Lernkurve, als dies bei anderen Programmiersprachen der Fall ist. So stellte die Einarbeitung in R einen nicht unerheblichen Zeitaufwand dar. 1.2 Datenimport und -aufbereitung Die Datensätze lagen in einer reinen Textdatei vor. Um diese in R verfügbar zu machen, wurden diese in eine MySQL-Datenbank eingepegt (siehe Abschnitt 1.3.1). Des Weiteren sind beim Datenimport nicht benötigte Spalten, wie z.b. die Art der gekauften Artikel, entfernt worden, um die Dateigrösse zu verringern. Über das R- Paket RODBC wird die Datenbank angesprochen und die Daten ausgelesen.

8 1 Vorarbeiten R R kann kostenlos über die Homepage des R-Projektes 1 bezogen werden. Eine Anleitung zur Installation ndet sich dort ebenfalls. Weitere Informationen zu R können dem Handbuch [R D05] entnommen werden. Zusätzlich zur Standardinstallation von R wird das Paket RODBC [Ori05] verwendet. Allgemein werden Pakete in R über den Menüpunkt Packages Install Package(s)... installiert, wobei eventuelle Abhängigkeiten automatisch aufgelöst werden. Die einzelnen Funktionen der Pakete können in den jeweiligen Anleitungen nachgelesen werden. Im weiteren Verlauf werden nur die benötigten Funktionen vorgestellt RODBC Dieses Paket dient zur Anbindung an ODBC-Datenbanken 2, wie sie z.b. unter Windows üblich sind. Im vorliegenden Fall wurden MySQL 3 sowie der MySQL ODBC- Treiber [MyS05] eingesetzt. Das ODBC-Konzept von Datenquellen erlaubt es jedoch leicht, andere Datenbanken wie Access oder MS-SQL zu verwenden. Im Listing 1.1 sind die Befehle aufgelistet, um die Datenbank zu kontaktieren und Daten auszulesen. Die Struktur der Datenbank-Tabellen kann im Anhang B nachgelesen werden. Listing 1.1: Anwendung des Pakets RODBC 1 # ODBC - Paket laden 2 library (" RODBC ") 3 4 # String Konkatenation, hängt zwei Zeichenketten aneinander. 5 "~" <- function (x, y) paste (x, y, sep = "") 6 7 # Datenbankverbindung herstellen. 8 channel <- odbcconnect (" allenby ") 9 10 # Beispiel : Die ersten 10 unterschiedlichen Kundennummern sortiert 11 # und in aufsteigender Reihenfolge holen 12 query <- " SELECT DISTINCT KundeNr FROM retail ORDER BY KundeNr " ~ 13 " ASC LIMIT 10" 14 list <- sqlquery ( channel, query )[,] Open DataBase Connectivity, siehe auch htm/dasdkodbcoverview.asp 3

9 1 Vorarbeiten 3 16 # Kundennummern ausgeben 17 list # Datenbankverbindung schlieÿen 20 odbcclose ( channel ) 1.4 Weitere R-Pakete Im Verlauf der Seminararbeit wurde von Rossi, Allenby und McCulloch das Buch Bayesian Statistics and Marketing [RAM05] vorgestellt/veröentlicht. Dieses behandelt unter anderem Teilaspekte der Aufgabenstellung. Parallel zur Buchveröentlichung wurde auch das R-Paket bayesm [RM05] zur Verfügung gestellt bayesm Das Paket bayesm ist Begleitmaterial zum bereits in Abschnitt 1.4 erwähnten Buch. Neben Beispieldatensätzen enthält es R-Funktionen für die meisten im Buch beschriebenen Algorithmen und Modelle. Obwohl von den gleichen Autoren, wird das dem Paket zugrunde liegende Paper der Aufgabenstellung in der Dokumentation nicht erwähnt oder referenziert. Des Weiteren lassen die Datensätze und zugehörigen Beispielskripte in der Dokumentation keine unmittelbaren Parallelen erkennen, die eine Verwendung der angebotenen Funktionalität ohne gröÿeren Aufwand gestatten. Um das Verarbeiten gröÿerer Datensätze ezient zu ermöglichen, sind die Berechnungsfunktionen in einer C++-Bibliothek implementiert, die von den einzelnen R- Routinen aufgerufen werden MCMCpack Ein Weiteres untersuchtes Paket ist MCMCpack [MQ05], ein Paket für Bayesian inference. Es bietet ähnliche bzw. überlappende Funktionalität wie bayesm, ist jedoch zur Auswertung auf das coda-paket angewiesen [PBCV05]. Auch hier stützen sich die Berechnungsfunktionen auf eine externe C++-Bibliothek, in diesem Fall auf die recht weit verbreitete Bibliothek Scythe

10 1 Vorarbeiten 4 Die Funktion MCMCmixfactanal() implementiert die im Vorwort erwähnten MCMC- Methoden aus dem Paper, jedoch ist die Adaption auf die Aufgabenstellung alles Andere als trivial (siehe Abschnitt 2.2).

11 2 A Dynamic Model of Purchase Timing Um das Modell aus [ALJ99] nachzustellen, wurden die folgenden Schritte identiziert: 1. Auswahl einer der vier Modellvarianten: Gamma-Dichtefunktion und Inverse-Gamma verteilte Heterogenität für Interpurchase-Times (mit temporal dynamics, λ = 1) Obiges Modell ohne temporal dynamics Generalized-Gamma-Dichtefunktion für Interpurchase-Times mit temporal dynamics Generalized-Gamma-Dichtefunktion ohne temporal dynamics 2. Formulierung der Modellgleichungen in R 3. Ausarbeitung eines R-Skripts zur MCMC-Inferenz des Modells unter Benutzung von bayesm oder MCMCpack 4. Ausführen des Skripts und Auswertung der Ergebnisse Temporal dynamics bezeichnet hierbei die individuelle zeitliche Dynamik der einzelnen Kunden. So bendet sich zum Beispiel ein Kunde in einem aktiven Zustand, wenn dieser einmal im Monat kauft, während ein anderer Kunde als noch aktiv gilt, wenn nur einmal im Jahr gekauft wird. Übertragen auf Aktienkäufe würde dies den Unterschied zwischen kurz- und langfristigem Anleger bedeuten. 2.1 Modellauswahl Bei der Auswahl eines nachzustellenden Modells war es Ziel möglichst wenig eigenen Quellcode zu schreiben, um mögliche Fehlerquellen von vornherein auszuschlieÿen. So el die Wahl auf das Component-Mixture-Model mit Generalized-Gamma

12 2 A Dynamic Model of Purchase Timing 6 verteilten Interpurchase-Times und Inverse-Generalized-Gama verteiler Heterogenität. Dieses Modell erlaubt temporal dynamics und verwendet nachgelagerte Log- Interpurchase-Times und drei Kovariaten. Dieses Modell ist von den vorstehend vorgestellten zwar das Aufwändigste, jedoch sind alle benötigten Gleichungen und Variablen beschrieben. 2.2 Entwicklung eines R-Skriptes Der Anhang des Papers von Allenby et al. beschreibt sehr knapp die Vorgehensweise. Zunächst werden alle benötigten Variablen mit den vorgegebenen Werten initialisiert: 1 # Werte für Theta - Verteilung initialisieren 2 cust $ a0 < cust $ b0 < # Weitere Modellparameter initialisieren 6 cust $ lambda <- array () 7 cust $ alpha <- 1 8 cust $ nu <- 1 9 cust $ gamma < cust$theta <- dinvgamma ( cust$a0, cust$b0, cust$gamma ) Es folgen die einzelnen Modellgleichungen, angefangen mit λ i [ALJ99, A.1], einem individuellen Skalierungsparameter für jeden Kunden. Aus π(λ i {t ij, j = 1,... n i }, n i, α, ν, γ) = IGG(n i α + ν, [ t γ ij + θ γ ] 1/γ, γ) (2.1) wird 1 cust. genlambda <- function () { 2 custcount <- length ( cust $ iptimes ) 3 for ( i in 1: custcount ) { 4 iptcount <- length ( cust $ iptimes [[ i]]) 5 cust $ lambda [ i] <- dinvgamma ( 6 iptcount * cust $ alpha + cust $nu, 7 sum( cust$iptimes [[i]] ^ cust$ gamma + 8 cust$theta ^(- cust$ gamma ) ) ^ (-1 / cust$gamma ), 9 cust $ gamma 10 ) 11 } 12 }

13 2 A Dynamic Model of Purchase Timing 7 Als nächstes wird der α-parameter [ALJ99, A.2] der Generalized-Gamma-Verteilung bestimmt: N n i γ π(α {λ i }, {t ij }, γ) Γ(α)λ αγ t αγ 1 ij e (t ij/λ i ) γ (2.2) i Dies wird in R-Code übersetzt zu i=1 j=1 1 cust. genalpha <- function () { 2 value <- 1 3 custcount <- length ( cust $ iptimes ) 4 for ( i in 1: custcount ) { 5 ipt <- cust$iptimes [[i]] 6 iptcount <- length ( ipt) 7 for ( j in 1: iptcount ) { 8 value <- value * ( 9 ( 10 cust $ gamma / 11 ( gamma ( cust$alpha ) * cust$lambda [i] ^ 12 ( cust$alpha * cust$gamma ) ) 13 )* 14 ipt[j] ^ ( cust$ alpha * cust$gamma - 1) * 15 exp( -(ipt[j] / cust$lambda [i]) ^ cust$ gamma ) 16 ) 17 } 18 } 19 cust $ alpha <- value 20 } Das heiÿt, es wird über alle Beobachtungen iteriert. Der ν-parameter [ALJ99, A.3] der IGG-verteilten Heterogenität wird ebenfalls iterativ über alle Kunden bestimmt: In R-Code: π(ν {λ i }, θ, γ) N i=1 γ λ νγ 1 Γ(ν)θνγ i e (1/θλ i) γ (2.3) 1 cust. gennu <- function () { 2 value <- 1 3 custcount <- length ( cust $ iptimes ) 4 for ( i in 1: custcount ) { 5 value <- value * 6 cust $ gamma / 7 ( gamma ( cust$nu) * cust$theta ^ ( cust$nu * cust$gamma ) ) * 8 9 cust$lambda [i] ^ (- cust$nu * cust$gamma - 1) *

14 2 A Dynamic Model of Purchase Timing 8 10 exp( -(1 / ( cust$theta * cust$lambda [i])) ^ cust$ gamma ) 11 } 12 cust $ nu <- value 13 } θ-parameter [ALJ99, A.4] für die Heterogenität: Nach R übersetzt: π(θ {λ i }, ν, γ) = IGG(Nν + a 0, [ λ γ i 1 cust. gentheta <- function () { 2 custcount <- length ( cust $ iptimes ) 3 cust $ theta <- dinvgamma ( 4 custcount * cust $ nu + cust $a0, 5 sum( ( cust$lambda + cust$b0) ^ -cust$ gamma ) ^ 6 (1 / cust$gamma ), 7 cust $ gamma 8 ) 9 } + b γ 0 ] 1/γ, γ) (2.4) Mit den oben dargestellten Gleichungen endet im Paper von Allenby et al. der für das Component-Mixture-Model direkt nachvollziehbare und in R-Code übersetzbare Teil. Die eigentlichen Analyseschritte, die Durchführung der MCMC-Algorithmen sind nur sehr knapp erläutert. In der für ein Seminar zur Verfügung stehenden Zeit war es nicht möglich, die oben genannten Methoden zur Anwendung zu bringen. Um mit den bereits zum groÿen Teil erläuterten R-Skript (das vollständige Skript ndet sich im Anhang A.1) eine weitergehende Analyse der Datensätze durchzuführen, ist eine noch intensivere Beschäftigung mit MCMC-Methoden erfoderlich. Es wird vorgeschlagen, für die MCMC-Analyse eine latente Zufallsvariable s ijk zu denieren, die die Beobachtung eines Geschäftsvorfalls des Kunden i zur j-ten Interpurchase-Time indiziert und damit die Einordnung der Beobachtung in einen der k Zustände ermöglicht (hier wie im erwähnten Paper gilt: k = 3). In jeder Iteration der MCMC-Analyse werden dann die bereits einer Komponente (=Zustand) zugeordneten Beobachtungen die berechneten Werte {λ ik }, a k, ν k und θ k erreichen. Für die Wahrscheinlichkeitsverteilung von s ijk ergibt sich somit: P r(s ijk = k ) φ k f(t ij α k, λ ik, γ k ) (2.5) Zusammen mit f(t ij α k, λ ik, γ k ) = φ k ( k φ ijk GG(α k, λ ik, γ k ) ) (2.6)

15 2 A Dynamic Model of Purchase Timing 9 ist eine Einordnung in einen Zustand möglich, da φ k durch φ ij = 1 Φ(β 01i ) (2.7) bestimmt ist. Als Nächstes sind in jeder Iteration des Algorithmus Ziehungen aus der im Paper denierten Random-Eects-Specication durchzuführen. Dies wird durch die Verwendung eines Metropolis-Hastings-Algorithmus mit einer Random-Walk-Chain erreicht. Die Funktionen aus dem Paket MCMCpack, insbesondere MCMCmixfactanal() sind einer genaueren Untersuchung in Hinblick auf den Einsatz bei der Nachstellung des Modells wert. 2.3 Probleme Bei der Ausführung des R-Skriptes (Formel ) stellte sich heraus, dass dieses keine verwertbaren Ergebnisse liefern. Zu Beginn der Berechnungen lieferte R als Ergebnisse NaN's (Not a number). Nach Korrektur einiger programmiertechnischer Fehler des Algorithmus hat veränderte sich das Ergebnis dahingehend, dass statt NaN nun 0 als Ausgabewerte geliefert wurden. In beiden Fällen brachte die Veränderung der Startparamenter keine besseren Werte. Diverse Startparameter wurden getestet, in vielen der möglichen Variationen. Auch eine Erhöhung der Durchlaufzahl des Skriptes brachte keine Besserung, die Ergebnisse veränderten sich weder bei einem Durchlauf noch bei mehreren hundert Durchläufen. Die Startparameter für α, ν und γ sind im Bereich von [0-2] variert worden, für a 0 im Bereich von [0-10] und für b 0 von [10-100]. Die Umsetzung des Modells aus dem Paper gestaltete sich schwieriger und vor allem zeitaufwändiger als erwartet. Viel Zeit gekostet hat insbesondere die Auswahl der geeigneten Arbeitsumgebung und die Erarbeitung der Grundlagen zu dem recht komplexen und überdies jungem Gebiet der verwendeten Statistik. Die Verwendung von R als Programmiersprache wurde seitens der Seminarbetreuer nahegelegt; auch hier mussten Syntax und Benutzung erst erlernt und erarbeitet werden. Zu Beginn des Seminars war kaum Zusatz-Literatur zum Seminarthema zu nden, und das Buch Bayesian Statistics and Marketing[RAM05] wurde erst im Laufe des Seminars veröentlicht, ebenso wie das R-Paket bayesm, mit dem die Autoren des Papers gearbeitet haben.

16 3 Fazit Angenehm sind die erledigten Arbeiten. (Cicero (106-43)) Leider hat das Seminar nicht den erhoten Erfolg gebracht. Auf den ersten Blick sah die Umsetzung des Papers von Allenby, Leone und Jen [ALJ99] einfacher aus als es letztendlich war. Der Vorteil an dem Verfahren von Allenby, Leone und Jen ist die deutlich gezieltere Kontaktierung bzw. Reaktivierung von Kunden, die im Begri sind, die Geschäftsbeziehungen zu einem Unternehmen zu lösen. Typischer Indikator für eine solche Absicht ist eine längere Zeit der Inaktivität, wobei nicht allgemein klar ist, wie genau längere Zeit zu denieren ist. Bei herkömmlichen Verfahren werden Kunden nach einer bestimmten xen Zeitspanne kontaktiert. Dabei werden jedoch die individuellen Interpurchase-Times der Kunden nicht berücksichtigt. Die komplexe Auswertung der Daten erfordert aktuelle Hardware die durchzuführenden Rechnungen sind nicht trivial, jedoch sind die Kosten für neue Hardware in groÿen Unternehmen vernachlässigbar. Zur Ezienz des Verfahrens bei groÿen Datensätzen sind leider keine eigenen Ergebnisse vorhanden. Ein gröÿeres Problem ist jedoch die Umsetzung des Verfahrens. Gute Kenntnisse in Statistik und das Vertrautsein mit MCMC-Methoden sind unerläÿlich. Dies macht es im Unternehmen erforderlich, auf externe Spezialisten zurück zu greifen. Die R-Pakete bayesm und insbesondere MCMCpack scheinen im Ansatz Hilfestellungen bei der Umsetzung zu enthalten. Die darin enthaltenen Funktionen müssen jedoch genau evaluiert und auf die eigene Problemstellung angepasst werden. Das Paket bayesm arbeitet laut Internetrecherche relativ ezient auch mit groÿen Datensätzen. Dies lässt die Vermutung zu, dass auch das Verfahren aus dem Paper ezient auf grosse Datensätze angewendet werden kann, so dass ein Einsatz im Unternehmen mit den oben erwähnten Einschränkungen empfehlenswert scheint.

17 Anhang A R-Skripte Listing A.1: R-Skript 1 # Benötigte Pakete einbinden 2 library (" RODBC ") 3 library (" MCMCpack ") 4 library (" bayesm ") 5 6 ## String Konkatenation, hängt zwei Zeichenketten aneinander. 7 # 8 x erster String 9 y zweiter String 10 zusammengesetzter String 11 "~" <- function (x, y) paste (x, y, sep = "") ## R- Umgebung für Datenbankverbindungen 14 # 15 db <- new.env () ## Stellt die Verbindung zur Datenbank her. 18 # 19 dbname Name der Datenbank 20 db. connect <- function ( dbname ) { 21 db $ channel <- odbcconnect ( dbname ) 22 } ## Setzt eine neue Standardtabelle, die von allen fetch - Funktionen 25 # ( fetchcustids, fetchcustiptimes, etc.) verwendet werden. 26 # 27 tablename Name der neuen Standardtabelle 28 db. defaulttable <- function ( tablename ) { 29 db $ defaulttable <- tablename 30 } ## Schlieÿt die Datenbankverbindung 33 # 34 db. close <- function () { 35 odbcclose ( db$ channel ) 36 } 37

18 Anhang A R-Skripte ## Führt eine Datenbankabfrage aus. 39 # 40 query SQL - Statement, dass ausgeführt werden soll 41 Ergebnis der Abfrage als Data Frame 42 db. query <- function ( query ) { 43 return ( sqlquery (db$channel, query )[,]) 44 } ## Gibt eine Liste mit Kundennummern zurück. 47 # 48 count maximale Anzahl von Kundennummern, die zurückgegeben 49 # werden sollen 50 Liste mit Kundennummern 51 db. fetchcustids <- function ( count = 10) { 52 query <- " SELECT DISTINCT KundeNr FROM " ~ db $ defaulttable ~ 53 " ORDER BY KundeNr ASC LIMIT " ~ count 54 return (db. query ( query )) 55 } ## Liefert eine Liste mit Interpurchase - Times zurück. 58 # 59 custids Liste mit Kundennummern, für die die IPTs zu 60 # berechnen sind 61 Liste von Listen mit Interpurchase - Times in derselben 62 # Reihenfolge wie die Kundennummern 63 db. fetchcustiptimes <- function ( custids ) { 64 iptimes = list () # Über alle Kunden iterieren 67 i < for ( cid in custids ) { 69 # Datum der einzelnen Käufe des Kunden holen 70 query <- " SELECT VKDatum FROM " ~ db $ defaulttable ~ 71 " WHERE KundeNr = " ~ cid ~ " ORDER BY VKDatum " 72 boughton <- db. query ( query ) # Nur ein einziges mal gekauft? => Nächster Kunde, keine 75 # sinnvolle Interpurchase Time 76 if ( length ( boughton ) == 1) 77 next # Interpurchase Times für Kunde ausrechnen 80 ipt <- array () 81 j < for (k in 2: length ( boughton )) { 83 diff <- round ( boughton [ k] - boughton [ k - 1]) 84 if ( diff!= 0) { 85 ipt[ j] <- diff 86 j <- j }

19 Anhang A R-Skripte } # Hat ein Kunde ausschlieÿlich einmal an einem Tag gekauft, 91 # gibt es ebenfalls keine sinnvolle Interpurchase Time 92 if (j == 1) 93 next iptimes [[i]] <- ipt 96 i <- i } return ( iptimes ) 100 } # Schritt 1: Generate lambda for each customer 103 cust. genlambda <- function () { 104 custcount <- length ( cust $ iptimes ) 105 for ( i in 1: custcount ) { 106 iptcount <- length ( cust $ iptimes [[ i]]) 107 cust $ lambda [ i] <- dinvgamma ( 108 iptcount * cust $ alpha + cust $nu, 109 sum( cust$iptimes [[i]] ^ cust$ gamma cust$theta ^(- cust$ gamma ) ) ^ (-1 / cust$gamma ), 111 cust $ gamma 112 ) 113 } 114 } # Schritt 2: Generate alpha over all observations 117 cust. genalpha <- function () { 118 value < custcount <- length ( cust $ iptimes ) 120 for ( i in 1: custcount ) { 121 ipt <- cust$iptimes [[i]] 122 iptcount <- length ( ipt) 123 for ( j in 1: iptcount ) { 124 value <- value * ( 125 ( 126 cust $ gamma / 127 ( gamma ( cust$alpha ) * cust$lambda [i] ^ 128 ( cust$alpha * cust$gamma ) ) 129 )* 130 ipt[ j] ^ ( cust $ alpha * cust $ gamma - 1) * 131 exp( -(ipt[j] / cust$lambda [i]) ^ cust$ gamma ) 132 ) 133 } 134 } 135 cust $ alpha <- value 136 } 137

20 Anhang A R-Skripte # Schritt 3: Generate nu over all customers 139 cust. gennu <- function () { 140 value < custcount <- length ( cust $ iptimes ) 142 for ( i in 1: custcount ) { 143 value <- value * 144 cust $ gamma / 145 ( gamma ( cust$nu) * cust$theta ^ ( cust$nu * cust$gamma ) ) * cust$lambda [i] ^ (- cust$nu * cust$gamma - 1) * 148 exp( -(1 / ( cust$theta * cust$lambda [i])) ^ cust$ gamma ) 149 } 150 cust $ nu <- value 151 } # Schritt 4: Generate theta over all customers 154 cust. gentheta <- function () { 155 custcount <- length ( cust $ iptimes ) 156 cust $ theta <- dinvgamma ( 157 custcount * cust $ nu + cust $a0, 158 sum( ( cust$lambda + cust$b0) ^ -cust$ gamma ) ^ 159 (1 / cust$gamma ), 160 cust $ gamma 161 ) 162 } # Datenbankverbindung herstellen 165 db. connect (" allenby ") 166 db. defaulttable (" retail ") # Neues Environment für Allenby - Modell erzeugen 169 cust <- new. env () # Erste 10 Kundennummern holen und Interpurchase - Times ausrechnen 172 ids <- db. fetchcustids (10) 173 cust $ iptimes <- db. fetchcustiptimes ( ids) # Werte für Theta - Verteilung initialisieren 176 cust $ a0 < cust $ b0 < # Weitere Modellparameter initialisieren 180 cust $ lambda <- array () 181 cust $ alpha < cust $ nu < cust $ gamma < cust$theta <- dinvgamma ( cust$a0, cust$b0, cust$gamma ) # Iterationsschritt durchführen 187 cust. genlambda ()

21 Anhang A R-Skripte cust. genalpha () 189 cust. gennu () 190 cust. gentheta () db. close () # Datenbankverbindung schlieÿen

22 Anhang B MySQL-Datenbanken Im Listing B.1 ist die Struktur der Retail-Datenbank abgebildet, im Listing B.2 die Stuktur des Airline-Datensatzes. Listing B.1: Retail-Datensatz: Datenbankstruktur Field Type Null Key Default Extra ID int (11) YES NULL 5 KundeNr int (11) YES NULL 6 umsgr varchar (40) YES NULL 7 ABCD_ FS2003 varchar (40) YES NULL 8 ABCD_ FS2004 varchar (40) YES NULL 9 KDStilgrbez varchar (40) YES NULL 10 Filbez varchar (40) YES NULL 11 Bez_ Shop varchar (40) YES NULL 12 Bez_ StatistikShop varchar (48) YES NULL 13 habteilungbez varchar (25) YES NULL 14 bez mediumtext YES NULL 15 Jahr int (11) YES NULL 16 Monat int (11) YES NULL 17 Tag int (11) YES NULL 18 VKDatum datetime YES NULL 19 Wochentag char (2) YES NULL 20 Saison varchar (5) YES NULL 21 VT double YES NULL 22 EKPreis double YES NULL 23 VKPreis double YES NULL 24 BruttoGewinn double YES NULL

23 Anhang B MySQL-Datenbanken 17 Listing B.2: Airline-Datensatz: Datenbankstruktur Field Type Null Key Default Extra ID int (11) YES NULL 5 FOCUS_ INT_ ID int (11) YES NULL 6 BIRTH_ DT varchar (255) YES NULL 7 CNTRY_ CD varchar (255) YES NULL 8 ADDRESS _ TYP varchar (255) YES NULL 9 GENDER int (11) YES NULL 10 MM_ STATUS varchar (255) YES NULL 11 ENROLLMENT _ MONTH int (11) YES NULL 12 ENROLLMENT _ TYP varchar (255) YES NULL 13 FIRST _ FLIGHT _ DT int (11) YES NULL 14 LAST_ FLIGHT _ DT int (11) YES NULL 15 LH_ WEBSITE varchar (255) YES NULL 16 duration double YES NULL 17 ALL_ 2001 Q1 int (11) YES NULL 18 ALL_ 2001 Q2 int (11) YES NULL 19 ALL_ 2002 Q2 int (11) YES NULL 20 ALL_ 2004 Q1 int (11) YES NULL 21 ALL_ 2002 Q1 int (11) YES NULL 22 ALL_ 2000 Q3 int (11) YES NULL 23 ALL_ 2002 Q3 int (11) YES NULL 24 ALL_ 2002 Q4 int (11) YES NULL 25 ALL_ 2003 Q1 int (11) YES NULL 26 ALL_ 2003 Q2 int (11) YES NULL 27 ALL_ 2003 Q3 int (11) YES NULL 28 ALL_ 2004 Q2 int (11) YES NULL 29 ALL_ 2004 Q3 int (11) YES NULL 30 ALL_ 2000 Q4 int (11) YES NULL 31 ALL_ 2000 Q2 int (11) YES NULL 32 ALL_ 2000 Q1 int (11) YES NULL 33 ALL_ 2001 Q3 int (11) YES NULL 34 ALL_ 2003 Q4 int (11) YES NULL 35 ALL_ 2004 Q4 int (11) YES NULL 36 ALL_ 2001 Q4 int (11) YES NULL 37 REVENUE _ 2002 Q2 int (11) YES NULL 38 REVENUE _ 2002 Q1 int (11) YES NULL 39 REVENUE _ 2002 Q3 int (11) YES NULL 40 REVENUE _ 2002 Q4 int (11) YES NULL 41 REVENUE _ 2003 Q1 int (11) YES NULL 42 REVENUE _ 2003 Q2 int (11) YES NULL 43 REVENUE _ 2003 Q3 int (11) YES NULL 44 REVENUE _ 2004 Q2 int (11) YES NULL 45 REVENUE _ 2004 Q3 int (11) YES NULL 46 REVENUE _ 2001 Q2 int (11) YES NULL 47 REVENUE _ 2000 Q4 int (11) YES NULL 48 REVENUE _ 2000 Q2 int (11) YES NULL 49 AKTIVE _ MONATE _ 1998 int (11) YES NULL

24 Anhang B MySQL-Datenbanken AKTIVE _ MONATE _ 1997 int (11) YES NULL 51 AKTIVE _ MONATE _ 2001 int (11) YES NULL 52 AKTIVE _ MONATE _ 2002 int (11) YES NULL 53 AKTIVE _ MONATE _ 2004 int (11) YES NULL 54 AKTIVE _ MONATE _ 1995 int (11) YES NULL 55 AKTIVE _ MONATE _ 1996 int (11) YES NULL 56 AKTIVE _ MONATE _ 1999 int (11) YES NULL 57 AKTIVE _ MONATE _ 2000 int (11) YES NULL 58 AKTIVE _ MONATE _ 2003 int (11) YES NULL