Mitglieder-Aktivität verfolgen — datensparsam und DSGVO-konform

Ein Schild als Sinnbild für Datenschutz Foto: Markus Spiske · Rawpixel (CC0 1.0), via Openverse

Fast jede Plattform will irgendwann wissen, wer eigentlich aktiv ist. Ein Studio möchte sehen, welche Mitglieder noch dabei sind und welche sich langsam verabschieden. Ein Trainer möchte wissen, ob seine Klienten die App überhaupt öffnen. Und wir als Betreiber möchten verstehen, ob das Produkt genutzt wird oder nur brachliegt. Die Versuchung ist groß, dafür einfach alles mitzuschneiden — jeden Klick, jede Seite, jede Bewegung — und die Auswertung später zu erledigen.

Bei einer Gesundheitsplattform ist genau das die falsche Antwort. Je mehr feingranulare Verhaltensdaten man hortet, desto größer wird das Risiko, das man mit sich herumträgt. Diese Woche beschreibe ich, wie wir Mitglieder-Aktivität erfassen, ohne ein detailliertes Bewegungsprofil jedes Menschen anzulegen — und warum uns der Grundsatz "so viel Aktivitätssignal wie nötig, so wenig gespeicherte Daten wie möglich" durch jede Designentscheidung geleitet hat.

Warum nicht einfach alles loggen

Ein vollständiges Nutzungs-Log klingt verlockend, weil es jede zukünftige Frage beantworten könnte. Der Preis dafür ist allerdings hoch. Wer festhält, wann jemand welche Seite geöffnet hat, baut ein Bewegungsprofil auf — und bei einer Plattform, an der Blutzuckerwerte, Ernährungspläne und Trainingsdaten hängen, ist ein solches Profil selbst schützenswert. Es wird zum Ziel, zur Auskunftspflicht und zur Löschverpflichtung.

Die DSGVO liefert hier keinen bürokratischen Störfaktor, sondern die passende Denkweise. Datensparsamkeit heißt: Ich frage mich zuerst, welche Frage ich beantworten muss, und speichere dann nur das, was diese Frage tatsächlich erfordert. Unsere Frage lautet fast nie "Was hat Person X wann getan?", sondern "Ist Person X noch aktiv?". Das ist ein viel kleineres Signal — und danach richtet sich das gesamte Modell.

Ein append-only-Ereignisstrom

Im Kern steht ein einziges Konstrukt: der UserActivityEvent. Aktivität erfassen wir als append-only-Strom. Ereignisse werden angehängt, niemals überschrieben und niemals im Nachhinein umgeschrieben. Das hat zwei Vorteile. Erstens ist ein reines Anhängen technisch robust — es gibt keine konkurrierenden Updates auf denselben Datensatz, keine Sperren, keine verlorenen Schreibvorgänge unter Last. Zweitens ist ein append-only-Log leicht zu begründen: Was drinsteht, ist passiert, und was nicht mehr gebraucht wird, kann später als Ganzes entfernt werden.

Ein Ereignis ist bewusst arm an Inhalt. Es hält fest, dass eine Nutzerin zu einem Zeitpunkt etwas getan hat, aber nicht die Feinheiten dessen, was auf welchem Bildschirm geschah. Wir schreiben diese Ereignisse dort, wo sie ohnehin entstehen — an den natürlichen Übergängen im System, die unsere Logging-Konvention <Domain>.<Process>.<Layer> bereits markiert. So bleibt das Aktivitätssignal ein Nebenprodukt der normalen Nutzung und kein zweites, paralleles Überwachungssystem.

Das hybride 30-Tage-Aktiv-Prädikat

Die eigentliche Intelligenz steckt nicht im Speichern, sondern im Auswerten. Wer als aktiv gilt, entscheidet ein hybrides 30-Tage-Aktiv-Prädikat. "Hybrid" bedeutet, dass die Antwort aus mehr als einer Signalquelle stammt: aus dem jüngsten Ereignisstrom für die letzten Tage und aus verdichteten Kennzahlen für alles, was länger zurückliegt. So können wir sagen, ob jemand innerhalb der letzten 30 Tage aktiv war, ohne dafür jede einzelne Interaktion dieser 30 Tage dauerhaft vorhalten zu müssen.

Der Kniff liegt genau in dieser Trennung. Feingranulare Ereignisse sind nur so lange nützlich, wie sie frisch sind — für die Frage nach den letzten Tagen. Für die längerfristige Aussage "aktiv oder nicht" genügt eine verdichtete Form. Damit entkoppeln wir den Nutzen des Signals von seiner Haltbarkeit: Das Prädikat bleibt aussagekräftig, während die Rohdaten dahinter altern und verschwinden dürfen. Genau deshalb ist das Fenster auf 30 Tage festgelegt und nicht offen — es ist lang genug, um Gewohnheiten abzubilden, und kurz genug, um kein Archiv zu werden.

Vernetzte Knoten als Sinnbild für Präsenz Foto: Rawpixel (CC0 1.0), via Openverse

Präsenz ohne Ortung

Eng verwandt mit Aktivität ist Präsenz — die Frage, wer gerade jetzt online ist. Dafür gibt es GetOnlineUserIds. Diese Methode macht Präsenz sichtbar, ohne Standort- oder Inhaltsdaten heranzuziehen. Sie beantwortet ausschließlich, welche Konten in einem kurzen Zeitfenster ein Lebenszeichen gegeben haben, und liefert dafür schlicht eine Menge von Nutzer-IDs zurück.

Das ist eine bewusst enge Definition. "Online" heißt bei uns nicht "hält sich an Ort Y auf" oder "sieht gerade Inhalt Z", sondern nur "war eben erreichbar". Für ein Präsenzlämpchen neben einem Mitglied oder für die Anzeige, dass ein Trainer gerade verfügbar ist, reicht das vollständig — und mehr will man an dieser Stelle auch gar nicht wissen. Alles, was über diese Ja/Nein-Aussage hinausgeht, wäre wieder ein Schritt zurück in Richtung Bewegungsprofil.

Ein Modell auf der grünen Wiese ist das eine, ein Modell im laufenden Betrieb das andere. Drei Hintergrundprozesse sorgen dafür, dass die Aktivitätsdaten über die Zeit gesund bleiben.

Backfill hat die Historie einmalig aufgefüllt. Ohne ihn hätte das Aktiv-Prädikat bei der Einführung so getan, als wäre niemand aktiv, weil schlicht keine vergangenen Ereignisse vorlagen. Der Backfill hat aus bereits vorhandenen Spuren im System eine plausible Ausgangslage rekonstruiert.
Prune ist der Dauerbetrieb: Ein Job entfernt regelmäßig alte Ereignisse, sobald sie ihren Zweck für die jüngste Auswertung erfüllt haben. Der append-only-Strom wächst also nicht unbegrenzt, sondern wird am hinteren Ende laufend beschnitten.
Der GDPR-Sweep schließlich sorgt für eine datensparsame Aufbewahrung als feste Regel. Er stellt sicher, dass Ereignisse nicht länger liegen bleiben, als sie gebraucht werden, und dass die Löschung nicht von einem manuellen Eingriff abhängt, sondern automatisch geschieht.

Diese drei greifen ineinander. Backfill macht das Prädikat vom ersten Tag an brauchbar, Prune hält die Datenmenge klein, und der Sweep macht die Datensparsamkeit verbindlich statt optional. Als Worker laufen sie im Hintergrund und lassen sich, wie unsere übrigen Worker, über die Laufzeit-Feature-Flags anhalten, falls wir sie einmal pausieren müssen.

Was das in der Praxis bedeutet

Für ein Studio oder einen Trainer ändert sich an der Oberfläche wenig Sichtbares, und das ist Absicht. Man sieht, wer aktiv ist und wer gerade online ist — genau die zwei Aussagen, die für die tägliche Arbeit zählen. Was man nicht sieht, weil es nicht existiert, ist die lückenlose Chronik dessen, was ein Mensch in der App getan hat.

Für uns als Betreiber ist der Gewinn ein leiseres Gewissen und ein kleineres Risiko. Ein Auskunftsersuchen lässt sich beantworten, ohne einen Berg an Verhaltensdaten aufzuarbeiten, und eine Löschung ist ohnehin schon im System eingebaut. Der Grundsatz, so viel Aktivitätssignal wie nötig und so wenig gespeicherte Daten wie möglich zu halten, ist damit kein Slogan, sondern die Form, die das Datenmodell tatsächlich angenommen hat.