Data Collection und Management mit Snowplow
Datenschutzrechtliche Regulierungen erschweren zunehmend die qualitative Erhebung und Auswertung verhaltensbasierter Webdaten durch Tools bekannter Analytics-Anbieter. Snowplow bietet mit seiner Open Source Data Collection Platform viele Funktionen für die Kontrolle und Individualisierung der Datengenerierung und -verarbeitung.
In diesem Blogbeitrag stellen wir den Funktionsumfang sowie den technischen Aufbau der Snowplow Data Collection Platform (Open Source) vor und zeigen anhand einer Beispiel-Integration in der Google Cloud Platform Komponenten und technische Besonderheiten der Pipeline auf.
1. Über Snowplow Analytics
Die Open Source Data Collection Platform besteht im Kern aus einer Data Processing Pipeline, welche sämtliche Daten erfasst, validiert, anreichert und speichert, die durch Requests an einen HTTP-Endpunkt gesendet werden. Snowplow kann sowohl in der Cloud-Umgebung der Google Cloud Platform (GCP) als auch in der Amazon Web Services (AWS) Cloud von Amazon betrieben werden.
Grundlegend lässt sich über das Tracker- und Collector-Prinzip eine breite Palette an Daten über Snowplow erheben, doch liegt die Kernkompetenz der Plattform in der Erhebung, der Weiterverarbeitung und dem Monitoring der Datenqualität verhaltensbasierter Webdaten und weniger in deren Analyse. Für einen optimalen Einstieg soll das folgende Kapitel zunächst eine generelle Übersicht über die beiden Produkte der Snowplow Data Collection Platform und ihre Funktionalitäten bieten.
1.1 Produkte
Snowplow Analytics bietet die Funktionalitäten seiner Data Collection Platform in zwei verschiedenen Formaten an. Alle Kernkomponenten der Plattform können über Snowplow Open Source kostenlos genutzt werden. Die Erstellung, das Hosting und die Wartung der Daten-Pipeline liegen allerdings vollständig in der eigenen Hand. Zusätzlich stellt Snowplow mit seiner Behavioral Data Platform eine “Out of the Box”-Lösung mit einer eigenen Service- und Pricing-Struktur zur Verfügung.
1.1.1 Snowplow Open Source
Die Open Source-Lösung von Snowplow gewährleistet vollständige Flexibilität und Individualisierbarkeit, im gleichen Zuge jedoch auch vollständige Verantwortung für die Wartung und Instandhaltung der eigenen Data Pipeline. Der Fokus der Lösung liegt verstärkt auf dem Data Sourcing und Data Modeling für die entsprechenden Zielsysteme. Hierfür stellt Snowplow mit der Iglu-Technologie ein eigenes Schema-Design bereit. Iglu ist ein maschinenlesbares Schema-Register für JSON-Formate und das Herz von Snowplow. Über das Schema wird definiert, welche Events in der Snowplow Pipeline prozessiert werden dürfen.
Das vordefinierte JSON-Schema wird auf den sog. Iglu-Server (Objektspeicher) geladen, welcher im Grunde genommen einen Speicher an Schema-Versionen darstellt, die für die Data Pipeline erstellt wurden. Die Schema-Version spielt im Tracking eine besondere Rolle, da sie im Tracking Code definiert werden muss, um die Rahmenbedingungen für die Event-Qualität festzulegen und anschließend validiert werden zu können. Es erfolgt somit ein gegenseitiger Abgleich zwischen Iglu-Server und Tracking Framework zur Gewährleistung einer maximalen Datenqualität.
1.1.2 Snowplow Behavioral Data Platform
Die Snowplow Behavioral Data Platform (BDP) ist eine kostenpflichtige Interface-Lösung von Snowplow, basierend auf dem technischen Backbone der Snowplow Open Source-Infrastruktur. Über die Behavioral Data Console lassen sich Daten aus den Pipelines über ein Interface oder die API auf console.snowplowanalytics.com verwalten, monitoren und konfigurieren.
Abbildung 1: Snowplow-Produkte und Komponenten
Snowplow übernimmt die Verantwortung für die Einrichtung, Wartung und Instandhaltung der Snowplow Pipelines und der damit verbundenen Infrastruktur. Über das Snowplow BPAInterface können Änderungen an der Pipeline-Konfiguration u.a. in einer Entwicklungsumgebung getestet werden, bevor diese in die Produktion übernommen werden. Die Kernelemente der Data Creation Pipelines von Snowplow sind überwiegend Open Source und der Code ist auf GitHub unter der Apache-2-Lizenz verfügbar. Schlüsselelemente des Snowplow BDP-Technologie-Stacks, einschließlich Benutzeroberfläche und API, sind dabei geschützt.
Alle mit Snowplow BDP verarbeiteten und gesammelten Daten werden innerhalb der eigenen Cloud-Infrastruktur durchgeführt. Die Datenerhebung, -verarbeitung und -speicherung sowie die Zugriffsrechte auf die Daten liegen in eigener Verantwortung. Allen Snowplow BDP-Kunden wird bei der Anmeldung zu Snowplow BDP ein „Kickstarter-Programm“ angeboten, um die Grundlagen der Pipeline sowie einen oder mehrere spezifische Anwendungsfälle des Kunden umzusetzen. Zusätzlich steht jedem Kunden ein eigener Account Manager zur Verfügung sowie vierteljährliche Infrastruktur-Reviews, die vom Snowplow Technical Operations Team durchgeführt werden. Dieses überprüft die Kunden-Infrastruktur und gibt Empfehlungen in Bezug auf Sicherheit, funktionale Verbesserungen, Leistungssteigerung, Zuverlässigkeit und Kostenoptimierung.
1.2 Funktionsumfang, Pipelines und SLA
Snowplow bietet für seine Behavioral Data Platform (BDP) unterschiedliche Funktionen und Services an, die den Funktionsumfang der Open Source Data Platform kostenpflichtig erweitern. Zusätzlich stehen diverse Arten von Pipelines für den Aufbau des Data Collection-Prozesses zur Verfügung. Um ein besseres Verständnis für die Services der BPA zu erlangen, sollen die folgenden Schaubilder das Portfolio an Services und Funktionen der unterschiedlichen Data Pipelines der Snowplow Data Collection Platform verdeutlichen und diese der Open Source-Variante gegenüberstellen.
Abbildung 2: Produktvergleich Snowplow OS vs. BDP
Abbildung 3: Produktvergleich Snowplow Data Pipelines
1.3 Unterschiede zu gängigen Analytics Tools
Einer der prägnantesten Unterschiede zu Analytics Tools wie Google Analytics 4 (GA4) oder Adobe Analytics ist, dass Snowplow im Kern kein Analytics Tool ist, sondern eine Data Creation und Collection Platform. Snowplow sieht sich selbst als “developer-first engine”, welche die komplette technische Infrastruktur über den Erhebungs- und Verarbeitungsprozess von verhaltensbasierten Daten erstellt und verwaltet. An sich konzipiert und managt die Plattform somit grundlegende ETL-Prozesse und bietet weniger Funktionen zur Analyse und Aktivierung der Daten. Folgende Charakteristika zeichnen Snowplow aus:
Open Source
Der Code der Plattform ist Open Source. Das bedeutet, dass vollständige Transparenz über den Aufbau und die Abläufe in der Pipeline besteht. Dies bietet maximale Flexibilität in Bezug auf Anpassungen und Erweiterungen der Lösung. Auf der anderen Seite bietet dies auch Raum für die Entstehung von Komplexität, da ein gewisser Grad an technischem Verständnis vorhanden sein muss, um mit der Plattform zu arbeiten und diese zu warten.
Data Ownership
Es besteht die vollständige Kontrolle darüber, wie Daten erfasst, prozessiert und gespeichert werden. Parameter (Enrichments) können einfach geändert und angepasst werden, was das Setup hochgradig konfigurierbar macht. Dies stellt einen signifikanten Unterschied zu Tools wie Google Analytics 4 dar, welche die DatenInfrastruktur und das Data Management selbst verwalten. Die Handhabe bei GA4 mag bequem sein, lässt aber die Daten in eine Art Blackbox einlaufen, in der Kontrolle über die Abläufe sowie das Verständnis darüber fehlt, wie Daten verarbeitet werden. Lediglich die Dokumentation bietet Anhaltspunkte über die Art und Weise der Datenverarbeitung.
Transparenz und Data Quality (Good and Bad Event Pipelines)
In der Good Event Pipeline werden Daten nach einem vordefinierten Schema erhoben und verarbeitet. Sobald Events nicht diesem Schema entsprechen, landen sie in der Bad Pipeline. In Analysetools wie Google Analytics werden Events, die dem gewünschten Format des Servers nicht entsprechen, stillschweigend abgelehnt, ohne dass das Tool den Nutzer darüber informiert. Durch den Bad Event Stream in Snowplow können somit auch Events, die dem Schema-Design nicht entsprechen, analysiert werden, was volle Transparenz über die Datenqualität ermöglicht.
Schema-Design
Google Analytics bietet volle Flexibilität in der Konfiguration von Events, wodurch das Risiko für schlechtere Datenqualität steigt. Zwar bestehen verpflichtende Event-Parameter, die in einem Request enthalten sein müssen, jedoch wird der Event Payload grundsätzlich ohne weitere Prüfung vom Server entgegengenommen. In Snowplow wiederum wird ein Schema erstellt, welches die Events erfüllen müssen, damit sie verarbeitet werden. Jeder Request wird demnach gegen ein festes Schema validiert, bevor die Pipeline in das gewünschte Zielsystem passiert.
2. Technischer Aufbau und Komponenten der Snowplow Open Source Data Pipeline
Der technische Aufbau der Snowplow Open Source Data Pipeline lässt sich in zwei übergeordnete Schritte unterteilen. Der erste Schritt umfasst die Einrichtung eines eigenen Servers (Iglu), der das Event-Schema verwaltet und validiert. Dieser dient als eine Art Gatekeeper für die Gewährleistung der Datenqualität. Im zweiten Schritt folgt der Prozess für den Aufbau der Data Collection Pipeline, welcher wiederum in weitere Teilschritte untergliedert ist und mehrere Komponenten enthält. Zur Veranschaulichung werden im folgenden Kapitel der Aufbau und die einzelnen Komponenten der Pipeline im Detail vorgestellt.
Abbildung 4: Snowplow Data Processing Pipeline
2.1 Tracker und Webhooks
Als Tracker werden von Snowplow clientseitige oder serverseitige Libraries verschiedener Technologien bezeichnet, welche NutzerInteraktionen (Snowplow Events) mittels HTTP GET- oder POSTRequest an den Collector senden. Snowplow bietet standardmäßig eine Vielzahl vorgefertigter TrackingSkripte für unterschiedliche Frameworks und Programmiersprachen an. Insgesamt stehen neben gängigen JavaScript-Trackern (Web und node.js) und nativen Mobile Trackern für iOS und Android über 80 verschiedene Tracker für Programmiersprachen wie Java, Python, Scala, Ruby, PHP, C++ und Unity zur Verfügung. Hinzu kommen zahlreiche Webhooks für Third Party Tools und Anwendungen wie MailChimp, HubSpot, Zendesk, Adjust und viele mehr. Alle NutzerInteraktionen (Events) werden dabei nach einem festen SchemaDesign definiert und anschließend durch den Tracker erhoben und strukturiert.
2.1.1 Schema-Design
Das Schema-Design ist das Herzstück der Snowflake Data Processing Pipeline und beschreibt, wie Daten strukturiert werden sollen. Sobald Daten in die Pipeline eingeführt werden, wird jedes Event anhand eines selbst beschreibenden Schemas validiert. Events, die das Schema-Format verfehlen, werden in einen separaten Event Stream (Bad Events) verschoben. Mehr Informationen dazu folgen im weiteren Verlauf. Das folgende Code-Beispiel für einen Google Analytics Pageview Hit soll den Aufbau des Schema-Designs in Snowplow näher erläutern:
Abbildung 5: Schema für ein Google Analytics Seitenaufruf (iglucentral.com)
Das Argument “$schema” weist die Snowplow Pipeline an, die aufgenommenen Daten nach dem hinterlegten Schema im IgluRepository der Ziel-Url entgegenzunehmen und im nächsten Schritt zu validieren. Das Argument dient als Schlüsselelement in der Tracker-Collector-Kommunikation und sollte demnach nicht angepasst werden. „self“ enthält Metadaten, die das Schema „selbstbeschreibend“ machen. Darunter fallen Informationen zum Vendor, für den die Daten bestimmt sind, wie auch das technische Format und die Version des verwendeten Schemas. Neben Event-spezifischen Informationen werden durch das Snowflow Tracker Object zusätzliche Parameter zu Browser-Informationen und Seiteninhalt übermittelt. Eine ausführliche Parameter-Referenz findet sich hier.
2.1.2 Events und Entities (Context)
Ein Event bezeichnet eine Aktion, welche durch das SchemaDesign und dessen Dateninhalt charakterisiert wird. Sobald ein Event ausgelöst wird, generiert der implementierte Snowplow Tracker ein Datenpaket zur Beschreibung des Events nach festgelegtem Schema-Design und sendet dieses an den Collector. Neben der Möglichkeit zur Erstellung benutzerdefinierter Events stellt Snowplow eine Reihe von Standard-Events zur Verfügung, die automatisch durch den Tracker erhoben werden können. Die folgende Abbildung stellt einen Auszug der Standard-Events dar.
Abbildung 6: Snowplow Event Types (docs.snowplow.io)
Wie in Punkt 3.9 und 3.10 der Abbildung aufgeführt, lassen sich neben dem von Snowplow vordefinierten Event-Schema für spezifische Ereignisse (Snowplow authored Events) auch benutzerdefinierte Events erstellen. Snowplow unterscheidet hierbei zwischen der Erstellung von strukturierten und unstrukturierten Events. Strukturierte Events folgen einem festen Schema-Design (Category, Action, Label, Property etc.). Unstrukturierte Events folgen nicht dem nativen Schema-Design von Snowplow, da sie beispielsweise unbekannte SchlüsselWert-Paare von anderen Vendoren enthalten (Bsp. AnzeigenImpressionen/Klicks).
Wenn ein Event ausgelöst wird, ist es im Allgemeinen mit einer Reihe von Entitäten verbunden. Entitäten geben dem Event einen zusätzlichen Kontext. Custom Context bietet in Snowplow die Möglichkeit, gemeinsame Entitäten einmal zu schematisieren und diese Schemata dann für verschiedene Events zu verwenden, in welchen diese Entitäten relevant sind. Beispiele für Custom Context Ecommerce-Events können Produktinformationen wie SKU, Preis, Category und Brand sein. Der eigentliche Mehrwert von Custom Context liegt jedoch darin, dass er innerhalb unterschiedlicher Event-Typen gesendet werden kann. So lassen sich zum Beispiel mehrere Produkt-Impressionen innerhalb einer Produktliste mit einem Pageview erfassen.
2.2 Collector App
Snowplow verwendet einen Collector als Endpunkt, an den Daten durch Tracker oder Webhooks geschickt werden können. Dieser Collector befindet sich in einer Compute Engine-Instanz (Virtual Machine) und verarbeitet die Anfragen. Anschließend wird der Payload der Events in ein Apache Thrift-Format von dem Collector standardisiert und die Log Files anschließend in eine Streaming Pipeline (Google Pub/Sub, AWS Kinesis) geschrieben. Die Collector App unterzieht die Events dabei schon einer ersten Pre-Validation, in der das Vendor-spezifische Event-Schema eingehender Events mit dem im Iglu Central-Repository zugrundeliegenden Schema abgeglichen wird. Von dort aus werden die Daten für deren weitere Validierung und Anreicherung weitergereicht.
Bad Stream
Der sog. Bad Stream zeigt alle in die Pipeline eingeführten Events, welche nicht erfolgreich gegen das Schema validiert werden konnten. Außerdem bietet er die Möglichkeit, nicht nur die Events zu analysieren, die nicht in das Schema passen, sondern auch den Fehler dazu zu ermitteln. An dieser Stelle können weitere Maßnahmen in Form von Jobs oder Data Cleaning vorgenommen werden, um die Daten in das richtige Schema zu strukturieren und in den Good Stream zurückzuführen.
2.3 Enrichment (Validation)
Der Snowplow Enrichment-Prozess nimmt die von dem Collector erzeugten Log Files entgegen, bereinigt die Daten und reichert sie an. Im ersten Schritt werden die Daten gegen das zuvor individuell definierte Schema-Design validiert, welches sich im eigenen Iglu-Repository befindet. Iglu ist ein maschinenlesbares SchemaRegister für JSON-Schemata. Das vordefinierte JSON-Schema wird auf den self-hosted Iglu-Server geladen, welcher als Speicher für Schema-Versionen der Data Pipeline dient. Die Schema-Version spielt im Tracking eine besondere Rolle, da sie im Tracking Code definiert werden muss, um die Rahmenbedingungen für die Event-Qualität festzulegen und anschließend validiert werden zu können.
2.3.1 Enricher
Snowplow stellt zwei verschiedene Arten von Enrichern zur Verfügung. Für die Verarbeitung von Batch-Loads wird Spark Enrich verwendet. Streaming-Daten können mit Stream Enrich gemanagt werden, einer in Scala geschriebenen Anwendung, in der Snowplow Events in dem Raw Data Stream von einem Scala Collector angereichert werden. Der Scala Collector validiert dabei jedes Event in “realtime” und schreibt es in den jeweiligen Stream. Darauf ruft der Enricher die Events aus dem spezifischen Pub/Sub Topic ab und reichert diese an. Anschließend bringt er die Events in das richtige Format und schreibt sie zurück in ein Pub/Sub Topic (Enriched Data Stream), aus dem die Daten im letzten Schritt zu BigQuery übermittelt werden.
2.3.2 Enrichment-Typen
Nach erfolgreicher Validierung des Schemas können die Rohdaten im nächsten Schritt über das dimension widening angereichert werden. Für die Anreicherung der Events stehen folgende Optionen zur Verfügung:
Hardcoded Enrichment
Einzelne Event Fields werden den Events hinzugefügt, abhängig davon, ob die Daten durch das Tracker Object zur Verfügung gestellt wurden oder nicht.
Configurable Enrichment
Die Felder werden entweder aus den zur Verfügung gestellten First Party-Datenquellen oder aus Datenquellen von Drittanbietern ausgefüllt. Unter anderem unterstützt Snowplow standardmäßig die Konfiguration folgender Third Party Enrichments:
2.4 Load and Store
Nachdem die Compute Engine-Instanz des Enrichers die angereicherten Daten in ein weiteres Pub/Sub Topic (Stream) geschrieben hat, können die Daten in das Zielsystem geladen werden. Hierfür wird ein Apache Beam Managing-Dienst (bspw. Cloud Dataflow, AWS Kinesis oder eine eigene Compute Engine Instanz) benötigt, welcher die Daten aus einem temporären Objektspeicher wie dem Google Cloud Storage oder einem S3 Glacier bezieht. Über den Loader können die Daten anschließend in das Data Warehouse geladen werden.
3. Integration von Snowplow in die Google Cloud Platform
Wie schon bei der Vorstellung der Snowplow Data Processing Pipeline beschrieben, lässt sich der Aufbau ihrer technischen Infrastruktur grob in die Definition eines Event-Schemas (IgluServer) und die Erstellung der Event Pipeline untergliedern. Um ein besseres Verständnis für die Komplexität des Snowplow Data Collection-Prozesses zu bekommen, soll das folgende Schaubild ein Praxisbeispiel für den Aufbau der Snowplow Data Pipeline im Ökosystem der Google Cloud Platform (GCP) aufzeigen.
Abbildung 7: Integration der Snowplow Data Processing Pipeline in der GCP
Über die jeweiligen Quellsysteme wie bspw. Websites, Mobile Applikationen, Datenbanken oder auch Server werden die Events von Snowplow Trackern oder aber auch Webhooks an den Snowflake Collector gesendet.
In der GCP steht eine Compute Engine-Instanz als Collector bereit, welche die Events annimmt und eine erste Validierung des Event Schemas durchführt sowie Events, die das Standard-Schema nicht erfüllen, in ein separates Pub/Sub Topic verschiebt (Bad Event Stream). Erfolgreich validierte Events werden anschließend in ein Apache Thrift-Format von dem Collector standardisiert und in ein weiteres Pub/Sub Topic geschrieben, welches den sog. Raw Data Stream widerspiegelt.
Der Enricher ruft die Events aus dem Pub/Sub Topic des Raw Event Streams ab. Dieser validiert die Events gegen das zuvor individuell definierte Schema-Design im Iglu-Repository des eigenen Iglu-Servers und nimmt beschriebene Änderungen oder Ergänzungen an dem Event Payload vor. Anschließend werden die angereicherten Event-Daten zurück in ein neues Pub/Sub Topic (Enriched Data Stream) geladen.
Der sog. Loader ist eine weitere Compute Engine-Instanz, welche die Aufgabe besitzt, die Daten aus dem Enriched Data Stream wie auch aus dem Bad Data Stream in das gewünschte Zielsystem (Data Warehouse) zu schreiben. In BigQuery werden für die einzelnen Streams separate Tables erstellt, in welchen sich die Daten anschließend für weitere Analysen und Datenmodellierungen nutzen lassen.
4. Fazit
Snowplow mit seiner Open Source Data Collection Platform bietet viele Funktionen zur Kontrolle und Individualisierung der Generierung und Verarbeitung verhaltensbasierter Webseiten. Durch den ständigen Abgleich des Event-Schemas und seiner Validierung kann auf die korrekte Struktur der Daten vertraut werden, da der komplette Prozess der Datenerfassung und -verarbeitung kontrolliert werden kann.
Entspricht in Analytics Tools wie Google Analytics 4 etwas nicht dem Schema, werden die Daten schlicht nicht in die Property gesendet. Eine Fehleranalyse dazu, weshalb gewisse Events nicht der Semantik von Google Analytics entsprechen und abgelehnt werden, wird dabei verwehrt. Bei Snowplow besteht volle Einsicht darüber, welche Daten nicht im Event Stream erfasst werden und warum sie nicht dem Schema entsprechen.
Auch wenn das Tool sehr vielversprechend ist, sollten die hohe technische Komplexität und der mit ihr verbundene Wartungsaufwand der Pipeline berücksichtigt werden. Daher eignet sich die Open Source-Variante eher nicht für kleine Unternehmen ohne eigene Data Teams, die das Thema verantworten können.