Suche
Dem Nutzer auf der Spur

Ich weiß, was du mit meiner App gemacht hast: Nutzer-Tracking mit MQTT

Dirk Dorsch

© Shutterstock/AVN-Photo-Lab

Es gibt einige Themen, bei denen Marketingabteilung und Entwicklung deutlich unterschiedlicher Meinung sind. Eines davon ist häufig das Thema Nutzer-Tracking. Für das Marketing ist es das einzig relevante Feature eines Systems, für den Entwickler ein datenschutzrechtlicher Moloch, der überdies neben dem ohnehin schon integrierten Logging den Code gänzlich entstellt. Zur Lösung dieses Zwists gibt es einen vielversprechenden Ansatz: MQTT.

Nutzer-Tracking mit MQTT

Fachlich sind die Bedenken gegenüber dem Nutzer-Tracking durchaus zu verstehen. Noch dazu macht die Integration von Tracking- oder Logging-Tools gemeinhin wenig Spaß. Aber wie ist es, ein Tracking-Tool selbst zu entwickeln? Anstatt das Feld den großen Datenkraken zu überlassen, lässt sich auf Basis des ressourcenschonenden MQTT-Protokolls ein eigenes Tracking-Tool entwickeln – mit einem wesentlich höheren Spaßfaktor, als ihn die Integration bestehender Lösungen bieten würde.

Auch für Entwickler können Tracking-Tools ein nicht zu unterschätzendes Werkzeug sein, insbesondere in mobilen Applikationen. Während sich der Web-/Backend-Entwickler durch den gekonnten – aber oft nicht so schönen – Einsatz eines Logging-Frameworks in Kombination mit einem Logfileanalysetool schnell über die Geschehnisse in seinem System Klarheit verschaffen kann, hilft dem Android-Entwickler das Logging nur während der Entwicklungszeit. Kaum ist die Applikation in die freie Wildbahn entlassen, entzieht sie sich dem Zugriff des verantwortungsvollen Entwicklers. Er hört nur ab und an über Crash Reports etwas von seiner Applikation. Ein Logging, oder eben Nutzungs-Tracking, bietet aber weitere interessante Einblicke in die Applikation. So können wenig genutzte Funktionen erkannt und jederzeit die relevanten Pfade durch den Code unter realen Bedingungen nachvollzogen werden. Spätestens bei der Entwicklung mobiler Anwendungen darf ein Entwickler in einem Tracking-Tool mehr sehen als den Wunsch der Marketingabteilung, den gläsernen Benutzer schaffen zu wollen.

Der Markt bietet eine reichhaltige Auswahl an Tracking-Tools. Häufig stammen sie aus dem Kontext des Web-Trackings, weshalb es auch nicht weiter verwunderlich ist, dass auch eine große Suchmaschine ein entsprechendes Tooling anbietet. Die Marketingabteilung oder ein Product Owner stellen einen ebenso hohen Anspruch an das Tracking in mobilen Apps, wie sie es aus dem Web gewohnt sind. Web-Tracking ist häufig über die Anbindung eines (REST-artigen) API über HTTP realisiert. Bei Multi-Page-Anwendungen wird bei jeder ausgelieferten Seite ein kleines JavaScript integriert, und schon offenbart der Browser des Benutzers dessen Vorlieben in der Nutzung der Webseite. Modernere Single-Page-Applikationen stellen bereits andere Anforderungen an ein Tracking-Tool, und Applikationen für mobile Plattformen sind wiederum ein gänzlich anderes Thema.

Während eine Webseite die Onlinekonnektivität inhärent voraussetzt und es bei den ohnehin schon voluminösen Inhalten nicht auf ein paar durch einen Tracking Request verursachte Bytes mehr ankommt, kann bei einer App zum einen keine dauerhafte Konnektivität vorausgesetzt werden, zum anderen kann auch noch nicht bei jedem Telefon von einer Datenflatrate ausgegangen werden. Somit ist Sparen angesagt. Der Ansatz des Web-Trackings, jeden Request unmittelbar an ein Tracking-Tool zu übergeben, ist in zweierlei Hinsicht nicht optimal. Zunächst ist das Auf- und Abbauen eines HTTP-Requests bei jeder Aktion oder jedem geloggten/getrackten Ereignis ein nicht zu unterschätzender Overhead. Um diesen Overhead zu minimieren, setzen viele Tools auf eine Batch-Übertragung. Die einzelnen Logs werden zunächst applikationsseitig gesammelt und dann am Stück in einen Request übertragen. Dieser Ansatz umgeht den HTTP-Overhead häufiger Verbindungen und kann daher wesentlich ressourcenschonender sein als das einer DDoS-Attacke ähnelnde Loggewitter eines intensiv gelebten Loggings. Dieser Ansatz führt aber zum nächsten Problem, nämlich einer unter Umständen großen temporären Belastung der Netzwerkressource. die einige Apps ebenso negativ beeinträchtigen kann.

Nutzungs-Tracking ist nicht die einzige Problemstellung, bei der in kurzen Abständen geringe Datenvolumen von ressourcenbeschränkten Geräten übertragen werden müssen – im Internet der Dinge ist das eine grundlegende Basisanforderung. Auf den ersten Blick mögen die Übermittlung und Auswertung von Sensordaten mit einem Nutzungs-Tracking nicht viel gemein haben. Abstrahiert betrachtet werden in beiden Fällen jedoch in verhältnismäßig vielen Einzelschritten große Datenmengen übertragen, die serverseitig analysiert werden sollen. Ein technologisches Grundgerüst für solche Applikationen wurde in [1] vorgestellt.

Mehr zum Thema: Spark, Mesos, Akka, Cassandra, Kafka: Aus Big Data werde Fast Data

Das Nutzungs-Tracking kann sich an diese Konzepte anlehnen und muss nur noch den Weg der Daten vom Telefon zum Server realisieren. Die naheliegenden Anforderungen an ein mobiles Nutzungs-Tracking sind zum einen eine einfache Skalierbarkeit auf der Serverseite, zum anderen ein nicht-(UI-)blockierendes Verhalten auf der Clientseite. Hauptanforderung des Clients ist es also, die Logdaten irgendwie im Hintergrund loszuwerden. Die Serverseite wiederum will die Annahme der Daten skalieren können und von der weiterverarbeitenden Analyse entkoppeln. Die Architekturwahl fällt so schnell auf den Einsatz eines Messaging-Systems.

Geschrieben von
Dirk Dorsch
Dirk Dorsch
Dirk hat seit 2008 nahezu alle Rollen in der Java-basierten (mobile) Enterprise-Entwicklung durchgemacht. In den Jahren als Entwicklungsleiter vermisste er das Hands-on und legt nun den Fokus wieder auf die Entwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.