Der Kern von Snowplow besteht aus einer Data Processing Pipeline, die Daten sammelt, validiert, anreichert und speichert, welche an HTTP-Endpunkte gesendet werden. Snowplow kann sowohl in der Cloud-Umgebung der Google Cloud Platform (GCP) als auch in der Amazon Web Services (AWS) Cloud betrieben werden. Der Fokus der Lösung liegt verstärkt auf Data Sourcing und Data Modeling. Hierfür wird ein eigenes JSON-Schema-Design bereitgestellt. Das Schema legt fest, welche Events in der Snowplow Pipeline verarbeitet werden dürfen. Es wird auf den sogenannten Iglu-Server (Objektspeicher) geladen, welcher im Wesentlichen einen Speicher von Schema-Versionen darstellt, die für die Data Pipeline erstellt wurden. Die Schema-Version spielt im Tracking eine besondere Rolle, da eingehende Events durch sie ständig validiert werden. Sie wird im Tracking Code definiert, um die Rahmenbedingungen für die Event-Qualität festzulegen. Es erfolgt somit ein gegenseitiger Abgleich zwischen Iglu-Server und Tracking Framework zur Gewährleistung einer maximalen Datenqualität.

Einer der wichtigsten Unterschiede zu Google Analytics 4 (GA4) oder Adobe Analytics besteht darin, dass Snowplow im Kern kein Analysetool ist. Snowplow bezeichnet sich selbst als “developer-first engine”, welche die komplette technische Infrastruktur über den Erhebungs- und Verarbeitungsprozess von verhaltensbasierten Daten erstellt und verwaltet. Snowplow bietet daher weniger Funktionen zur Analyse und Aktivierung der Daten.

Der Code der Plattform ist Open Source und gewährleistet vollständige Transparenz über den Aufbau und die Abläufe in der Pipeline. Dies schafft maximale Flexibilität in Bezug auf Anpassungen und Erweiterungen der Lösung, aber auch Raum für Komplexität. Entsprechend ist ein gewisser Grad an technischem Verständnis vorausgesetzt, um mit der Plattform arbeiten zu können.

Es besteht die vollständige Kontrolle darüber, wie Daten erfasst, prozessiert und gespeichert werden. Einzelne Event-Parameter (Enrichments) lassen sich individualisieren, was das Setup hochgradig konfigurierbar macht. 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 GA4 werden Events, die das gewünschte Format des Servers nicht erfüllen, stillschweigend abgelehnt, ohne dass das Tool den Nutzer darüber informiert. Durch den Bad Event Stream in Snowplow können auch Events, die dem Schema-Design nicht entsprechen, analysiert werden, wodurch volle Transparenz über die Datenqualität ermöglicht wird. Dies stellt einen signifikanten Unterschied zu Tools wie GA4 dar, welche die Daten-Infrastruktur 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 und Einsicht in die Abläufe der Datenverarbeitung fehlt. Zudem erhöht die Flexibilität in der Konfiguration von Events in GA4 das Risiko für schlechtere Datenqualität. Zwar bestehen verpflichtende Event-Parameter, die in einem Request enthalten sein müssen, doch wird der Event Payload grundsätzlich ohne weitere Prüfung vom Server entgegengenommen. In Snowplow hingegen wird ein Schema erstellt, welches die Events erfüllen müssen, um verarbeitet werden zu können.

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, der wiederum in weitere Teilschritte untergliedert ist und mehrere Komponenten enthält.

Über die Quellsysteme werden die Events mithilfe eines der über 80 Snowplow Tracker oder Webhooks an den Snowflake Collector gesendet. Dieser Collector befindet sich in einer Compute-Engine-Instanz (Virtual Machine) und verarbeitet die Anfragen. Anschließend wird der Payload der Events standardisiert, in eine Streaming Pipeline (Google Pub/Sub) geschrieben und einer ersten Schema-Validierung unterzogen.

Im nächsten Schritt validiert der Enricher die Events gegen das zuvor definierte Schema im Iglu-Repository und nimmt Änderungen oder Ergänzungen an dem Event Payload vor.

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 eine weitere Compute-Engine-Instanz benötigt, welche die Daten aus einem temporären Objektspeicher (Cloud Storage) bezieht. 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.

Snowplow mit seiner Open Source Data Collection Platform bietet viele Funktionen zur Kontrolle und Individualisierung der Generierung und Verarbeitung verhaltensbasierter Webseitendaten. 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 GA4 etwas nicht dem Schema, werden die Daten schlicht nicht in die Property gesendet. Eine Fehleranalyse dazu, weshalb gewisse Events nicht die Semantik von Google erfüllen und abgelehnt werden, bleibt aus. 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.