Begriffe wie Cus­to­mer Expe­ri­ence, Omnich­an­nel Manage­ment, Cus­to­mer Jour­ney, Cus­to­mer Ana­ly­tics, Per­so­na­li­sie­rung und kon­text­ba­sierte Kun­den­in­ter­ak­tio­nen ste­hen bei vie­len Unter­neh­men ganz oben auf der Agenda. Für das Aus­spie­len von per­so­na­li­sier­tem Con­tent in Echt­zeit über digi­tale Kanäle (z.B. zur Stei­ge­rung der Con­ver­sion-Rate) wer­den aktu­elle Daten über den Inter­es­sen­ten bzw. Kun­den benö­tigt. Dazu gehö­ren z.B. demo­gra­phi­sche Daten, die bis­he­rige Kon­takt­his­to­rie wie z.B. gekaufte Pro­dukte, Zah­lungs­ver­hal­ten, his­to­ri­sches Surf­ver­hal­ten, etc.

Häu­fig ver­fügt das Unter­neh­men noch nicht über eine der­ar­tige Daten­ba­sis oder die Daten sind über ver­schie­dene Sys­teme ver­teilt. Des­halb ist für viele Unter­neh­men der ideale Ein­stieg in ein Omnich­an­nel-Manage­ment, die Web­logs, die auf den Web­sei­ten, Kun­den- und Ser­vice-Por­ta­len sowie Apps. erzeugt wer­den, zeit­nah zu sam­meln, zu ver­ar­bei­ten und zu ana­ly­sie­ren. Oft haben Unter­neh­men Web-Ana­ly­tics mit Pro­duk­ten wie Google-Ana­ly­tics oder Adobe-Ana­ly­tics bereits imple­men­tiert. Aller­dings ste­hen diese Click­stream-Daten erst mit einem Zeit­ver­zug von 24 bis 48 Stun­den zur Ver­fü­gung und die Kos­ten sind nicht unerheblich.

Wenn das Unter­neh­men den­noch die Click­stream-Daten in Echt­zeit benö­tigt, kann es z.B. neben Adobe Ana­ly­tics die wei­te­ren kos­ten­pflich­ti­gen Pro­dukte der Adobe Mar­ke­ting Cloud nut­zen oder pro­prie­täre Click­stream-Coll­ec­to­ren ein­set­zen oder voll­stän­dig auf Open­so­urce-Pro­dukte set­zen. Wir möch­ten Ihnen aus einem Pro­jekt berich­ten, bei dem wir den Open­so­urce Click­stream Coll­ec­tor Divolte ein­ge­setzt haben.

Divolte war nicht der erste Coll­ec­tor, der bei dem Kun­den imple­men­tiert wurde. Er hatte bereits meh­rere Click­stream-Coll­ec­to­ren von ver­schie­de­nen Anbie­tern ein­ge­setzt. Aber auf­grund der posi­ti­ven Erfah­rung mit Divolte ent­schied der Kunde, die­ses Pro­dukt zukünf­tig als allei­nige Lösung zu nut­zen und die übri­gen Pro­dukte suk­zes­sive zu erset­zen. er große Vor­teil von Divolte liegt in sei­ner Offen­heit und Anpass­bar­keit, so las­sen sich Akti­vi­tä­ten indi­vi­du­ell und exakt taggen. 

Damit grenzt sich Divolte von ver­gleich­ba­ren Pro­duk­ten ab. So las­sen sich nicht nur Page Views iden­ti­fi­zie­ren, son­dern auch andere Akti­vi­tä­ten auf digi­ta­len Kanä­len tra­cken wie: Down­load eines Files; Laden von Ajax, Java­Script oder Flash Con­tent; Aus­le­sen von For­mu­lar­ein­trä­gen; Laden von Videos auf einer Web­site; Drü­cken des Start‑, Pause- und Stopp-But­tons bei Videos; Laden einer dyna­mi­schen Web­seite; Inter­ak­tion mit einem Gad­get; Click auf ein Bild oder einen exter­nen Link; Log-ins; Tei­len oder Dru­cken eines Blog Post, Arti­kels, Video oder Bild; Click eines But­tons oder eine Mouse-Bewe­gung. Letzt­end­lich las­sen sich so Mouse‑, Tas­ta­tur, Frame und Form-Events tracken. 

Show-Case für Cus­to­mer Jour­ney Ana­ly­tics und Echtzeit-Personalisierung

Mit dem Show-Case soll das fol­gende Sze­na­rio umge­setzt wer­den: Das Surf­ver­hal­ten auf einer Web­site wird über den Divolte Click­stream Coll­ec­tor in Echt­zeit per Kafka in die AWS-Cloud. In Spark Strea­ming wer­den die Daten aus Kafka ana­ly­siert und danach in HBase gespei­chert. Auf diese Weise las­sen sich dann in Echt­zeit z.B. Noti­fi­ca­ti­ons an die Web­seite ver­sen­den oder dyna­mi­sche Web­sei­ten mit per­so­na­li­sier­tem Con­tent erzeugen.

Im fol­gen­den Schau­bild wird die Archi­tek­tur der Kom­po­nen­ten Divolte Coll­ec­tor und Kafka Clus­ter ver­an­schau­licht. Wenn der Nut­zer auf der Web­site surft, wer­den in Echt­zeit Daten vom Divolte Coll­ec­tor gesam­melt und wei­ter an das Kafka Clus­ter gesen­det. Von dort aus kön­nen diese von einer Strea­ming-Engine wei­ter­ver­ar­bei­tet und per­sis­tiert wer­den. Mehr dazu im zwei­ten Teil die­ser Blog-Serie.

Beschrei­bung der System-Komponenten:

Im Fol­gen­den wer­den die für unse­ren Show Case ver­wen­de­ten Sys­tem­kom­po­nen­ten (AWS-Cloud) beschrieben.

1. Instal­la­tion von Divolte

Divolte wurde als Source Code von der Pro­jekt­seite auf Git­hub gela­den und anschlie­ßend per Gradle kom­pi­liert bzw. einen Build erstellt.

$ wget https://github.com/divolte/divolte-collector/archive/divolte-collector-0.6.0.zip
$ unzip divolte-*.zip
$ cd divolte-collector-divolte-collector-0.6.0
$ vi build.gradle
$ ./gradlew

Danach sind im Ord­ner „dist” ver­schie­dene Packa­ges des fer­tig kom­pi­lier­ten Tools enthalten.

Für das Tes­ten von Divolte kann eine leere Kon­fi­gu­ra­tion im Ord­ner „conf“ ange­legt werden.

$ touch conf/divolte-collector.conf

Wenn danach der Ser­ver gestar­tet wird, wer­den die Dateien nicht in das HDFS son­dern in den /tmp Ord­ner auf dem loka­len File­sys­tem geschrie­ben. Dies ist die Default-Ein­stel­lung bei lee­rer Kon­fi­gu­ra­tion.
Nun kann der Divolte-Coll­ec­tor für einen ers­ten Test gestar­tet werden.

$ ./vin/divolte-collector

Dadurch wird ein ein­fa­cher Web­ser­ver gestar­tet, der eine Test Web­site ent­hält mit der Click Events simu­liert wer­den kön­nen. Diese ist unter http://<divolte-server-adresse>:8290 im Web­brow­ser erreich­bar. Nach­dem man dort ein paar Mal geklickt hat, kann man seine Test­da­teien als .avro Dateien im Ord­ner /tmp finden.

Beim Kom­pi­lie­ren von Divolte wer­den auto­ma­tisch auch die Avro Tools mit kom­pi­liert. Diese sind ein klei­nes Java Pro­jekt, das viele nütz­li­che Funk­tio­na­li­tä­ten im Umgang mit Avro Dateien lie­fert.
Die Avro Dateien, die in /tmp abge­legt wur­den, kön­nen nun mit den avro-tools inspi­ziert werden.

$ ./bin/avro-tools tojson /tmp/*avro --pretty

2. Kafka

Zur Ver­ar­bei­tung der Daten wurde ein Kafka-Clus­ter auf­ge­setzt, das aus 3 Kno­ten besteht. Mit der Leis­tung die­ses Clus­ters könn­ten meh­rere Tau­send Events pro Sekunde ver­ar­bei­tet wer­den. In die­sem Setup sollte Kafka aller­dings nicht nur zur Ver­ar­bei­tung der Click­streams, son­dern auch für wei­tere Real­time Pro­zesse ein­ge­setzt werden.

Um Kafka sepa­rat von Hadoop auf­zu­set­zen, wer­den auf allen Kno­ten Zoo­kee­per und Kafka benö­tigt. Falls bereits ein Zoo­kee­per Quo­rum vor­han­den ist, kann auch die­ses genutzt wer­den. Da bereits eine bestehende Instal­la­tion der HDP (Hor­ton­works Data Plat­form) bestand, wurde die Instal­la­tion in die­sem Fall über Ambari durch­ge­führt. Über Ambari konnte das Kafka-Clus­ter danach kon­fi­gu­riert wer­den. Wich­tig ist für Divolte eine Kafka-Ver­sion > 0.10.0. In die­sem Bei­spiel wurde Kafka 0.10.2 verwendet.

Zusätz­lich musste Divolte kon­fi­gu­riert wer­den um die Click­da­ten als Mes­sa­ges an Kafka zu schi­cken. Eine mini­male Kon­fi­gu­ra­tion kann fol­gen­der­ma­ßen in der Datei conf/divolte-collector.conf ange­legt werden:

divolte {
    golbal {
        kafka {
            // Enable Kafka
            enabled = true
            threads = 2
            producer = {
                bootstrap.servers = ["kafka-broker-1:9092",
                                     "kafka-broker-2:9092",
                                     "kafka-broker-3:9092"]
            }
        }
    }
    sinks {
        kafka {
            type = kafka
            type = clickstream-data
        }
    }
}

Diese Kon­fi­gu­ra­tion sorgt dafür, dass Divolte das Kafka Plugin akti­viert, dass für das Schrei­ben in Kafka zwei Threads ver­wen­det wer­den und dass die Kafka-Ser­ver bekannt sind.
Zusätz­lich wird der Name der Topic fest­ge­legt, in die geschrie­ben wird. Diese Topic sollte vor­her bereits in Kafka mit der rich­ti­gen Kon­fi­gu­ra­tion für die Anzahl an Par­ti­tio­nen und Repli­ka­tio­nen ange­legt wer­den. In die­sem Fall wur­den dafür die Kafka Scripts genutzt, die nach der Instal­la­tion von Kafka im …/kafka/bin/ Ver­zeich­nis vorliegen:

$ ./kafka-topics.sh --create \
  --topic clickstream-data \
  --zookeeper zookeeper-host:2181 \
  --partitions 3 \
  --replication-factor 3

Im nächs­ten Teil des Blogs wird u.a. der Ein­satz von HBase mit Apa­che Phoe­nix und Spark Strea­ming beschrie­ben, um die in Echt­zeit gene­rier­ten Daten zu ver­ar­bei­ten und hin­ter­her per­so­na­li­sierte Ereig­nisse aus­lö­sen zu können.