Abbildung 2: Produktvergleich Snowplow OS vs. BDP

zu den Preismodellen

Abbildung 3: Produktvergleich Snowplow Data Pipelines

zu den Pipeline-Typen

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.

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.

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.

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.

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.

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.

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.

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:

• IP-Anonymisierung

• IP-Lookups

• Kampagnen-Attribution

• Referrer-Parser

• Extrahieren von Cookies

• User Agent

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.

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.