© Excellent backgrounds/Shutterstock.com
Nutzungs-Tracking mit MQTT

Ich weiß, was du mit der App gemacht hast


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.

Video: Mobile Development: Take Advantage of Test Automation

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. 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.

Was hinter MQTT steckt

MQTT (Message Queue Telemetry Transport) [2] wurde als leichtgewichtiges Publish-/Subscribe-Protokoll entworfen. Der Fokus von MQTT liegt auf der Übertragung von (Telemetrie-)Daten in unzuverlässigen Netzwerkumgebungen von Maschine zu Maschine. Anders als beim aus REST over HTTP gewohnten Request-/Response-Paradigma ist ein MQTT-basiertes Publish-/Subscribe-System Event-gesteuert. Zentrales Element des Systems ist der MQTT Broker. Wie Abbildung 1 zeigt, können unterschiedliche Sensoren ihre Daten am Broker veröffentlichen. Sogenannte Topics strukturieren das System. Während der Publisher seine Daten immer bezüglich eines bestimmten Topics veröffentlicht, abonniert die Gegenseite in der Subscription ebenso immer ein Topic. Sollen in einem System die einzelnen Abonnenten bei ihrer initialen Verbindungsaufnahme mit immer gleichen Informationen, beispielsweise einer Konfiguration, versorgt werden, kann an einem Topic genau eine retained Message abgelegt werden. Sie wird bei jeder Subscription unmittelbar und genau einmal ausgestellt. Die Ausstellung regulärer Nachrichten kann über das Quality-of-Service-Level gesteuert werden. Neben dem niedrigsten Level 0 (fire-and-forget), das keinerlei Ausstellungsgarantie übernimmt, kann mit dem QoS 1 sichergestellt werden, dass eine Nachricht mindestens einmal ausgestellt wird. Während QoS 1 zu Dubletten führen kann, können sie mit QoS 2 ausgeschlossen werden. In diesem höchsten Level werden Nachrichten genau einmal ausgestellt. Soll auch eine Ausstellung nach Verlust der Verbindung zum Server garantiert werden, muss eine Art persistente Session beim Broker beantragt werden. Hierzu sieht MQTT beim Verbindungsaufbau das cleanSession Flag vor. Neben optionalen Authentifizierungsdaten wird beim Verbindungsaufbau auch eine Client-ID mitgeschickt. Sofern sie immer gleich und (Broker-)global eindeutig ist, kann in Kombination mit cleanSession = false und einem QoS 1 oder 2 die Auslieferungsgarantie über die Verbindung hinaus gewährleistet werden. Um den Overhead eines wiederholten Aufeinanderfolgens von Verbindungsaufbau und Subscription/Publishing zu minimieren, können MQTT-Verbindungen dauerhaft offen gehalten werden. Hierzu genügt das regelmäßige Übermitteln eines Ping Requests. Ein Client kann bei der Verbindung optional einen Last Will und ein Testament (LWT) übergeben. Dieser ist analog zu einer Message strukturiert und enthält das Topic, das QoS und die Payload. Bemerkt der Broker den Verbindungsabbruch eines Clients, versendet er diese Nachricht an alle Subscriber d...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang