Digital SolutionsMarketingSoftware

Website- und Trackingdaten – effiziente Verarbeitung von Daten

Durch die seit 2018 geltende Datenschutzgrundverordnung wird die personenbezogene Sammlung und Speicherung von Daten erschwert. Hierzu gehören auch zum Teil die Website- und Trackingdaten. Umso wichtiger ist es, die vorhandenen Daten optimal zu nutzen.

Franziska Müller und Werner Hunger sind Data Analysts bei Key-Work und haben schon viele Projekte im Bereich Website-Tracking erfolgreich zu Ende geführt. Sie beleuchten das Thema Webtracking unter dem technischen Gesichtspunkt.

Welche Website- und Trackingdaten gibt es und wie kann man sie nutzen?

Website- und App-Daten können die verschiedensten Ereignisse umfassen. Sie beschreiben Bestellvorgänge, Suchverhalten und das Surfverhalten von Besuchern auf der eigenen Website. Es lässt sich auswerten, wie viel Zeit der Besucher auf der Website verbringt und welche Unterseiten er besucht. Klicks, zum Beispiel auf Produkte oder auch Informationen wie Mausbewegungen, werden mitgeschrieben sowie gespeichert. Durch das Platzieren von Cookies werden wiederkehrende Nutzer – und auch User fremder Seiten – identifiziert.

Typische Anforderungen an die Website-Daten sind

• Beschreibung des Nutzerverhaltens, wie die Anzahl der Besuche eines Users vor dem Kauf
• Optimierung des Nutzererlebens, wie die Verbesserung des Bestellvorgangs, der Suchfunktion etc.
• Zusammenführen von Nutzerdaten über verschiedene Geräte hinweg
• Segmentierungen anhand des Nutzungsverhaltens für Dynamic Pricing oder Vorschlagsfunktionen
• Aufspüren von Betrugsfällen

Aber auch das Verhalten außerhalb der eigenen Website lässt sich beobachten. Zum Beispiel ist es interessant zu wissen, von welcher Website User auf die eigene Seite kommen oder welche anderen Seiten er besucht. Für die verschiedenen Nutzergruppen ist auf Basis dieser Informationen der Inhalt der Website angepasst. Zudem lässt sich das Werbebudget besser steuern.

Herausforderungen im Umgang mit Website-und Trackingdaten

Wer mit Website- oder App-Daten arbeiten möchte, steht gleich vor mehreren Herausforderungen.

Zunächst kann die Menge der Daten beachtlich sein. Je nach Anzahl der Nutzer und gesammelten Informationen können Größenordnungen von 10.000 Ereignissen pro Minute anfallen. Diese lassen sich nicht mehr ohne weiteres von Hand sichten und analysieren und auch nicht einfach in Excel geöffnet.

Eine weitere Herausforderung ist, dass Website- und Tracking-Daten semi-strukturiert sind. Das bedeutet, dass ein Datensatz je nach Kontext verschiedene Ereignisse abbilden kann, je nachdem in welchem Kontext der Website er entstanden ist. Er kann Käufe mehrerer Produkte, den Besitz einer Kundenkarte, die Nutzung eines Mobilgeräts und vieles mehr beschreiben. Und auch das Gegenteil ist möglich. Viele Datensätze beschreiben zusammen ein einziges Ereignis, wie der Vergleich mehrerer Produkte zu einem einzigen Kaufvorgang. Auch wenn die Daten in tabellarischer Form vorliegen, müssen die Daten zur Nutzbarmachung modelliert werden.

Zur Illustration betrachten wir die Daten einer Anfrage für eine Zugfahrt vom Berliner Hauptbahnhof nach München auf der Website der Deutschen Bahn:

Diese Daten, die der Browser an die Website sendet, können vom Nutzer ausgelesen werden. Bei dieser Anfrage ist auch die Speicherung der anderen eingegebenen Informationen denkbar. Dazu gehört beispielsweise der Zeitpunkt der Anfrage, der Zeitpunkt der Abreise bzw. Ankunft, die Auswahl der Felder „Bahncard“, „Schnellste Verbindung“ oder „Nur Nahverkehr“ sowie die Anzahl der Reisenden. Diese und ähnliche Daten sind zunächst zur Abwicklung des Ticketkaufs relevant. Je nach Art der Daten und Speicherung (allerdings nur mit Zustimmung) sind diese auch für die statistischen Auswertung des Nutzungsverhaltens relevant.

Schema-on-read – Data Warehouse versus dynamische Feature-Erzeugung

Für Betrachtungen zur Beantwortung der Eingangsfragen, müssen die Daten aufbereitet und zugänglich gemacht werden.

So kann eine große Menge an Daten wie zum Beispiel Website- und App-Daten, die in tabellarischer Form vorliegen, in ein Data Warehouse gelegt werden. Ist die Tabelle jedoch erst einmal in einer Datenbank eingebunden, sind Änderungen an den Strukturen im Nachhinein schwierig. Es entstehen Abhängigkeiten, die Speicherplatz, Zeit und Aufmerksamkeit brauchen. Der Netzwerkeffekt lässt diesen Aufwand sehr schnell ansteigen, die Tabelle ist Teil der Infrastruktur geworden. Um eine Datenanalyse zu ermöglich, müssen Daten strukturiert vorliegen. Dafür müssen die Daten aber analysiert werden. Ein möglicher Weg, diesem Konflikt zu entgehen, ist es, so lange wie möglich auf die Speicherung in festen Strukturen zu verzichten und ein „virtuelles Datenmodell“ zu erstellen.

Ansätze, die das Speichern von strukturierten Zwischenergebnissen vermeiden, werden oft als „Schema-On-Read“ bezeichnet.

Wenn es gelingt, mit einem veränderbaren, verständlichen Programm die Rohdaten in die gewünschte strukturierte Form zu bringen, bleibt die größtmögliche Beweglichkeit bei der Analyse erhalten. Nicht die Daten selbst, sondern nur das Programm wird angepasst. Konkurrierende Versionen lassen sich nach Belieben erstellen und ihre Ergebnisse verglichen. Der Zyklus „Analyse – Diskussion – Verfeinerung“ kann viele Male am Tag durchlaufen werden. Es wird ohne weiteres mit kleinen Samples gearbeitet, ohne Konsistenz einzubüßen. Über eine Versionsverwaltung lassen sich mehrere Ansätze parallel ausprobieren.

√ Es ist jederzeit möglich, zentrale Definitionen zu ändern und zu verbessern, ohne Konsistenz zu verlieren.
√ Es entsteht kein Informationsverlust durch frühe „säubernde Umformung“ von Daten.

Dataflow-Ansatz – Die Daten zum Fließen bringen

Zur Schema-On-Read-Verarbeitung gehört meist eine Technik, die es erlaubt, die Parallelität heutiger Maschinen und Maschinencluster zu nutzen. Ohne sich zu sehr um die Technik zu kümmern kann man sich stattdessen auf die inhaltliche Arbeit an der Umformung zu konzentrieren.

Die Idee ist, zu einer Zeit alle Daten eines Users im Speicher zusammenzuführen, daraus alle Entitäten und Ereignisse zu extrahieren sowie zu verknüpfen. Zusätzlich mit Eigenschaften und berechneten Kennwerten zu versehen, zu aggregieren und in Relation zueinander zu bringen. Daten, zum Beispiel Website und App-Daten, die man im Endergebnis festhalten möchte, werden kontinuierlich geschrieben. Zwischenergebnisse und alles andere wird sofort verworfen. Der Speicher ist frei für die Berechnungen zum nächsten User.

Die aufgezählten Schritte einer Datenanalyse sind auch beim klassischen Ansatz nötig, bauen dort aber fest aufeinander auf. Änderungen in einem frühen Verarbeitungsschritt ziehen alle folgenden Verarbeitungen erneut nach sich. Die Ergebnisse der Teilschritte müssen festgehalten werden, deshalb entsteht nicht nur hoher Zeitaufwand, sondern auch hoher Platzbedarf.

Damit die Berechnung im Kontext eines Users tatsächlich funktioniert, müssen die Daten „fließen“. Alle Daten, die in der Verwendung sind, sind so zusammengeführt, dass es zu einem ununterbrochenen Zufluss in den Rechenprozess kommt. Das gelingt zum Beispiel, indem alle Teildatensätze nach Userschlüssel sortiert gehalten, und diese in einem „Reißverschlussverfahren“ zusammengefügt werden. Die Lokalität der Daten, die so entsteht, begünstigt vieles. Datenkopien werden häufiger vermieden und das hilft Prozessoren, ihre volle Rechenkraft zu entfalten.

Durch diesen Dataflow-Ansatz entsteht ein „Fluss“ von Daten, mit wenigen „Verwirbelungen“, die aus dem wiederholten Beschaffen und Verwerfen von notwendigen Daten entstehen würden.

√ Die Parallelität beim Filtern, Zusammenführen und Aggregieren wird bequem nutzbar.
√ Die zusammengeführten Daten lassen Verknüpfungen zu, an die man vorher nicht dachte.

– Die Freiheit im Programmiermodell erlaubt sehr mächtige Transformationen, birgt aber gleichzeitig alle Fallstricke des Programmierhandwerks.
– Es ist keine weit verbreitete Technik mit Ökosystem, und für reine BI-Anwender ist nur das Endergebnis zugänglich

Praxis – Ressourcenschonende Kombination

Durch den Schema-on-Read- und Dataflow-Ansatz ist auf einer einzelnen Maschine eine Datenmenge verarbeitbar, für die sonst ein Speicher- und Rechencluster erforderlich ist.

Durch die Kombination des Schema-on-Read- und Dataflow-Ansatzes eröffnet sich bezüglich der verarbeitbaren Datenmenge pro Rechner ein Spielfeld, das beim Einsatz von Clustertechnik aus Kostengründen nicht zugänglich oder nicht wirtschaftlich wäre. Es lässt sich leicht mit Zwischenergebnissen rechnen, die in Summe Terabytes verschlingen würden, wenn man sie speichern müsste.

Für einfache Attribute lässt sich eine deklarative Programmiersprache nutzen, wie zum Beispiel SQL. Um Ereignisse in eine Beziehung zu setzen und Attribute zu bilden, ist es einfacher, eine allgemeine oder imperative Programmiersprache zu verwenden. Auch Verallgemeinerung, Wiederverwendung und abgegrenzte Lösung von Teilproblemen sind einfacher bzw. überhaupt erreichbar. Die kognitive Last ist geringer.

Wir nutzen die Technik z.B. für ems Touchpoint, um täglich Attribute für einige 100 Millionen Touchpoints zu aktualisieren, die dann für Analyse und Modellierung bereitstehen.

Wir unterstützen Sie!

Auf der Suche nach einem umsetzungsstarken technischen Partner oder auch Inspirationsgeber für die Anwendung von Website- und Trackingdaten? Wir begleiten Sie von der Use Case Definition bis zur Umsetzung. Wollen Sie mehr erfahren – sprechen Sie uns gerne an.