Ein knallharter Wettbewerb kennzeichnet den Parfümerie- und Kosmetik-Markt im Netz. Die Produkte sind zwischen den Händlern austauschbar. Viele Kunden wissen, was sie wollen, denn die Marken oder die Beauty-Influencerinnen bereiten den Marketing-Boden. Folglich geht es um die besseren Abverkaufs-Trigger, die ein Händler setzen kann, sei es beim Preis oder bei der passend ausgesprochenen Empfehlung. Und je besser sich beides an dem aktuellen Verhalten der User auf der Website orientieren kann, umso relevanter wird die Ausspielung sein.

Flaconi rüstet gerade auf. Die Berliner sind einer der größten Parfüm-Händler und bieten den Kunden 45.000 Produkte von 700 Marken an. Die Bilanz von Eigentümer ProSiebenSat.1 weist für 2018 ein Wachstum von 40 Prozent auf 134 Millionen Euro Jahresumsatz aus.

Martin Nguyen ist der Director Business Intelligence bei Flaconi. Er ist unzufrieden mit Reportings, die im Zehn-Minuten-Rhythmus ins System eingespielt und verarbeitet werden. Er will dem Kunden live auf die Pelle rücken, um dessen Kaufentscheidung bestmöglich zu unterstützen. Flaconis Partner bei diesem Ansinnen sind die Berliner Analytics-Spezialisten von Webtrekk. Deren Neuheit zur Dmexco heißt “Data Streams”.

ADZINE: Herr Nguyen, was sind Data Streams?

Martin Nguyen: Das sind eventgetriebene Datenströme, die zwischen unterschiedlichen Systemen fließen. Wir haben mit Apache Kafka eine eigene Infrastruktur dafür aufgebaut. Aber bisher fließen da begrenzt Analytics-Daten aus der Website hinein. Das ändern wir gerade mit den Webtrekk Data Streams.

ADZINE: Welche Daten kommen da?

Nguyen: Jede User-Interaktion auf der Website. Zukünftig werden auch Apps integriert, aber jetzt geht es um die Website. Das kann ein Klick sein, das kann ein Kauf sein, das kann auch einfach die Information sein, dass ein User ein bestimmtes Bild gesehen hat. Auch diese Daten wollen wir in Echtzeit verarbeiten.

Wenn man sich einer unserer Katalogseiten anschaut, erhält man 46 Seiten Produktauflistungen. Wir haben eine dynamische Sortierung der Produkte, also ist es schwer nachträglich nachzuvollziehen, was der einzelne User gesehen hat. Deswegen ist es für uns extrem wichtig, exakt zu tracken, wie der User auf welches Produkt reagiert hat.

ADZINE: Mussten die Seiten dafür angepasst werden oder ergibt sich das aus dem normalen Tracking-Tag?

Nguyen: Das ergibt sich komplett aus der Standard-Implementierung. Webtrekk hat uns ein Frontend gebaut, um die Rohdaten vorzustrukturieren, während die klassischen Analytics-Reports bereits strukturiert übergeben werden. Welche Daten wir aus den Streams in welcher Form nutzen wollen, müssen wir selbst definieren und umsetzen. Aber das macht ja auch Spaß.

ADZINE: Geht es eher um Datenqualität oder um mehr Geschwindigkeit?

Nguyen: Ganz klar Geschwindigkeit. Es gibt für mich zwei Bereiche an Use Cases. Zum einen die schnellere Reaktion auf bestimmte Events. Wir könnten jetzt theoretisch alle zehn Sekunden in alle Daten schauen. Das kann aber nicht das Ziel sein. Wir haben Events definiert, zu denen Reports ausgegeben werden, und auf dieser Grundlage treffen wir Entscheidungen. Real Time Alerting also.

Es kommt zum Beispiel vor, dass ein Influencer viel Traffic auf unsere Seite bringt. Das wissen wir nicht immer vorab, wenn es sich nicht um eine Kampagne handelt. Wir können dann kurzfristig die Preise justieren oder eine Landingpage dazwischen legen, die genau auf das Bezug nimmt, was der Influencer kommuniziert hat. Dadurch können wir die Entscheidungswege der Kunden verkürzen.

Der zweite Aspekt ist natürlich die Echtzeit-Personalisierung. Wenn wir zu lange brauchen, um auf das Verhalten des Nutzers zu reagieren, ist er vielleicht schon weg und kauft beim Wettbewerber. Das wird natürlich per Machine Learning passieren. Eine Unterscheidung zwischen Männern und Frauen kriegen wir jetzt schon in Echtzeit hin, aber wenn wir persönlich werden wollen, brauchen wir Live-Daten.

ADZINE: Was muss man strukturell verändern, wenn man im ersten Fall möglichst schnell reagieren will?

Nguyen: Das ist On-Call-Duty, wie man sie typischerweise aus der IT-Infrastruktur kennt. Wenn der Server abraucht, wird ein Verantwortlicher informiert – auch mitten in der Nacht – und der löst dann die Schritte aus, die es braucht, um das Problem zu beheben. Das haben wir jetzt auch für die Sales-Teams aufgebaut. Wenn der Alert nachts kommt, dann müssen die auch aufstehen. Dafür müssen die Alerts aber sitzen. Wenn man 20 Alerts am Tag bekommt und auf 19 nicht reagieren muss, dann reagiert man auf den Zwanzigsten auch nicht mehr. Man muss sehr klar vorher spezifizieren: Was ist der Use Case und wollen wir darauf in Echtzeit reagieren?

ADZINE: Das heißt, Sie haben im Vorfeld ein Set an Schwellenwerten definiert.

Nguyen: Genau. Das ist am Anfang eventuell noch etwas grob, wird aber mit der Erfahrung immer besser werden. Da geht es ja nicht nur um die Website selbst, sondern wenn wir zum Beispiel sehen, dass sich ein Produkt sehr schnell abverkauft, von dem wir nur noch eine begrenzte Stückzahl auf Lager haben, dann können wir mit dem Preis reagieren. Das kann man aber auch automatisieren. Und dabei geht es nicht nur um den höheren Ertrag, sondern vor allem auch darum, dass der Kunde auch in zwei Tagen noch Ware auf der Seite sieht und nicht enttäuscht wird.

ADZINE: Für das Bauen einer Landingpage braucht es ganze „Notfall-Teams“?

Nguyen: Ja. Wichtig ist, dass ein Verantwortlicher den Alert bekommt, also ein First-Level-Support, wenn man so will. Der entscheidet dann: Reagieren wir und was braucht es dafür? Natürlich versuchen wir auch die Reaktionen vorzudefinieren, damit man sich das nicht on the fly immer neu ausdenken muss. Manche Ereignisse sind aber so nicht vorhersehbar.

ADZINE: Welche technischen Anpassungen waren nötig, um mit den Daten arbeiten zu können?

Nguyen: Da sind wir in einer Prototyping-Phase. Intern nutzen wir Kafka über eigene Listener oder Kafka Connect, schieben die Daten in unser Data Warehouse weiter oder der Server verarbeitet sie direkt. Was die Analytics-Daten angeht, probieren wir das gerade aus. Bisher pushen wir die Daten in die S3 und greifen sie von dort ab. In 14 Tagen machen wir einen Hackathon, um die optimale Nutzung auszuloten.

ADZINE: Aber die Daten sind doch die gleichen wie vorher. Wo ist der Flaschenhals in der Infrastruktur?

Nguyen: Der Unterschied ist das Zusammenbringen einer starken fachlichen Konzeption und Strukturierung von Analytics-Rohdaten mit einer leistungsfähigen Infrastruktur. In den Produkten von Webtrekk stecken 16 Jahre Anforderungen und Erfahrungen drin. Das können und wollen wir hier so nicht nachbilden. Da bräuchte ich 16 Data Engineers und Analysten.

ADZINE: Jenseits der Data Streams – wo sehen Sie noch Optimierungsbedarf in Ihrer technischen Infrastruktur?

Nguyen: Bei uns sind die nächsten Schritte ganz klar: Wir wollen mehr Daten zu einem User in Echtzeit zusammenbringen, damit wir wirklich gut personalisieren können. Dazu zählt vor allem die Integration der Touchpoints in den Marketing-Kanälen. Das können wir heute in Echtzeit noch nicht abbilden.

Grundsätzlich betrachtet, fehlt es im Markt definitiv an der „Blaupause“, abseits der großen „one-stop-shop players“ Es gibt unendlich viele Lösungen und jeden Tag kommen neue hinzu. Wir bräuchten Referenz-Architekturen, zum Beispiel zu einem solchen Thema wie Data Streams. Wir brauchen da mehr Transparenz im Markt, Lösungs-agnostisch. Letztlich haben doch alle Onlinehändler einer bestimmten Größe die gleichen Herausforderungen.

ADZINE: Aber die großen, integrierten Anbieter versprechen doch seit Jahren vor allem mehr Beratung.

Nguyen: Ja. Haben wir probiert und aussortiert. Als wir nachgerechnet haben, waren die im Verhältnis zu den Kosten nicht gut genug. Transparenz hilft ja nicht, wenn die Leistung am Ende schlechter ist. Kleine Best-of-Bread-Lösungen haben den deutlich besseren ROI und es schadet nicht, das notwendige zusätzliche Know-how inhouse aufzubauen. Denn auch die Berater haben nur historisches Wissen aus den Vorprojekten und nach drei Monaten ist das veraltet.

ADZINE: Herr Nguyen, vielen Dank für dieses Gespräch.