Funktionale vs. analytische Datenzwecke trennen: Was wir aus „The purpose of your data“ von Clemens Kaar (Tractive GmbH) mitnehmen

Kontext: Ein Blick hinter die Kulissen von Tractive und der Session

In der Session „The purpose of your data“ führte uns Clemens Kaar, Head of Big Pet Data bei der Tractive GmbH, durch eine ebenso einfache wie folgenschwere Grundidee: Jedes Datum in einem Unternehmen hat einen Zweck – und zwar typischerweise zwei sehr unterschiedliche. Einen funktionalen Zweck (das, was ein Produkt oder eine Anwendung unmittelbar für Kundinnen und Kunden leisten muss) und einen analytischen Zweck (das, was Teams später aus denselben Daten lernen wollen). Kaars zentrale Botschaft: Wer diese beiden Perspektiven nicht sauber trennt, verliert Fokus, Performance und letztlich die Fähigkeit, verlässlich zu analysieren.

Zur Einordnung: Tractive ist Marktführer im GPS-Tracking für Katzen und Hunde. Der Tracker ist zugleich ein Aktivitätstracker, der Aktivität und Schlafverhalten erfasst und auf dem Smartphone sichtbar macht. Das Unternehmen hat seinen Hauptsitz in Linz (Pasching), rund 140 Mitarbeitende aus mehr als 30 Nationen (die Unternehmenssprache ist Englisch), seit kurzem auch ein US-Büro. Nach Kaars Angaben tragen etwa 500.000 Katzen und Hunde in über 150 Ländern weltweit ein Tractive-Gerät.

Diese Fakten liefern den Rahmen für Kaars Kernanliegen: Das Datenökosystem von Tractive ist breit – GPS-, Aktivitäts-, Nutzer-, App-, Web-, Marketing-, Logistik-, Sales-, Finanz- und Webshop-Daten sowie Daten externer Tools (er nannte explizit MailChimp). In dieser Vielfalt verschiebt sich der Fokus leicht. Zunächst denken Produkt- und Entwicklungsteams naturgemäß funktional. Mit der Zeit entstehen jedoch Analysebedarfe. Genau an diesem Übergang passieren die kostspieligen Fehler.

Der Kern: Zwei Zwecke – funktional und analytisch

Clemens Kaar trennt konsequent zwischen funktionalem und analytischem Datenzweck. Er illustriert das mit mehreren konkreten Beispielen:

• GPS-Daten
• Funktionaler Zweck: Kundinnen und Kunden möchten wissen, wo sich ihre Katze oder ihr Hund befindet – jetzt, in Echtzeit. Der Tracker liefert den Weg und den aktuellen Standort aufs Smartphone.
• Analytischer Zweck: Ein Produktteam möchte verstehen, wann in bestimmten Regionen die Jagdsaison beginnt, um Partnerschaften zu synchronisieren oder die Produktqualität zu verbessern.
• Aktivitätsdaten
• Funktionaler Zweck: Der Kunde sieht, wie aktiv der Hund ist oder wie sich das Schlafverhalten gestaltet.
• Analytischer Zweck: Intern lassen sich etwa Schlafprofile von Beagles mit denen sibirischer Huskys vergleichen.
• Marketingdaten
• Funktionaler Zweck: Marketingkampagnen effizient ausspielen (z. B. Google-Kampagnen).
• Analytischer Zweck: Kampagnen vergleichen, Verhalten verstehen, Strategien ableiten – mit Blick auf Effizienz.

Diese Gegenüberstellung macht sichtbar, dass dieselbe Datenquelle in völlig verschiedenen Nutzungskontexten lebt. Damit verändern sich Anforderungen an Modellierung, Abfrage, Performance, Latenz und Usability.

Datenlandschaft: Viele Quellen, interne und externe

Kaar betont, dass Daten in diversen Systemen entstehen:

• Interne Datenbanken, unter anderem für Webshop-, Nutzer- und GPS-Daten.
• Externe Systeme, wie MailChimp für Newsletter-Kampagnen.

In der Praxis beginnt jede Systemeinführung mit dem funktionalen Ziel. Das ist legitim: Ein GPS-Tracker wird eingeführt, um Haustiere zu tracken, nicht um sofort komplexe Analysen zu fahren. Doch die Erfahrung zeigt, dass mit dem Ausbau eines Produkts immer mehr Stakeholder Analysen wünschen – und dabei zu schnell auf die funktionalen Systeme zugreifen wollen. Genau hier setzt Kaars Warnung an.

Die Falle: Analytics in funktionalen Systemen unterbringen

„Am Anfang ist es nur der Kunde, den wir bedienen müssen“, so die implizite Ausgangslage. Aber dann kommen Anfragen aus Produkt, Forschung oder Marketing: „Wir bräuchten zusätzlich diese Historie“ oder „Wir möchten diese Daten über mehrere Quellen hinweg vergleichen.“ Die vermeintlich einfache Lösung: „Wir fügen im Transaktionssystem noch ein paar Tabellen hinzu“ oder „Wir loggen zusätzliche Werte direkt in der funktionalen Datenbank.“

Nach Kaar ist das „nicht der Weg“. Warum?

• Fokusverlust: Funktionale Systeme sind für unmittelbare Produktfunktionen optimiert. Zusätzliche analytische Strukturen vernebeln Verantwortlichkeiten und Ziele.
• Performance-Konflikte: Funktional zählt schnelle, gezielte Abfrage auf Einzelobjekte (z. B. ein Tracker). Analytisch zählen Bulk-Analysen über große Datenmengen – das gefährdet die Antwortzeiten funktionaler Pfade.
• Usability-Divergenz: Die Bedienung und Datenaufbereitung unterscheidet sich stark zwischen Kundensicht und Analytik-Sicht.
• Schema-Drift: Analytische Anforderungen führen oft zu Format- und Integrationsbedarfen, die nicht in produktionsnahen Datenbanken gelöst werden sollten.

Kaars Fazit: Wer beides vermischt, zahlt doppelt – mit Qualitätseinbußen in der Anwendung und mit zäher, fehleranfälliger Analyse.

Die Architekturantwort: Ein separates Analytics-Ökosystem

Die strukturelle Lösung ist die klare Trennung der Datenwelten. Kaar skizziert mehrere Varianten, wie Unternehmen diesen Bruch umsetzen:

• Einsatz eines SQL-Tools zur direkten Analyse über extrahierte Daten.
• Nutzung eines Tools wie Tableau, das auch ein eigenes Data-Warehouse-Setup mitbringt.
• Aufbau eines eigenen Data Warehouses, in das Daten aus verschiedenen Quellen extrahiert, transformiert und geladen werden, anschließend Visualisierung.
• Kombination aus eigenem Data Warehouse und einem Warehouse des Tool-Anbieters.
• Pfad über einen Data Lake: Daten extrahieren, in den Lake legen, weiterverarbeiten, in ein Data Warehouse schieben, visualisieren.

Wichtig ist in allen Varianten die logische Trennung: Funktionale Systeme dienen Produkt und Kundenerlebnis; analytische Systeme dienen der Auswertung – und sind technisch, organisatorisch wie prozessual entkoppelt.

Gründe für die Trennung – aus Kaars Sicht

Kaar benennt konkrete Motive, die wir als Leitplanken verstehen können:

• Informationen verknüpfen: Datenquellen verbinden, die funktional nichts miteinander zu tun haben, analytisch aber gemeinsam betrachtet werden müssen.
• Datenformate vereinheitlichen: Unterschiedliche Schemata und Formate lassen sich im Analytics-Pfad harmonisieren.
• Performance dort optimieren, wo sie gebraucht wird:
• Funktional: sehr schnelle Zugriffe für Abfragen auf einzelne Entitäten (z. B. aktueller GPS-Standort).
• Analytisch: Bulk-Analysen, Aggregationen, Batch-Verarbeitung.
• Unterschiedliche Usability-Anforderungen: Kundensicht und Analystensicht verlangen andere Oberflächen, Modelle und Abfragepfade.

Diese Gründe erklären, warum ein Data Warehouse kein Selbstzweck ist – sondern ein strukturelles Mittel, um die beiden Zwecke von Daten sauber zu erfüllen.

Wie Tractive die Pipeline betreibt

Kaar beschreibt den analytischen Datenfluss bei Tractive mit klaren Bausteinen:

• Orchestrierung: Airflow steuert die Jobs zur Extraktion.
• Verarbeitung: Apache Spark führt die Extraktionen durch.
• Speicherung (Staging): Amazon S3 dient als Zwischenablage für die geladenen Daten.
• Data Warehouse: Die Daten werden nach Amazon Redshift geladen.
• Visualisierung: „Any kind of data visualization tools“ – die konkrete Toolauswahl ist offen, Visualisierung ist aber der abschließende Zugriffspfad.

Damit schafft Tractive eine dedizierte Analytics-Landschaft – entlastet die funktionalen Systeme und stellt gleichzeitig sicher, dass Analystinnen und Analysten auf integrierte, performante Daten zugreifen können.

Warum das noch nicht reicht: Die BMI-/Gewichts-Historie als Lehrstück

Besonders einprägsam ist Kaars Beispiel einer hypothetischen neuen Funktion: Ein BMI-Rechner für Hunde. Funktional genügt es, das Gewicht abzufragen und direkt in der App das Ergebnis anzuzeigen – ähnlich dem menschlichen BMI. Alles in Ordnung, solange es nur um den unmittelbaren Nutzen geht.

Später entsteht jedoch ein Analysewunsch: „Wie entwickelt sich das Gewicht über die Zeit?“ Das erfordert eine Historisierung der Gewichte. Die naheliegende (aber problematische) Reaktion ist, die funktionale Datenbank zu erweitern: jedes Mal, wenn der Kunde das Gewicht ändert, einen neuen Eintrag schreiben, die komplette Historie im Transaktionsschema halten – obwohl diese Historie gar nicht für den Kunden angezeigt werden soll, sondern rein für Analysezwecke gedacht ist.

Genau hier verläuft die unsichtbare Grenze: Wird eine rein analytische Anforderung in der funktionalen Datenbank realisiert, sind die beiden Welten wieder vermischt. Kaars Alternative: Diese Historisierung im Analytics-Pfad aufbauen – also in der Datenpipeline-Struktur, nicht in der funktionalen Anwendung. In der Realität, so Kaar, sprechen Stakeholder allerdings oft zuerst mit den „funktionalen“ Entwicklern („Wir müssen dieses Datum erfassen“), nicht mit den Datenleuten. Das führt zurück in die alte Falle.

Die Lehre: Es braucht mehr als Technik. Es braucht Bewusstsein, Organisation und Prozess.

Drei Empfehlungen: Bewusstsein, Organisation, Prozess

Kaar schließt mit drei konkreten Empfehlungen, wie Teams die Trennung dauerhaft absichern:

1) Bewusstsein schaffen

• Jede und jeder im Unternehmen – Produkt, Entwicklung, Daten, Marketing – muss die zwei Seiten des Datensatzes kennen: funktional und analytisch.
• Mit diesem Mindset fällt die Zuständigkeitsklärung leichter: Wer liefert die Funktion? Wer baut die Analysefähigkeit?

2) Organisational trennen

• Tractive arbeitet mit Data Engineers, Datenleuten und Entwicklern auf der funktionalen Seite – und mit Data-Expertinnen, Entwicklern und Verantwortlichen auf der analytischen Seite.
• Diese organisatorische Differenzierung erleichtert Entscheidungen, Priorisierung und den Schutz der jeweils anderen Welt.

3) Prozessual verankern

• Neue Features starten bei Tractive mit Kickoffs, in denen beide Seiten vertreten sind: diejenigen, die die Funktion bauen, und diejenigen, die die analytische Auswertung ermöglichen.
• Tickets werden getrennt: ein Ticket für den funktionalen Teil, ein Ticket für den analytischen Teil.
• So bleibt klar, welche Anforderungen wohin gehören – und dass analytische Anforderungen nicht stillschweigend in der Transaktionswelt landen.

Praktische Implikationen für Engineering-Teams

Aus Kaars Vortrag lassen sich klare Handlungsanweisungen ableiten, ohne über das Gesagte hinauszugehen:

• Definiere den Zweck jedes Datums explizit. Frage bei neuen Features konsequent: Was ist der funktionale Zweck? Was ist der analytische Zweck?
• Platziere die Implementierung am richtigen Ort. Alles, was ausschließlich der Analyse dient (Historisierungen, Aggregationen, Formatangleichungen), gehört in die Analytics-Landschaft – nicht ins funktionale Schema.
• Etabliere eine stabile Datenpipeline. Ein orchestrierter Flow – Extraktion, Verarbeitung, Staging, Warehouse, Visualisierung – schafft einen belastbaren Pfad für Analysezwecke.
• Optimiere getrennt für unterschiedliche Performanceziele. Funktional: niedrige Latenz, punktuelle Abfragen; analytisch: Bulk-Throughput, Batch-Prozesse, vereinheitlichte Schemas.
• Halte Zuständigkeiten sauber. Wer verantwortet das Feature? Wer verantwortet die Analysefähigkeit? Dokumentiere dies pro Kickoff und Ticket.

Details, die den Unterschied machen

Kaar sprach mehrere feine, aber entscheidende Punkte an, die im Alltag oft untergehen:

• „Functional first“ ist normal – aber nicht endgültig. Systeme werden verständlicherweise für Kundennutzen gebaut. Die Realität ist jedoch, dass Analysebedarfe unvermeidlich entstehen. Diese Bedarfe gehören in eine dedizierte Analytics-Architektur.
• Getrennte Usability-Welten. Die Art, wie Kundinnen und Kunden Daten sehen sollen, ist eine andere als die, wie Analystinnen und Analysten Daten benötigen. Das legitimiert unterschiedliche Schemata, Transformationslogiken und Zugriffsmodelle.
• Bulk statt Einzelobjekt. Analytische Arbeit interessiert sich selten für den „einen Tracker“, sondern für Muster über viele Tracker hinweg. Das ist ein anderes Zugriffsmuster als das einer App, die einen aktuellen Standort anzeigen muss.
• Joinen und Vereinheitlichen als First-Class-Bedarf in Analytics. Kaars Beispiele zeigen, dass Analysen häufig Quellen übergreifen (z. B. App-, Web-, Marketing-, GPS-Daten). Diese Integrationsaufgabe gehört nicht in produktionsnahe Datenbanken.

Ein wiederkehrender Anti-Pattern-Zyklus – und wie man ihn bricht

Der von Kaar beschriebene Zyklus ist vertraut:

1) Ein Team benötigt eine neue Erkenntnis.

2) Es fragt das nächste erreichbare Team – oft die funktionalen Entwickler.

3) Diese implementieren rasch zusätzliche Felder oder Tabellen.

4) Die funktionale Datenbank wird ein Quasi-Analytics-System.

5) Ab diesem Punkt leiden sowohl Produkt-Performance als auch Analysequalität.

Der Ausweg ist, diesen Zyklus sichtbar zu machen – und ihm eine etablierte Alternative entgegenzusetzen: den Analytics-Pfad. Mit der genannten organisatorischen und prozessualen Trennung können Teams Anfragen früh richtig routen.

Einprägsame Beispiele, die wir mitnehmen

• GPS-Zweck: Kundenstandort jetzt vs. Jagdsaisonmuster später. Derselbe Datenstrom, zwei gegensätzliche Anforderungen.
• Aktivitätsschlaf-Vergleiche: Kunden sehen Schlafverhalten; intern werden Rassenprofile verglichen. Kundenansicht ist nicht Analyseansicht.
• BMI-/Gewichtshistorie: Funktional reicht der aktuelle Wert; analytisch braucht es Historisierung. Der Ort dieser Historisierung entscheidet über die Gesundheit des gesamten Datenökosystems.

Diese Beispiele sind bewusst greifbar – und genau deshalb so hilfreich: Sie verhindern, dass die Diskussion abstrakt bleibt.

Werkzeuge sind Mittel zum Zweck – das Prinzip zählt

Airflow, Apache Spark, Amazon S3 und Redshift sind keine Dogmen, sondern konkrete Ausprägungen eines Prinzips: Orchestrierung, Verarbeitung, Staging, Warehouse, Visualisierung – alles in einem separaten Analytics-Pfad. Entscheidend ist, dass dieser Pfad organisatorisch und prozessual geschützt bleibt. Andernfalls droht trotz moderner Tools die alte Vermischung.

Fazit: Ein Mindset, das Komplexität reduziert

Clemens Kaars abschließende Empfehlung ist entwaffnend einfach: „Bitte wirklich sicherstellen, dass ihr dieses Mindset habt: Es existieren der funktionale Zweck und der analytische Zweck.“ Wenn alle das verinnerlichen, lassen sich Verantwortlichkeiten klären, Trade-offs adressieren und Architekturen so gestalten, dass beide Welten gewinnen.

Für uns war „The purpose of your data“ vor allem eine Erinnerung daran, dass technische Entscheidungen ohne organisatorische und prozessuale Flankierung zu kurz greifen. Eine saubere Trennung der Datenzwecke – und der dazugehörigen Systeme – ist kein Luxus, sondern Voraussetzung dafür, dass sowohl Produkt als auch Analyse funktionieren: Kunden sehen zuverlässig, wo sich ihre Katze oder ihr Hund befindet, und Teams können darüber hinaus robuste Erkenntnisse gewinnen – ohne das eine zugunsten des anderen zu opfern.

Wer tiefer einsteigen möchte, kann laut Kaar direkt den Kontakt suchen – per E-Mail oder auf LinkedIn. Die Prinzipien und Beispiele aus dieser Session liefern dafür eine klare gemeinsame Sprache: Funktional ist, was die App liefert. Analytisch ist, was das Unternehmen daraus lernt. Beides braucht seinen eigenen Raum.

• 

  

  Logging in a Polyglot IoT Environment

  Dominik Hurnaus von Tractive zeigt in seinem devjobs.at TechTalk „Logging in a Polyglot IoT Environment“ wie Tractive die Probleme, welche bei GPS Geräten, Server Software, Mobile Apps, usw. auftreten, gelöst haben.

  Jetzt ansehen